Since you were so helpful with my last two questions, I thought I'd try another one :-)
Many quadrotor hobbyists buy or build their own custom airframes with widely varying dimensions, weights, materials, motors, propellers, etc. These guys don't know anything about control theory, so they've coded up a PID implementation they found on the internet somewhere and tune the gains via various dubious methods (like holding the craft in their hands and shaking it). My thought was to design a fairly generic control scheme and employ some sort of autotuning or adaptive structure to automatically find the gains inflight. My idea would be to make this a user-initiated mode to "calibrate" the gains. Once the process was finished, the gains would be frozen, at least until the next time they hit the calibrate button. The vehicles are unstable, so can't be flown without some sort of feedback loops.
What do you think of this? Any advice or recommendations for good adaptive control references?
"press the self tune button, repair airframe, repeat".
"Adaptive Control" by Karl Astrom & Bjorn Wittenmark (with semi-literate umlaut deletions from the Swedish, by yours truly). It's _the_ book on adaptive control, by _the_ guy.
My favorite part, after learning all about adaptive control, is chapters
8, 9 and 10 where they try to talk you out of using it in fielded systems unless you _really_ need it. Heed the warnings.
I think you should first learn how to do it at all, then concern yourself with doing it adaptively.
I further suggest that if you at all know what you're doing you'll do a lot better by building in some hooks to do system identification. Then rough tune your controller by any means that'll result in stable flight, do a system identification pass, and design your 'real' controller. You'll probably want to iterate a few times to get really decent performance.
My book on applied control theory
formatting link
has a chapter on doing this using frequency response methods, although if it ever goes to a second edition it'll have bump testing and ARMA system parameter extraction added.
Forget the Astrom approach. Most of the adaptive approaches don't have integral action. Self tuning control was in vogue about 25 years ago when I did my Ph.D. It's robust control now guys! Just because they minimise a squared error and control cost function does not make them good. You will need to implement recursive-least squares.in real-time in a micro. There are some criteria that have integral action however if you do a search. LQG is no good but can be modified by using dynamic weighting.
Still beats "completely ignorant user tune gains, repair airframe, repeat". (BTW, Tim, when the forum asked what the PID gains do, I pointed them to your "PID without a PhD". I also plugged your book. Alas, I suspect both went over most of their heads. Hence the auto- tuning concept)
I assumed this after a quick google search. I have the first edition (with umlauts :-). I notice that Dover has the second edition in paperback (of course - gotta love Dover!). Do you think the second edition is that much better than the first?
Completely agree. I'm going to build a model in scilab, design a controller, fly the real thing, do system ID, refine the model, refine the controller, lather, rise repeat. After I understand the dynamics, then I'd like to give something back to the community (most of whom don't want to hear about gains - they just want to fly the thing)
I guess I see 4 options:
1) have ignorant users tune the gains on their own (the only choice today)
2) give them something that's flyable, and use adaptive techniques to auto-tune the gains in the controller
3) give them something that's flyable, include on-board data collection or telemetry, auto-tune the gains off-line on a laptop
4) design a control system that provides great performance for a wide range of configurations
I don't think there's too many parameters to identify: motor/rotor characteristics (maybe just a gain and a time constant and perhaps a delay?), mass, moment of inertias.
I'm not looking for what's in vogue - I just want something that works. Having said that, my main motivation for this project (besides that it seems a fun hobby) is to learn more control theory. Do you have more specific references for what you're talking about, Hardy? I'm sure I have some robust control textbook around here somewhere.
I see a lot of papers in the quad literature that talk about using "integral backstepping" and "sliding mode control" (among others). I never got to non-linear controls in school, but these sound intriguing. On the other hand, lots of folks seems to have success with plain old PID (or just PD). The quad is a good control testbed because it is underactuated, non-linear, and has highly coupled rotational and translational dynamics (not unlike a helicopter, in some ways, but the actuators are mechanically much simpler).
I am a motion control guy and this is how a motion control guy would approach the problem. First I would make the joy sticks update a target generator. This would at least have the target or reference attitude of the craft and would always go back to stable upright position when the joysticks are in neutral, duh. Hopefully you have some sort of elevation detection too so that you can have a target elevation, yaw pitch and roll. Using PIDs is the obvious way to go but what you should notice it that when the craft is at an angle the the propellers are not pushing straight up, the efficiency of lift goes down by the cos(AngleFromUp). Once the craft gets at an angle that is too steep the craft will just plow into the ground. The cure isn't obvious or intuitive because the obvious thing to do is to increase the speed of the lower rotors to level the craft but they will probably be 'maxed' out. The solution would be to lower the speed of the higher rotors so the craft becomes more level and this isn't intuitive. Since the lift efficiency goes down by a factor of 1/cos the PID gains should be multiplied by 1/cos(AngleFromUp) to compensate and provide more thrust to maintain elevation. I would try to leave some head room for the lower rotors so they can level the craft by increasing speed instead of having other rotor decrease speed and lose elevation. You can see this isn't too exotic. I think the big part is going to adjust the rotor speeds base on angle. The distance from the axis of tilt will be a factor on leveling the craft. So there appears to be two factors to consider, elevation and tilt. I bet with a little thought one can figure out a control scheme with an integrator that while minimize the error of the attitude and elevation.
You should be able to suspend your craft from a string and first try to control the attitude. You should be able to see how a motors effectiveness varies with the distance from the axis of rotation. I think the 1/cos(AngleFromUp) is a no brainer. By using a counter balance on the string you can adjust the amount of assisting lift force until you can control the elevation.
I think you are a long way from auto tuning because the effectiveness of each rotor varies a lot depending on the attitude and the distance from the current axis of rotation. When you have good estimates for that THEN you can consider auto tuning. The auto tuner must take into account the attitude and distance from axis of rotation.
Exactly my plan - for my particular quadrotor implementation. Once I have a validated model, I can run some sensitivity parametrics to ascertain the impact of different user's configurations. Without having done any of that, I am doubtful I can come up with a set of static gains that will work for all users. OTOH, all these guys will have some sort of laptop-based ground station to update the s/w, change the on-board gains, etc. I think the best approach may be some sort of off-line system ID / gain update procedure on the laptop (per Tim)
In my nominal control scheme the joysticks (or path planning function) will generate desired attitudes, rates, velocities, and positions.
At some bank/pitch angle, the system has to gracefully disable altitude hold (and just as gracefully re-engage it when the angles are reduced) - otherwise all that will happen is we'll wind up the integrators and translate instead of holding altitude.
You can't do this. The opposing rotor speeds must be balanced to command an attitude change - that is if the front rotor increases by
100 rpm, then the rear must decerase by 100, otherwise the craft will start to yaw (both thrust and drag (and hence torque) are proportional to the square of the rotor speed.)
Yes, its highly non-linear. But, I don't think I would change the gains as a function of sensed attitude. I'd keep the gains constant (especially if I go with a linear PID architecture). Instead, I'd put in some feedforward "throttle" as a function of _commanded_ attitude (not sensed) if altitude hold is enabled. Otherwise I'll have created another non-linear feedback loop.
I plan on designing with successive / nested loops: attitude being the innermost, then altitude, then position. As you point out, the degrees of freedom are highly coupled to one another. I also think (at least initially) I'll just allocate a certain percentage of rotor speed command to the "vertical/thrust" axes, another percent to the pitch/ roll axes, and the third to the yaw axis, so I can properly handle "saturation"
Suspending a craft with 6 DOF and 4 whirling blades from a string strikes me as a bad idea :-) I've seen gimballed 3DOF mounts, and simple 1 DOF tilt mounts. I don't think I'd want to build a vertical- only 1 DOF test fixture
You're forgetting moments of inertia and mass - which may be difficult for the generic user to measure themselves. But I could tell them how to determine the parameters, enter the numbers into a PC program and have it spit out the gains. Or I could get a "robust" set of gains that is good enough to fly briefly enough to gather sufficient in- flight data to do automated system ID and again post process via ground-based PC.
Keep in mind that "atuotuning" is a project for way down the line, after the basic system is developed and tuned.
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.