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.
Comments
Hi Rick, Now that video is pretty cool :)
The people coming to quads that have been flying Helli's can often achieve this level of height control while talking and tying their shoes. One of the reasons for this is they know how to set up the throttle on their radio. That is where I got the pointers when I had the same trouble you were having (one click going up, one click going down, no hover in between)
So now I take the ratchet feel off my throttle stick (generally you have to undo a screw to adjust this in your radio)
Move the center of the throttle to be hover.
Add expo to reduce the sensitivity around hover.
We also have an auto pilot though and the new version of the code has implemented a gradual increase and decrease in altitude in ALT HOLD mode with a dead band. If I was to try to do this for the first time I would probably do it in ALT HOLD even though after the changes above I am getting pretty good with my throttle control.
Let me know how you go with my suggestions (I have heard some radios don't support what everything I am suggesting).
It sounds like I have been wrestling with the same problem for several weeks. I keep seeing video's of other flyers maintaining elevation while flying fpv? I'm spending so much time trying to keep a constant elevation....how could I ever do this - https://www.youtube.com/watch?v=WzuIWYtGomw&feature=channel&...
One notch on the throttle our quad will gradually rise and then one notch down and the quad will gradually start going down.
Maybe the APM2 can not do this ?
Thanks for that Phil,
I would say don't bother with acro mode it isn't worth it unless you can fly stabilized with manual throttle easily.
I do most of my testing in my front yard under a gum tree as well so I know what you mean about being nervous about throttle :) I found getting out in a big open space really helped me get my confidence going because I could always punch throttle to get away from any obstetrical (mainly the ground). In fact, most of my learning to fly was done in the Simpson Desert :) I will have to post a video of that as well.
Hi Phil,
To answer your question. The Altitude Hold is set up like an up, down, hold system. Currently if you push the throttle slowly up to the top you will reach a point (80%) at which the copter will attempt to increase altitude by 1.8m/s and below 20% throttle it will attempt to drop by 1.2m/s. This makes small altitude changes difficult and slow altitude changes impossible using altitude hold.
I have not contributed to the code at all.... yet.... hopefully. So I assume your thanks are going to the Dev Team. However I do see an opportunity to make improvements in the "Fly by wire" aspect of the APM2. Thankfully most of the really hard stuff has been done and is working very well! I am putting together a set of ideas that I will put up on my blog soon (I need to do the diagrams). The problems I am trying to suggest solutions to are:
1. Setting up the Altitude hold mode to be more "fly by wire". (obvious solution)
2. Minimising the throttle problems switching between Altitude Hold or one of the other auto modes and Stabilised or Acro mode.
3. Making the Acro mode feel right.
4. Make moving from flying with Stabilised to flying with Acro much easier.
5. Making the new Acro mode work in all orientations.
I can see places in the code where parts of these ideas have been tried but just missed the mark... Maybe.... And this is why I want to bounce some of these ideas around and learn from others mistakes :)
I think I want to use the APM2 in a similar way to you so what I have added below may help. If it doesn't I am sorry for wasting your time :)
I chose the APM2 because it could do everything I wanted with a camera gimbal, and had a Return To Launch, Stabilize, Altitude Hold and Loiter. As this was my first copter like aircraft (started flying gliders when I was 14) I figured I could use these features to learn more effectively. It worked for me.
I set a three position switch to Stabilize - Altitude Hold - Loiter and I have a second switch that sets Ch7 to Return To Launch.
I started by just learning to hover in Stabilize, then I switched to Altitude Hold and worked out how to move around and how the three axis work together (this was strange until I realized how the pids worked). If I needed to take a breath I would switch to Loiter, work out what I needed to do then back to one of the other two.
Return To Launch was always there to bring it back to me if I got things back to front.
When I am filming I often switch to altitude hold to move around at that level smoothly, but I find it too abrupt for changing levels when low (under 5m).
Thanks for the discussion!
Thanks!
Most of the work has been a long experimentation over the last few years. Almost all of it has been derived experimentally. Any feedback is appreciated!
Jason
Thanks for your time Jason! It helps a great deal to understand how the code was developed!
I have been thinking about the Integrator vs Cruze Offset. I like this setup because the separate integrator can quickly account for changes in throttle during forward flight and ESC non linearities, while Cruze setting allows is potentially useful for switching between modes.
I realize that you probably get this pretty regularly but I really appreciate all the work that yourself and the other members of the development team have done, the IMU especially is something to behold!
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)
This is based on air resistance.
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)
I have no idea who put that there.
Why didn't we get rid of the rate squared term and just use the PID loop?
The noise in the climb_rate was making altitude changes very difficult. My copter wouldn't even take off from the ground without it.
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.
The outer loop I and throttle cruise are/should be the same variable. History has lead us to the version we have now. Designing it from scratch, I would make these two the same.
Jason
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.
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.
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.
-
1
-
2
of 2 Next