MultiWii

Hi,

I am looking to improve the altitude hold in MW. In the past I implemented my own FC and the alt hold was based on Arducopter code. The alt hold worked brilliantly, I could engage it in any scenario (there was no need for stable fight beforehand), it also worked a treat in all weather conditions.
I've never managed to achieve anything similar to that in MW.

Are there any views on this (licencing should be ok), any obstacles, anything else before I dive into this again? It might be a little bit on a heavy side (size- and computation wise) but would this be a problem?

Here is an overview of the approach. AFAIK the code loosely follows the diagram:
http://ardupilot.org/copter/_images/Alt ... -3.0.1.jpg

You asked for the views. Here is mine

After spending good amount of time collecting real-time logs of sensor inputs and tuning PID controller in-flight, I've concluded that MW althold code is adequate, at least for the set of sensors I use (MS5611,MPU6050). I've built three very differently sized multicopters thus far and all three hold altitude quite well. In fact I fly almost exclusively in althold mode. The only minor tweak to the code I found useful was to reduce improve responsiveness by mixing stick input to D-term. See this thread for description viewtopic.php?f=8&t=4992

As for the diagram you posted, I do not see anything there that would mean significantly improved performance. Maybe I missing something, but it seems just like another re-hash of the same mixing together two noisy inputs.

Thanks happul3, looks like you have spent decent amount of time looking into it. What approach did you take to set the alt pids?

Here is an example of alt hold I had before https://youtu.be/lyR4wM2C4sA?t=48 I have never managed to achieve anything similar with MW

gregd72002 wrote:Thanks happul3, looks like you have spent decent amount of time looking into it. What approach did you take to set the alt pids?

Here is an example of alt hold I had before https://youtu.be/lyR4wM2C4sA?t=48 I have never managed to achieve anything similar with MW

Nice build, nice stability. And yes, I have similar stability in no wind with MW, but I was never brave enough to get my hand close to what amounts to flying blender

To answer your question about setting althold PIDs, I run customized MW that includes special flight modes for real-time PID tuning with two pots. It makes the tuning process faster and less sensitive to ever-changing conditions. But otherwise it is a pretty standard process: (1) reduce P,I,D to make sure you are below optimum (2) increase P until see oscillations then reduce 20% (3) increase D till see overall reduction in stability (it does not look like oscillation, more random jumping, difficult to describe) than reduce 20% (4) increase I until see slow oscillations then reduce 20% (5) optionally repeat steps 2 and 3 few times trying to find a workable combination with sizeable D

You can trade P,I and D values to some degree; experiment and see what work best for you. Just remember that that P-term and I-term get input only from baro sensor. If your tuning somehow ends up with very low contribution of D-term to overall PID, the stability will suffer. You *must* have substantial D-term to utilize both sensors (baro and acc) for althold. This may be specific to MW... It also helps if you can see PID terms in real-time - you may want to modify code to make the visible in GUI (through debug[], for example).

Aside from tuning, there may be an issue with user input in althold mode. You mentioned engaging althold in scenarios other than stable hover. The question is, how would MW know what pilot wants after althold is engaged? Obviously, it relies on neutral position of throttle stick to interpret pilot input: above neutral means go up and below means down. But the neutral position is determined during althold engage moment and the kicker is that the pilot is expected to remember that stick position for the remainder of althold flight. I wonder if people are complaining about MW althold stability partly because they are actually giving minor up/down input without even realizing it. When I was getting to know MW and standard RC radios I remember I hated this, and from that point on I physically modify transmitters by spring-loading throttle stick the same way other sticks are. Combined with code change to fix neutral at 1500, it completely eliminates uncertainty there - all I have to do is to release the throttle stick and I know that FC will keep multicopter at the same height in althold mode.

Guess what, it works! I've suppressed RC throttle in BARO mode and it keeps the altitude perfectly fine

I might start using ALT_HOLD_THROTTLE_MIDPOINT, it feels an oversight that one cannot set it without re-compilation - the MIDPOINT will be different for different batteries I use...