I was hoping that someone could explain why the Throttle PID's are designed like this.

This is like a feed forward controller design that is then stabilized by the PID feedback loop. That is ok.


Why is the feed forward gain based on to desired rate squared? (propeller static force is proportional to (delta RPM)^2 from what I can find on the net but ESC's aren't very linear anyway)

Why is the limit on the output set to 3200 when the output of the throttle should be only 0 to 1000? (I may be wrong here but I have done my best to check this)

Why didn't we get rid of the rate squared term and just use the PID loop?

Why didn't we get rid of the Throttle Cruze offset and just use the PID loop and not reset the I term? This approach may stop that "my copter dropped out of the sky when I switched to altitude hold mode" problem. Even if the I term is zero to start with at least it can correct it's self while in this flight mode instead of having to fly in Stabilize Mode for 10 to 15 seconds.

I just want to reassure everybody that I am not having a go at all the hard work the developers have done on this project so far. I am just enjoying working towards helping improve the code. Before attempting to improve things I want to understand why things are the way they are.

I would really appreciate any help and discussion that people can contribute.

Edit:

Ok, I was slack and didn't put the control input into the diagram. Here it is.

It is a bit complicated to work out from the code because the throttle control is very non linear. Navigation control does something similar but it has set THR_ALT_P to 1/4, limited from 100 to 180,if going up and 1/6 if going down, limited from -10 to -100.

Views: 5270


Developer
Comment by Pete Hollands on August 25, 2012 at 12:20am

Could you add a link to the code that your examining ?


Developer
Comment by leonardthall on August 25, 2012 at 12:41am

The two parts of the code that I am looking at relating to the Throttle control are:

http://code.google.com/p/ardupilot-mega/source/browse/ArduCopter/Ar... (Lines 1828 to 1840)

http://code.google.com/p/ardupilot-mega/source/browse/ArduCopter/At... (Lines 355 to 377)

Thanks for taking the time to have a look!

I realize that this part of the code is only used when changing altitude and that the Cruze throttle is updated when in Altitude Auto mode here:

http://code.google.com/p/ardupilot-mega/source/browse/ArduCopter/Ar...

I will have to add the Throttle Auto diagram as well.

Comment by Phil Cramer on August 25, 2012 at 5:44am

I find the throttle control to be very sensitive and tricky while trying to maintain a constant altitude. Small stick inputs yield too large a response from my 3DR quad, APM2. I'd like to fly Stabilize mode at the same altitude for shooting steady video. It's hard enough to control roll and pitch directions without having to 'fight' the throttle. 

I'm anxious to see if there's some activity with the code to help with this 'sensitivity.' TIA.


Developer
Comment by leonardthall on August 25, 2012 at 7:24am

Hi Phil,

Are you taking about the throttle being too sensitive in Stabilize mode or in Alt Hold mode. Because Alt Hold does a pretty good job at maintaining altitude. It can be a bit abrupt and bouncy when changing altitude but very steady at constant altitude if the pids are tuned well.

I found the throttle very sensitive in Stabilize mode too and the way I addressed it was to adjust the center point of my throttle throw to be at hover then added expo. It was like night and day for me.

Comment by Phil Cramer on August 25, 2012 at 7:37am

Leonard, yes, too sensitive in Stabilize mode. I need to work with Alt Hold mode more and get better at going in and out of that mode. It's been a bit scary knowing that the throttle will have "shifted" when exiting Alt Hold.

I wish I had expo on throttle. My radio is Spektrum DX7s and no expo or rates on throttle. Time for a new system? Not practical now. I like your center point adjustment tip. Is that a Tx setting or can it be done with MP? I'll see if I can figure a way to do it. Thanks! 

Comment by Gerard Toonstra on August 26, 2012 at 12:08am

The "squared"  term is probably related to expressions of energy. Throttle is not an aircraft "speed" setting, it's a lever to insert or bleed energy to/from your platform. This energy in the aircraft is either kinetic or potential, which is basically saying both speed and altitude.

To be able to relate kinetic energy to potential energy in the proper way to get one single expression for the energy you desire, you need to perform some operations. The actual equations are a bit more involved, but you'll notice that eventually mass can be removed. It's also incomplete, since it's an approximation, but it looks like:

energy = v^2 + altitude * g

it is possible that altitude control no happens in this loop, but this expression remained as the most simple explanation.

Comment by Marooned on August 26, 2012 at 12:21am

Agree. When flying with Stabilize mode it requires constant throttle stick manipulation and every roll/pitch/yaw changes requires to pull up a throttle and then step back a bit. Would be good if roll/pitch/yaw try to maintain vertical thrust for hold the altitude.

Comment by Gerard Toonstra on August 26, 2012 at 1:32am

Well, you could argue that stabilize mode is only about keeping the craft at a desired angle. You might want to zip along something in a slight descent or ascent. A colleague of mine recently noticed that throttle settings on the radio are also interpreted differently depending on the mode you fly in. That requires one to think about that specific exclusion within the range of modes where the throttle should be in a different position. he took off in ful auto, then pulled the stick back because you don't need it, then eventuall went into loiter or something and suddenly the radio setting was the one applied to the rotors. Took a dive from 20m.

Could be an interesting experience to safeguard users from such mistakes by verifying throttle setting after mode changes or always go into some intermediate alt-hold mode, so that users are required to actuate the throttle to move up first, then move down.


Developer
Comment by leonardthall on August 26, 2012 at 3:33am

I agree that Stabilize mode is not supposed to add throttle boost as the quad banks. I personally like the manual throttle in Stabilize mode once I offset the throttle center and added expo.

However, I believe that Altitude Hold mode could fill the role that Marooned is after. Currently it is set up to increase and decrease altitude by a fixed rate. If it was set up to increase and decrease altitude proportional to throttle stick input with a significant central dead band.

This reminds me I didn't add the angle boost.


Developer
Comment by Jason Short on August 26, 2012 at 5:32pm

I can shed some light on the controller design. It started as a basic PID. Then I started calculating climb_rate, I changed it to a rate controlled PID. The desired speed is a PI calc using the altitude error. Later I realized we can't change altitudes well without running up the outer loop's I term so I froze that term when the error was too high. That didn't go well and we had a few fly aways in the SIM so I built an altitude manager to slowly change the altitude from one level to another. That worked better, but the outer loop's I term still would build up. 

Recently I switched to an alternate rate controller and ditched the altitude manager. (although I still use it to know if we are going up, down, or holding). 

Now the controller is fed a desired rate, and the controller manages a PID loop using climb_rate error as input. The feed forward part (I guess), is the same as the navigation controller. Basically, it's an estimation of the air resistance vs climb_rate. It was developed in the simulator and worked so well for the nav loop I applied it to the altitude control loop. It is tunable and can be turned off with a 0. 

The Outer loops I term is basically a slow guess at the throttle hold set point. It's applied directly to the output and has been tested not to interfere with the inner rate I term. 

The inner loop really needs the best possible climb_rate calculation. The main idea is we finish an inertial solution and pump that into the controller vs the barometer's slow and noisy climb_rate. I've tested that and even implemented that with really good success. The rate_P term in the inner loop can go up to 10x with smooth and low latency climb_rate values.

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service