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.
Leonard, it's so refreshing to find these issues discussed. I have renewed interest in getting my 3DR APM quad to do the best that it can with the current code. There are plenty of of other challenges like which camera, how to mount/gimbal and so on.
I have my Spektrum DX7s Tx set for the same three flight modes with Ch 5; Stabilize, Alt Hold and Loiter. The RTL has me scared so I haven't done that. I mostly fly in my backyard with looming tree limbs; I need to get out in the open.
Yes, thanks to the Dev team for coding; I was thanking you for digging into, understanding it and asking all the right questions.
Your comments are not a waste of my time at all; quite the opposite. I don't want to highjack this thread so I'll stay tuned for developments. Your five suggestions are spot on. If only throttle sensitivity was addressed, I think I'd be able to make the moves I want. I've not had any luck with finding a PID to "desensitize" throttle.
I've not even tried Acro mode (yet). My experience with Stabilize and Alt Hold have made me nervous enough. Maybe I need to 'fortify' myself with an IPA and just 'go for it!'
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!
Phil, you might want to look at the Quadrino controller for simple rc flying if autonomous flight is not what your'e interested in. It uses the Multiwii software, which still comes with some setup & tuning, but it's less effort then the APM. I've been flying my 3DR quad with one while waiting for the APM2.5, and was impressed. It's still more work then a Naza, but also a good bit cheaper. I'm back on APM now.
Regards,
Knut
Leonard, I'm all for your comment about "fill the role that Marooned is after."
Can you clarify your comment about the "increase and decrease altitude by a fixed rate" comment? Thanks. I would love to see a way to maintain altitude with only gentle adjustments. And no 'exit' trauma either.
Thanks for all the work on the code. I only 'get' a glimmer of the principles behind the PIDs. I understand feedback loops and much of the rest but the precise coding is a mystery.
I know that I have over 50 years of RC experience and fly a Stryker F-27Q for relaxation so I know how to fly. I expected my 3DR quad to be easy and it's not. I made the mistaken assumption that hover-in-place would be the first easy step in flying. Not!
I now I glean that the all purpose APM has much of its functionality (and development) in autonomous flight which doesn't interest me at all. I want to gracefully move around as an airborne camera dolly. I'll keep tweaking even though I have diminishing faith that I'll be able to achieve my goals with the APM2.
It's so enticing to see YouTube of two guys (Japan, China?) with a quad indoors in a hallway pushing by hand the thing back and forth and it's like it's on rails. Altitude is fixed. Wow! How do they do it when I can't?
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