FPGA Central

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?

Thanks
Roy

On Tue, 16 Jun 2009 20:36:22 -0700, Roy wrote:

> 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?
>
> Thanks
> Roy

"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 (http://www.wescottdesign.com/actfes/
actfes.html) 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.

--
www.wescottdesign.com

On Jun 16, 9:53*pm, Tim Wescott <t...@seemywebsite.com> wrote:
> On Tue, 16 Jun 2009 20:36:22 -0700, Roy wrote:
> > 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?
>
> > Thanks
> > Roy
>
> "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 (http://www.wescottdesign.com/actfes/
> actfes.html) 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.
>
> --www.wescottdesign.com

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.

Hardy

On Jun 17, 12:53*am, Tim Wescott <t...@seemywebsite.com> wrote:

> "press the self tune button, repair airframe, repeat".

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)

> "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.
>

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?

>
> I think you should first learn how to do it at all, then concern yourself
> with doing it adaptively.

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 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.
>

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.

>
> --www.wescottdesign.com

- Roy

On Jun 17, 3:18*am, HardySpicer <gyansor...@gmail.com> wrote:

> 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.
>
> Hardy

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).

- Roy

Roy wrote:

> 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?

Do NOT. You don't want this.

1. Build a math. model of the airframe.
2. Measure the parameters of the real airframe and put it into the model.
3. Find the parameters for the control on the math. model.
4. Apply the parameters to the real thing.
5. Apply minor tweaks where necessary.



Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On Jun 16, 8:36*pm, Roy <brewer....@gmail.com> wrote:
> 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?
>
> Thanks
> Roy
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.

Peter Nachtwey

On Jun 17, 10:56*am, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
wrote:

>
> Do NOT. You don't want this.
>
> 1. Build a math. model of the airframe.
> 2. Measure the parameters of the real airframe and put it into the model.
> 3. Find the parameters for the control on the math. model.
> 4. Apply the parameters to the real thing.
> 5. Apply minor tweaks where necessary.
>
> Vladimir Vassilevsky
> DSP and Mixed Signal Design Consultanthttp://www.abvolt.com

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)

- Roy

> 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.

In my nominal control scheme the joysticks (or path planning function)
will generate desired attitudes, rates, velocities, and positions.

> 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.

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.

> 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.

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.)

> 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.

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 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 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"

>
> 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.
>

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

> 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.

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.

>
> Peter Nachtwey

- Roy