Altitude loss after fast forward flight

Joined
Jun 17, 2015
Messages
602
Reaction score
158
I know some here were seeing or complaining about this.

Basically, the Solo would/could lose altitude if you were in very fast forward flight.

Here's a bug report:
https://github.com/diydrones/ardupilot/issues/1277

Here's a post and some discussions about it:
http://diydrones.com/forum/topics/copter-3-3-beta-testing?commentId=705844:Comment:2071638

Summary from the thread:
There have been discussions on software solutions but at heart, it's a frame issue. A frame that's built with the baro effect in mind does not suffer from this effect. An IRIS for example does not suffer from this because it has somewhat balanced air holes on the top and bottom. A Solo does suffer from the problem because it's a closed top with a large hole on the bottom for the gimbal.

If we want to discuss this item further could someone create a separate discussion and post a link?

Further discussion was taken here:
http://diydrones.com/forum/topics/effects-of-frame-design-on-barometer-performance-and-all-other

I hope this is helpful to some of you. For me, I don't care to worry about very fast forward flight, the Solo is a camera ship to me.
 
Last edited:
I know some here were seeing or complaining about this.

Basically, the Solo would/could lose altitude if you were in very fast forward flight.

Here's a bug report:
https://github.com/diydrones/ardupilot/issues/1277

Here's a post and some discussions about it:
http://diydrones.com/forum/topics/copter-3-3-beta-testing?commentId=705844:Comment:2071638

Summary from the thread:


Further discussion was taken here:
http://diydrones.com/forum/topics/effects-of-frame-design-on-barometer-performance-and-all-other

I hope this is helpful to some of you. For me, I don't care to worry about very fast forward flight, the Solo is a camera ship to me.
Yeah, I don't care about FF flight either as the flying I do does not require me to be in a hurry. But I did do testing on this in another thread and found that the Solo was able to maintain altitude until about 35mph, beyond that it started dropping. But it was also due to pitching forward over a certain amount. If you gradually increased speed you could get to about 35-38mph and hold it with out losing altitude. But if you were in a mode that allowed you to pitch forward more for a faster increase in speed, it would start losing altitude at about 18-20mph. And that would be due more to physics I think than airflow over the barometer.
 
Yeah, I don't care about FF flight either as the flying I do does not require me to be in a hurry. But I did do testing on this in another thread and found that the Solo was able to maintain altitude until about 35mph, beyond that it started dropping. But it was also due to pitching forward over a certain amount. If you gradually increased speed you could get to about 35-38mph and hold it with out losing altitude. But if you were in a mode that allowed you to pitch forward more for a faster increase in speed, it would start losing altitude at about 18-20mph. And that would be due more to physics I think than airflow over the barometer.

Yes, its the angle of the propellers in relationship to horizontal when attempting to fly a rotorcraft forward at high rates of speed. The same happens to us when piloting a helicopter. There is a maximum angle of attack that the plane of the rotor can sustain where you cannot maintain a constant altitude. (the blade becomes more like the screw of an airplane then a planar wing).

It was originally a problem during transitional flight on a VTOL like an Osprey also - If forward speed was not enough to maintain sufficient airflow over the wings while transitioning, the aircraft would lose altitude. Now the VTOL software prevents that from happening.
 
It seems the discussion from developers thinks that the issue is that the internal barometer is getting a false indication that the Solo was climbing, due to air pressure differences inside of the Solo, and this caused the computer to try to compensate by causing it to fly lower.

You have to read the threads that I included to understand the full ramifications of the issue. It's not as simple as the angle of attack of the props, etc. ;)

This post in the bug report has some good info and a nice graphic:
https://github.com/diydrones/ardupilot/issues/1277#issuecomment-55395092
 
It seems the discussion from developers thinks that the issue is that the internal barometer is getting a false indication that the Solo was climbing, due to air pressure differences inside of the Solo, and this caused the computer to try to compensate by causing it to fly lower.

Appears my "guess" from the other thread might be right.

pressure changes (turbulence) inside the body. Pretty sure most baro sensors for altitude are susceptible to turbulence. Just my guess(es)

Regardless its a flaw if you personally need that speed or not. Some of us bought the Solo because it was supposed to fly 55 mph in manual (alt hold). In the end it doesn't.

Maybe they will get around to fixing it so it can meet spec.

@Dunginhawk
 
It certainly does lose altitude at Rabbit Speed.... it should not.
 
Yea I can see where pitch and barometer turbulence errors could go hand and hand.
 
Any fix for this? I definitely lose altitude with rabbit speed. I would assume that this shouldn't happen.
 
My solo is now swimming with the fish south of Pahoa (in a non-diveable location), possibly due to this issue. See Solo Submarine - Awaiting 3DR response. for details. Hopefully it gets replaced. The only things I'll be able to send them if I DO get an RMA # will be the controller and a bottle of seawater.

I noted in my logs that the density altitude (barometer, z position) measurements seem to agree very well with the GPS, so I don't know if this is actually a sensor issue or if the higher speed settings allow so much forward pitch that the vertical component of thrust isn't enough to keep the Solo in the air.

If the latter is the case, especially in "fly" mode, this is a software problem IMHO. I can see allowing an altitude/speed tradeoff in some of the less-automated flight modes, but it shouldn't ever be an issue in what is meant to be "flying camera tripod" mode.
 
My solo is now swimming with the fish south of Pahoa (in a non-diveable location), possibly due to this issue. See Solo Submarine - Awaiting 3DR response. for details. Hopefully it gets replaced. The only things I'll be able to send them if I DO get an RMA # will be the controller and a bottle of seawater.

I noted in my logs that the density altitude (barometer, z position) measurements seem to agree very well with the GPS, so I don't know if this is actually a sensor issue or if the higher speed settings allow so much forward pitch that the vertical component of thrust isn't enough to keep the Solo in the air.

If the latter is the case, especially in "fly" mode, this is a software problem IMHO. I can see allowing an altitude/speed tradeoff in some of the less-automated flight modes, but it shouldn't ever be an issue in what is meant to be "flying camera tripod" mode.
Looks to be 35-37 degree AOA on inpact. What was the wind direction?
 
Looks like it had some headwind. It definitely went down due to the high forward pitch. Not a lot of time to react with that high of sink rate. I could see the drone but couldn't really determine pitch at that distance so all I saw was loss of altitude. I had started another thread re: the crash as linked above.

Again, this isn't a barometer issue since GPS and density altitude are in agreement during the crash. The autopilot definitely COULD be written to prioritize altitude over speed, and it certainly SHOULD behave that way in any mode that automatically maintains altitude.
 
Last edited:

New Posts

Members online

No members online now.

Forum statistics

Threads
13,096
Messages
147,752
Members
16,069
Latest member
Mr M