Welcome
Username or Email:

Password:


Missing Code




[ ]
[ ]
Online
  • Guests: 108
  • Members: 0
  • Newest Member: omjtest
  • Most ever online: 396
    Guests: 396, Members: 0 on 12 Jan : 12:51
Members Birthdays:
All today's birthdays', congrats!
Download (31)
ScottH (37)


Next birthdays
11/02 Download (31)
11/02 ScottH (37)
11/03 Electroguy (94)
Contact
If you need assistance, please send an email to forum at 4hv dot org. To ensure your email is not marked as spam, please include the phrase "4hv help" in the subject line. You can also find assistance via IRC, at irc.shadowworld.net, room #hvcomm.
Support 4hv.org!
Donate:
4hv.org is hosted on a dedicated server. Unfortunately, this server costs and we rely on the help of site members to keep 4hv.org running. Please consider donating. We will place your name on the thanks list and you'll be helping to keep 4hv.org alive and free for everyone. Members whose names appear in red bold have donated recently. Green bold denotes those who have recently donated to keep the server carbon neutral.


Special Thanks To:
  • Aaron Holmes
  • Aaron Wheeler
  • Adam Horden
  • Alan Scrimgeour
  • Andre
  • Andrew Haynes
  • Anonymous000
  • asabase
  • Austin Weil
  • barney
  • Barry
  • Bert Hickman
  • Bill Kukowski
  • Blitzorn
  • Brandon Paradelas
  • Bruce Bowling
  • BubeeMike
  • Byong Park
  • Cesiumsponge
  • Chris F.
  • Chris Hooper
  • Corey Worthington
  • Derek Woodroffe
  • Dalus
  • Dan Strother
  • Daniel Davis
  • Daniel Uhrenholt
  • datasheetarchive
  • Dave Billington
  • Dave Marshall
  • David F.
  • Dennis Rogers
  • drelectrix
  • Dr. John Gudenas
  • Dr. Spark
  • E.TexasTesla
  • eastvoltresearch
  • Eirik Taylor
  • Erik Dyakov
  • Erlend^SE
  • Finn Hammer
  • Firebug24k
  • GalliumMan
  • Gary Peterson
  • George Slade
  • GhostNull
  • Gordon Mcknight
  • Graham Armitage
  • Grant
  • GreySoul
  • Henry H
  • IamSmooth
  • In memory of Leo Powning
  • Jacob Cash
  • James Howells
  • James Pawson
  • Jeff Greenfield
  • Jeff Thomas
  • Jesse Frost
  • Jim Mitchell
  • jlr134
  • Joe Mastroianni
  • John Forcina
  • John Oberg
  • John Willcutt
  • Jon Newcomb
  • klugesmith
  • Leslie Wright
  • Lutz Hoffman
  • Mads Barnkob
  • Martin King
  • Mats Karlsson
  • Matt Gibson
  • Matthew Guidry
  • mbd
  • Michael D'Angelo
  • Mikkel
  • mileswaldron
  • mister_rf
  • Neil Foster
  • Nick de Smith
  • Nick Soroka
  • nicklenorp
  • Nik
  • Norman Stanley
  • Patrick Coleman
  • Paul Brodie
  • Paul Jordan
  • Paul Montgomery
  • Ped
  • Peter Krogen
  • Peter Terren
  • PhilGood
  • Richard Feldman
  • Robert Bush
  • Royce Bailey
  • Scott Fusare
  • Scott Newman
  • smiffy
  • Stella
  • Steven Busic
  • Steve Conner
  • Steve Jones
  • Steve Ward
  • Sulaiman
  • Thomas Coyle
  • Thomas A. Wallace
  • Thomas W
  • Timo
  • Torch
  • Ulf Jonsson
  • vasil
  • Vaxian
  • vladi mazzilli
  • wastehl
  • Weston
  • William Kim
  • William N.
  • William Stehl
  • Wesley Venis
The aforementioned have contributed financially to the continuing triumph of 4hv.org. They are deserving of my most heartfelt thanks.
Forums
4hv.org :: Forums :: General Science and Electronics
« Previous topic | Next topic »   

Pan and Tilt?

 1 2 3 
Move Thread LAN_403
Steve Conner
Tue Jul 14 2009, 09:55AM
Steve Conner Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706
MinorityCarrier wrote ...

With digital positioning you can control speed to setpoint easily.

Yes, and in order to do this, you'll need to write code that amounts to a digital simulation of an old-fashioned PID controller. That's what "controlling speed to setpoint", "slow down on approach" and so on is: the D term of the PID. A PID controller is not one of those thermostat things: it's a mathematical abstraction of which the temperature control box is just one practical instance.

In other words, changing to the digital domain doesn't make the control problem go away. If anything it makes it harder, because you can now implement non-linear functions to confuse yourself even further, and hide the true nature of a control problem that's been fully understood in the analog domain since the first servo-driven gun turrets of World War 2. Although I will grant it is easier to prevent integrator windup in the digital domain, and those gun turrets had what amounted to a dead band, which is non-linear.

Microchip have several application notes for motor control, including one that implements digital PID control on a DC motor with a position encoder, on the 18 series PICs.
Back to top
MinorityCarrier
Wed Jul 15 2009, 04:37AM
MinorityCarrier Registered Member #2123 Joined: Sat May 16 2009, 03:10AM
Location: Bend, Oregon
Posts: 312
Firt of all, all the robotics I work around, metrology X-Y tables, Wafer placement and cassette elevators, use digital position encoding. We couldn't tolerate the ringing out of an analog PID controller in these. The only analog position control on the lithography steppers uses a HeNe laser interferometer (lambda/64 I believe) for final positioning.

You misunderstand my meaning of "speed to setpoint" and "slow down on approach". I'm not referencing proportional or intergral terms, and only mimicing the derivative. I'm guessing Ama is playing with videography or something optical-related, and tilt and pan used for something like videography, where I've used motorized platforms, often different pan speeds are desired, motor drive speed is then manually selected as is ramp up and ramp down, for smooth pan effect. With absolute position encoding the starting position error relative to destination position is not used for proportional or integral term error to determine speed. As the destination is approached, something like the derivative term is used (mag comparators triggers ramp-down of the step frequency input to the stepper motor controller in what I've done). And once the programmed position is reached the position is locked, no PID ringing around set point, needed for precision placement or videography. Digital control goes to position and stops, there. Watch the X-Y table of a KLA-Tencor UV1250 and tell me an analog PID could control that. Programming a PIC I guess would be a pain, I wouldn't know, I build logic circuits to perform these tasks.

Also, I was my understanding that aircraft gun turrets (B29 etc) used 400Hz AC phase resolvers for position encoding and determining drive speeds. I didn't realize this was an analog PID control, my ignorant.
Back to top
Carbon_Rod
Wed Jul 15 2009, 07:31AM
Carbon_Rod Registered Member #65 Joined: Thu Feb 09 2006, 06:43AM
Location:
Posts: 1155
Sounds like your control loop needs tuned, latency issues, or the power source is unstable.

Tried Spherical Vision + VS
Link2

Cheers,
Back to top
Dr. Slack
Wed Jul 15 2009, 08:11AM
Dr. Slack Registered Member #72 Joined: Thu Feb 09 2006, 08:29AM
Location: UK St. Albans
Posts: 1659
I guess you still haven't got Steve's main point, but I'm not sure anyone has got yours yet.

There are two main control philosophies, each has two flavours, and then each can be implemented in analog or digital. Finally each can be linear or non-linear. I make that potentially 16 different scenarios to discuss. Unless you nail specifically what problem or approach is being discussed, it will all be at cross purposes.

The 2 main philosophies are "closed loop" and "open loop", also known as "fed-back" and "dead-reckoning". Closed loop can do things that open loop cannot, like compensate for reaction from loading.

The two flavours are "high speed" and "low speed". In the former, slewing between positions is so rapid that kinetic energy of the masses and compliance of the links stores enough energy to have to be taken into consideration. In the latter, things can creep around and start and stop on a dime without any apparent overshoot. There isn't a hard and fast demarcation between these, the important word is "apparent". This means that the way a stepper motor is normally used is "slow", though I have worked on a design where a stepper was moved in "fast" mode.

The difference between analog and digital is more implementation detail than real difference, though it is a lot easier to do very non-linear things in digital.

Linear versus non-linear is where it gets exciting. There's lots of theory out there for linear systems. Go non-linear, and you are pretty much on your own.

Of these, the most difficult to get right is "high speed" "closed loop". It doesn't matter whether it is done as analog or digital, you need linear control theory.Horowitz, Black, Nyquist, all those good people spent the early 20th century getting amplifiers and gun turrets to be stable. When you close the feedback loop round the system, you get the potential for instability. Actually, if you close the feedback loop round a system without understanding the mathematics, you get the virtual certainty of instability.

Depending on the order of the system, generally how many integrators it contains (for instance voltage to inductor current, current via torque to acceleration, to speed, to position), it is possible to design a linear control system which will settle without an overshoot, or it may be part of the mathematics that an overshoot *must* occur (quite common for high order systems). Reducing the order of the system is good here, if you can control the servo current rather than voltage, you have at once eliminated one integrator, and with it 90 degrees of phase shift you really didn't want.

Without wanting to appear too preachy, if it's closed loop and linear, it *has all been done*. Read the books, understand the criteria, pick your compromise response (fast with an overshoot or slower without), implement the control loop (analog or digital, it doesn't matter which, though one's easier to tune and to interface to your PC), and you cannot do better than that.

If you want to go non-linear open loop, the scenario that has the potential for the highest possible settling speed, then google for "solving the inverse dynamical problem". It is fairly easy to put a sequence of control forces into a springy massy system model and predict what it is going to do. It is a reasearch topic to derive the sequence of control forces that will result in a specified load trajectory. The research I spotted was how to move a dangling bucket of concrete, suspended from a tower crane, from rest here to rest there in the shortest possible time.

To refer back to some words from an earlier post, "slow down on approach". A well-tuned linear system has this behaviour. If it's done with "if distance to set point is < threshhold, then decrement speed", then you are non-linear, and there is no theory that will help you. Empirically, it's very very hard to out-perform a well-tuned linear system with a seat-of-the-pants non-linear system.
Back to top
Steve Conner
Wed Jul 15 2009, 10:25AM
Steve Conner Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706
Basically +1 on everything Dr. Slack said. Just a few points:

With absolute position control using encoders, it's integral control by default, because the control loop compares actual position and desired position, but what it actuates is motor speed, and position is the integral of velocity.

So there's a mechanical integration going on in the plant, and that explains how there can be zero steady-state position error without an explicit integral term in your controller. (A PD controller would actually be PI.)

In one of Dr. Slack's "fast" systems it's worse than that, it's double integral, because now that we consider inertia, the motor control signal determines acceleration, and velocity is the integral of acceleration, and position the integral of velocity. So if you just close the loop with a gain term ("P controller") there is 180 degrees of phase shift (two integrations at 90 degrees each) and the system is naturally unstable. (thanks Mr. Nyquist!) I'm guessing this is the original poster's problem.

Those gun turrets did indeed use synchros, amplidynes and so on, but the math was all the same as the latest digital CNC tools.
Back to top
GeordieBoy
Wed Jul 15 2009, 11:43AM
GeordieBoy Registered Member #1232 Joined: Wed Jan 16 2008, 10:53PM
Location: Doon tha Toon!
Posts: 881
I think it would be good to have Dr Slack and Steve's posts to this control issue archived somewhere. The issues they discuss are equally applicable to those people modifying PC SMPSUs and then complaining that the supply whines and the output oscillates! It's all control theory, just on different scales.

-Richie,
Back to top
Steve Conner
Wed Jul 15 2009, 12:09PM
Steve Conner Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706
I'm not too sure whether our posts would actually be helpful to the average hobbyist. Control theory is one of these things that is hard to apply unless you have the mathematical background.

For instance, I said above that an integration causes a 90 degree phase shift: that's not obvious unless you've studied Laplace transforms, complex numbers and so on, and you won't even have an intuitive feel for what integral and derivative mean unless you've done calculus 101.

And, terms such as "plant" and "controller" that we toss around casually may well be pretty meaningless unless you've actually taken a control engineering class. Simple answer: "plant" is the water bath, temperature sensor and heater. "Controller" is the thermostat. But it's not always as clear-cut as that. A cookie for anyone who can tell me which parts of an ATX power supply (or similar SMPS) constitute the plant and the controller. If you can tell me what type of controller it is (PI, lead, lag, lead-lag and so on) I'll make it a chocolate Oreo.

I'd be happy to collaborate with Richie and Dr. Slack on a control theory for newbies article, maybe for the HVWiki, but I'm honestly not sure what good it would do. And only if we get to call it "Pole (and zero) dancing for beginners" :D

Any other opinions on this matter are welcome.
Back to top
Dr. Slack
Wed Jul 15 2009, 02:07PM
Dr. Slack Registered Member #72 Joined: Thu Feb 09 2006, 08:29AM
Location: UK St. Albans
Posts: 1659
Practical stuff for Ama

The very fastest way of getting from rest at A to rest at B is the non-linear method of apply maximum acceleration until maximum velocity, run at max V until the right distance from B, then brake with maximum acceleration again, coming to rest at the right spot.

The only problem with this is the detail of applying the braking force for the right time, at the right time. Load inertia, winding resistance, error in starting velocity etc will all conspire such that any open loop way of doing it will give you a residual velocity and position error by the time the braking command has finished.

If you switch on a conventional control loop to handle the final settling, then it is starting from an unknown velocity and position, albeit very close to the target. Actual settling will take a while. If the whole movement had been under closed loop control, then although the slew and approach to the final position may be slower, the final settling could well be quicker.

OTOH, it might be interesting to do a fast slew and brake, then switch on closed loop control with a phase-space controller, the sort of thing that keeps a Segway (tm) vertical and going at a defined speed. Instead of controlling only the position, and letting velocity and acceleration be subservient to that, it controls both velocity and position, so may be able to make better use of the velocity and position errors at the end of the braking phase. I know little of the detail of this, but it will not be breaking any of the fundamental stability rules.

A stepper motor can give the illusion of breaking the rules, especially if used carefully beyond its "single-step-stop" speed. For any given load inertia, a stepper may well be specified to start and stop in one step up to x steps per second, and to operate above that up to some maximum as long as the rate of change of step speed is kept below y. It is then fairly easy to draw a software profile backwards from the target position, run the acceleration backwards at maximum rate of change until you reach maximum speed, and note the position. Then when you make it run forwards, braking starts at the right place, and it magically comes to rest on the money.

Steve and Richie

Personally I use very little hardcore control theory, only do Laplace if necessary to save my life. I've not yet met a control problem that couldn't be solved by a few lines scrawled on a Bode plot, and the basics of that don't need over-much mathematics. Now I've discovered my favourite Spice-alike simulator (Simetrix) implements Laplace equations directly, it's made it much easier to do time plots of phase locked loops and the like settling (and another analytic discipline falls to mindless simulation!)

Actually, the most practical stuff for Ama

Download Simetrix (free)(see the wiki for where to get it), and model the interia, forces etc of your system. Then simulate what it does in time. Much easier to tune, faster to iterate. In modelling what you have mechanically, you may get to understand it better. I can help with some of the modelling or simulation nitty-gritty if you like, either by pm, or start a new "simulating the dynamics of my camera positioner" thread for everyone's benefit.

Back to top
MinorityCarrier
Thu Jul 16 2009, 05:52AM
MinorityCarrier Registered Member #2123 Joined: Sat May 16 2009, 03:10AM
Location: Bend, Oregon
Posts: 312
I have dug up some photos of PID set-up work I did with a Rapid Thermal Processor. While not a servo motor situation, the graph data of the servo feedback control response shows some of what's involved trying to tune a PID servo loop control.

In this system, the energy in is from a bank of quartz lamps, the feedback sensor is an optical pyrometer imaging a silicon wafer. The first photo shows the as-found response.




There is a secondary undershoot, indicating underdamping, at the end of both ramp-ups in the response indicating the PID is not optimally tuned. A calibration was performed where the pyrometer output is compared against a thermocouple, the response is shown in the second photo.



An iterative process of tuning was performed until the response in the third photo was achieved.



the fourth photo shows instability introduced into the servo loop when a silicon wafer with a layer of silicon dioxide was substitued for the original silicon wafer.



This is one of the weaknesses of analog PID. A change can de-tune the loop enough to send the control into oscillations. Precision placement systems would find this possibility a problem.

I also went back to the books to brush up on servo theory and to improve my vocabulary so that Mr McConner won't beat me up so much for speaking podunk american english.

Feed-forward control with digital position encoding and motor velocity control is what I have used for my video platform. There is little disturbance to setpoint position of the pan part of tilt and pan, and if the tilt is well balanced, braking the tilt motor at set position prevents disturbance there. Based upon Ama's description of what he's seeing with his tilt-and-pan platform, I'd recommend he look into that approach.

PID overshoot and undershoot even with a critically damped set-up is unacceptable for videography applications, and certainly in some of the optical metrology tool applications I have previously mentioned (tachometer feedback speed control and motor step count referenced to an initialization home position is what they use for positioning).

And yeah, I botched the picture placement. I'll figure out how to do that later.







1247722205 2123 FT72820 Img 1b

1247722205 2123 FT72820 Img 2b

1247722205 2123 FT72820 Image 4b

1247722205 2123 FT72820 Image 5b
Back to top
Proud Mary
Thu Jul 16 2009, 10:25AM
Proud Mary Registered Member #543 Joined: Tue Feb 20 2007, 04:26PM
Location: UK
Posts: 4992
I agree with Hr Dr McConner - my ideas would fall somewhere between self-steering gear and the ailerons of a V1, so I shall drop out of this thread with good grace.
Back to top
 1 2 3 

Moderator(s): Chris Russell, Noelle, Alex, Tesladownunder, Dave Marshall, Dave Billington, Bjørn, Steve Conner, Wolfram, Kizmo, Mads Barnkob

Go to:

Powered by e107 Forum System
 
Legal Information
This site is powered by e107, which is released under the GNU GPL License. All work on this site, except where otherwise noted, is licensed under a Creative Commons Attribution-ShareAlike 2.5 License. By submitting any information to this site, you agree that anything submitted will be so licensed. Please read our Disclaimer and Policies page for information on your rights and responsibilities regarding this site.