Loosing altitude in Altitude Hold

This started off as just exploring the limits of my QAV500 but I have found something I haven’t been able to find an explanation for.

I started to increase ANGLE_MAX to see how much speed I could get without loosing altitude. Obviously as more thrust is used to propel the Quad forward then less is available to keep it up in the air.

So I was doing this test in Alt Hold mode and my first change from 45 degrees to 50 degrees left a fair amount of altitude drop but I expected the quad to return to the altitude that that it had been saved as but it didn’t. It lost near 20m during the Fast Forward Flight but DAlt (Desired Altitude) fell as well.

Any Ideas?

This shows the Altitude lost:
s560.photobucket.com/user/joel04 … 2.jpg.html

This shows my channel 3 was about middle and then I increase it as I notice the drop. I possibly didn’t actually raise it past 60% for it to rise but I just included this to show I didn’t lower it.
s560.photobucket.com/user/joel04 … 6.jpg.html

This is Throttle out. It’s maxed out so there is no way the Quad could maintain it’s height:
i560.photobucket.com/albums/ss50 … 55f961.jpg

This is the desired and actual Pitch:
s560.photobucket.com/user/joel04 … 7.jpg.html

And finally the GPS Speed:
s560.photobucket.com/user/joel04 … f.jpg.html
Happy Days

One contributing factor is most likely that the static pressure drops when the speed (airflow around flight controller housing) increases, thus the flight controller believes it’s climbing. The law says that total air pressure = dynamic (speed) pressure + Static (ambient) pressure. Since Alt Hold uses Static pressure, you get this effect. This can be seen in Alt Hold already in low speeds/wind changes. This said, sounds like a lot of altitude drop you got there - probably more reasons than I described here(?)

Sent from my iPhone using Tapatalk

Loosing the altitude is not the problem.

It’s the fact that the desired altitude fell.

Happy Days

I completely understand it can’t actually maintain the altitude. :wink:

The problem is the set altitude changes. :unamused:

If it’s happy to change altitude then what’s the point. Once the altitude is set then it should try and maintain it. if something phyically makes the altitude change such as wind, even if it uses 100% throttle to attempt to maintian it, once the external force is removed it should return to the set altitude.

Happy Days

Hm, and there was something about prioritising altitude when pushing it with speed in the new update. This don’t make sense to me!

Sent from my iPhone using Tapatalk

[quote=“Flyhard”]Hm, and there was something about prioritising altitude when pushing it with speed in the new update. This don’t make sense to me!

Sent from my iPhone using Tapatalk[/quote]

Thanks mate.

Gives me something to search for.

Happy Days

[quote=“Flyhard”]Hm, and there was something about prioritising altitude when pushing it with speed in the new update. This don’t make sense to me!

Sent from my iPhone using Tapatalk[/quote]

It seems this is in relation to Way Point speed vs altitude. Altitude takes priority over speed. So if you set the Way Point speed at 15m/s and it requires too much pitch to acheive that speed then it will loose altitude however as Altitude takes priority then it will slow up rather than loose altitude.

Happy Days

Ah, should of course be in relation to GPS based flight. This rule applies in LOITER flight as well I take it?

Sent from my iPhone using Tapatalk

Not sure about loiter or any other GPS based flight but definatly flying to Way Points with the Way Point speed setting.

I shouldn’t have been so specific in my post in saying 15m/s. That was only as an example. Apparently I can’t edit my post.

Happy Days

Ok.

I mean If you don’t have a pitot airspeed sensor, we’re only left with GPS ground speed input for any speed input, right. Danger here is that a limit for example 10 m/s din only ground speed that don’t take into account any headwind. Had a suspicious crash myself in loiter once, where I had the limit 10m/s set, but gusts that day was at 7 m/s thus resulting that my poor APM 2.5 had to fight 17 m/s headwind resulting in a violent forward pitch trying to catch up my fully forward command and down it went. No wind issues in your case?

Sent from my iPhone using Tapatalk

[quote=“Flyhard”]Ok.

I mean If you don’t have a pitot airspeed sensor, we’re only left with GPS ground speed input for any speed input, right. Danger here is that a limit for example 10 m/s din only ground speed that don’t take into account any headwind. Had a suspicious crash myself in loiter once, where I had the limit 10m/s set, but gusts that day was at 7 m/s thus resulting that my poor APM 2.5 had to fight 17 m/s headwind resulting in a violent forward pitch trying to catch up my fully forward command and down it went. No wind issues in your case?

Sent from my iPhone using Tapatalk[/quote]

Ok, got it.

So when you crashed in Loiter, were you flying on the stick and saw it go down? Couldn’t have you just backed off the stick a little. As I understand the Altitude Priority thing should now prevent it loosing altitude for speed.

My speed tests have only been line of sight and I can see it dropping as I am flying above trees. The clearing I have is more than big enough for taking off and landing but too short for speed. Once it drops too much I back off the stick, it stops falling and it levels out but it doesn’t go back up again.

I just don’t understand why I the DAlt (Desired Altitude) doesn’t stay at what it is when I change to Alt Hold mode. We should see the log file graph a straight line for the DAlt and tha falling line for the Alt (Actual Altitude). Then once the pitch is reduce there is more power avalible for vertical flight and the Aircraft should return to the DAlt.

Happy Days

Yeah, dalt should be fixed! Sounds like a bug (Guessing!!)

It was on the old firmware without the protection. Yes, line of sight. Very quick event. The sudden pitch forward was immediately followed by total loss of directional control and violent wobble all over, but head up, so I had some thrust authority managing a soft decent with full thrust whilst trying Stabilise and loiter modes on the way down and cyclic and yaw inputs. Graphs go all over, but my throttle output went 100% at event start, so something went severely wrong. No hardware malfunction, flight controller might gotten loose in mid air maybe, but IMU data is too smooth for that I believe. I think the APM might have been saturated due to all gust inputs and my inputs. (It was a very windy day in a moutaneouua region) My pixhawk is much more stable in gusts and seem to process such things better.

Sent from my iPhone using Tapatalk

And yes, flying on stick with full forward.

Sent from my iPhone using Tapatalk

Just a thought, you don’t accidentally have some mixing active on your radio screwing around with throttle commands or anything else radio related that lowers your dalt input?

Sent from my iPhone using Tapatalk

[quote=“Flyhard”]Just a thought, you don’t accidentally have some mixing active on your radio screwing around with throttle commands or anything else radio related that lowers your dalt input?

Sent from my iPhone using Tapatalk[/quote]

Nah, mate.

One of the pictures I posted in input channel 3 which is throttle. So comfirmed both on the radio and log of Pixhawk input.

Happy Days

Ah!

Sent from my iPhone using Tapatalk

This is by design. When the copter cannot maintain the target altitude, the altitude target is dragged around by the actual altitude, so it will not hold. This was a design decision, not a bug. There are similar decisions made in several places in the code, such as in yaw, where if the error is greater than 10°, it will start dragging the target yaw around.

Obviously, in some situations this is not desirable. But in other cases, having the system suddenly and unexpected spring back to some maintained setpoint would also be a problem. It was decided that having the system accept these errors felt more natural, and was the better compromise.

Note that this does not happen in something like a Waypoint mode, where the target altitude is rigid.

Any easy way to determine what parameter caused this drift of dalt?

Sent from my iPhone using Tapatalk

Thanks Rob,

I’ve been busy to reply and say thanks for answering my question. I want to discus further but I’ve still been busy to fly ans test further.

I have done a little flying though and I think I can answer “Flyhard” and say it’s a combination of max throttle and falling altitude changes Dalt. In the little extra flying I have done it’s easy to see in the log that as soon as the throttle hits maximum the Dalt will follow the actual altitude.

Happy Days.