AC3.2rc2 Altitude loss after forward flight

[Jaime Machuca]

Today I did some test flights with AC3.2rc2, I noticed that after forward flight when stopping the copter losses between 1-3 meters in altitude when stopping. Is there a parameter I need to tweak to fix this? or is this an issue? Also this only happens with forward flight and not with backward flight, and it also is not present with AC3.1.X. 

This is a screenshot from the log:

This is the video matching this portion of the flight:

https://www.dropbox.com/s/topxy39kwmmotkq/IMG_2520.MOV

I can provide the log if anyone is interested.

Best Regardos / Saludos,

Jaime Machuca Mercado

[Randy Mackay]

Jaime,

 

     There’s a long standing issue that sounds exactly like this but it’s caused by an aerodynamic effect on the baro.  It should exist in AC3.1.5 though as well.

 

     If you have low vibrations you should be able to increase the INAV_TC_Z from 5 to 7 and you should see the effect becomes less.

 

-Randy

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Pawlak]

I am testing a new octo-quad which is almost unflyable in auto modes because of this. I did an experiment a while back with a modified static system which improved the situation on a 3DR X8. I will be puting an improved version on my new octo.

In any case today I will be testing a "windshield" on my new octo. My pixhawk is pretty much on top of the main center hub and directly exposed to wind. I have a feeling that air is entering the SD slot and causing pressure differencial inside the Pixhawk. I noticed that as speed builds up, and even before I begin to slow down, the copter begins to lose altitude. I saw this same effect on the 3DR X8, but less pronounced.

So I'll report back on the "windsheild tests". I don't expect complete relief, but I hope to see at least enough to be able to do an auto mission.

[Jaime Machuca]

I had read about that issue, but I don't think this is it because I don't have this issue with the 3.1.x firmware. And I would think if it's this barometer issue, wouldn't it happen in forward AND backward flight also?

Best regards,

Jaime Machuca

[mlloyd]

I have this problem too. After extensive testing I've concluded that it only affects forward and rightward flight. Alt hold is perfect in backward and leftward flying. I haven't tried with 3.1.x. Could this be a software bug? The Pixhawk has openings on all four sides (front: SD card; right: USB; left: reset pin; back: RC pins) and it's odd this effect is so asymmetric...

[Chris Anderson]

One of the issues is that if you're going fast in auto modes into a wind, the angle of the copter may be so extreme that it limits the ability to hold altitude. I think in 3.2, we're now privileging altitude over ground speed. so if it can't maintain altitude it slows down. 

Randy, is that right?

Chris Anderson

CEO, 3D Robotics

ch...@3drobotics.com

[Jaime Machuca]

Yes, but this was not in an auto mode, it was while flying in Stab, and the speed was very slow, and also the distance traveled was only about 10m. Even if I slowly move the copter a few meters forward I get a drop in altitude. Also if this was an issue with the Baro, I would expect then that in order for the copter to drop altitude, that the barometer is actually seeing an altitude increase and hence it compensates by trying to go down. This in turn if it were a problem with the Baro data would cause a discrepancy between the GPS Alt and the Baro altitude, and in this case they seem to track each other (Ok, but the GPS is much slower than the baro). I also remember something about a throttle compensation being added, could this be that I don’t have that setup correctly?

Green is GPS, Red is Baro.

Best Regardos / Saludos,

Jaime Machuca Mercado

[David Pawlak]

Nope! Worse. Any airspeed whatsoever and it starts to drop. And then it's worse as you try to come to a stop.

So I'm going to put my improved static system on this buggy. My 3DR X8 with the minimal static system flies better, and has absolutely no drop in any direction but forward. Without the static system it drops a bit in reverse too.

While it sounds like Jaime's is different, this is still quite an issue.

I can make a static system that works for mine, but each configuration is likely to be different.

[Jaime Machuca]

This is interesting because I have a much more subtle altitude drop in auto mode. It actually keeps altitude pretty well in auto, it drops a little but then recovers as expected, In stab it seems that as long as I go forward it keeps loosing altitude, it never stops unless I throttle up.

Jaime Machuca Mercado

[Jason Short]

If this is in alt hold modes could it be vibrations? The rear props kick in and you loose altitude?

Does it also happen asymmetrically in Acro? Acro does not use throttle tilt compensation.

Jason

On Jul 6, 2014, at 10:59 PM, Jaime Machuca <ja...@droidika.com> wrote:

Today I did some test flights with AC3.2rc2, I noticed that after forward flight when stopping the copter losses between 1-3 meters in altitude when stopping. Is there a parameter I need to tweak to fix this? or is this an issue? Also this only happens with forward flight and not with backward flight, and it also is not present with AC3.1.X. 

This is a screenshot from the log:

<Screen Shot 2014-07-07 at 12.38.46 AM.png>

This is the video matching this portion of the flight:

https://www.dropbox.com/s/topxy39kwmmotkq/IMG_2520.MOV

I can provide the log if anyone is interested.

Best Regardos / Saludos,

Jaime Machuca Mercado

[Jaime Machuca]

I have not tried Acro yet. I’ll try it later today, but my vibration levels seems to be ok.

Best Regardos / Saludos,

Jaime Machuca Mercado

Este correo electrónico y cualquier archivo transmitido en él, son confidenciales y para uso exclusivo de los individuos y entidades a quienes está dirigido. Si usted no es el destinatario previsto o la persona encargada de recibirlo, y tiene por error este mensaje, queda prohibido y sin validez el uso, difusión, re-envío, reimpresión o copia. Toda oferta y/o aceptación de propuestas comerciales, celebración de contratos u otros actos tendientes a la adquisición de bienes o servicios, así como el establecimiento de cualquier clase de obligación legal para Droidika S.A. de C.V., deberá confirmarse por escrito firmado autógrafamente por funcionario competente, excepto que se cuente con un contrato vigente que autorice el uso de este medio para tales fines. Si usted recibió este correo por equivocación, favor de notificar inmediatamente por este medio a su remitente, y después borrarlo de su correo

[Robert Lefebvre]

I didn't realize at first that you were talking about this happening in Stab mode. I had assumed it was Alt Hold or Auto.  That is very strange then.  

[Jaime Machuca]

Sorry Robert, this statement:

"Yes, but this was not in an auto mode, it was while flying in Stab, and the speed was very sl….”

Is wrong!, I meant to say Loiter. So it is an Alt-hold mode. 

Best Regardos / Saludos,

Jaime Machuca Mercado

CTO | Droidika | www.Droidika.com

Mail. Ja...@Droidika.com

Tel. +52 (33) 3777 5327

Cel. +52 1 (33) 3945 3350

Este correo electrónico y cualquier archivo transmitido en él, son confidenciales y para uso exclusivo de los individuos y entidades a quienes está dirigido. Si usted no es el destinatario previsto o la persona encargada de recibirlo, y tiene por error este mensaje, queda prohibido y sin validez el uso, difusión, re-envío, reimpresión o copia. Toda oferta y/o aceptación de propuestas comerciales, celebración de contratos u otros actos tendientes a la adquisición de bienes o servicios, así como el establecimiento de cualquier clase de obligación legal para Droidika S.A. de C.V., deberá confirmarse por escrito firmado autógrafamente por funcionario competente, excepto que se cuente con un contrato vigente que autorice el uso de este medio para tales fines. Si usted recibió este correo por equivocación, favor de notificar inmediatamente por este medio a su remitente, y después borrarlo de su correo

On Jul 7, 2014, at 1:05 PM, Robert Lefebvre <robert....@gmail.com> wrote:

I didn't realize at first that you were talking about this happening in Stab mode. I had assumed it was Alt Hold or Auto.  That is very strange then.  

On 7 July 2014 14:02, Jaime Machuca <ja...@droidika.com> wrote:

I have not tried Acro yet. I’ll try it later today, but my vibration levels seems to be ok.

<Screen Shot 2014-07-07 at 1.01.24 PM.png>

[Randy Mackay]

Jaime,

     Can you provide the log files?

 

     Chris is correct that AC3.2 properly prioritises altitude over horizontal position (AC3.1.x did not) so hopefully this is not the issue.

 

-Randy

[Jaime Machuca]

Its the same log as the one for the flip on take off crash. This part is about 1/3 of the log into the flight.

https://www.dropbox.com/s/c59e68bl6nnrltz/WithEKFandCrash.BIN

Best Regardos / Saludos,

Jaime Machuca

On Jul 7, 2014, at 8:02 PM, 'Randy Mackay' via drones-discuss <drones-...@googlegroups.com> wrote:

Jaime,

     Can you provide the log files?

 

     Chris is correct that AC3.2 properly prioritises altitude over horizontal position (AC3.1.x did not) so hopefully this is not the issue.

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Jaime Machuca
Sent: July 8, 2014 3:10 AM
To: drones-...@googlegroups.com
Subject: Re: [drones-discuss] AC3.2rc2 Altitude loss after forward flight

 

Sorry Robert, this statement:

 

"Yes, but this was not in an auto mode, it was while flying in Stab, and the speed was very sl….”

 

Is wrong!, I meant to say Loiter. So it is an Alt-hold mode. 

Best Regardos / Saludos,

 

Jaime Machuca Mercado

CTO | Droidika | www.Droidika.com

Mail. Ja...@Droidika.com

Tel. +52 (33) 3777 5327

Cel. +52 1 (33) 3945 3350

 

<image001.png>

[Randy Mackay]

Jaime,

 

     Thanks.

 

     So it looks like the aerodynamic effect that’s been mentioned a couple of times on this thread.  Looking at the attached pic of a part of the flight in “Hybrid” you can see how the baro alt is ok when the vehicle is pitched back but after leaning forward and then flattening out the Baro jumps up a few meters.  The increase in the baro alt pulls the inertial nav alt up and leads to the copter falling.  The same thing can be seen earlier in the log when in Loiter mode as well.

 

     This effect should be there in AC3.1.5 as well.

[Robert Lefebvre]

And it' quite possibly not a simple problem of Bernoulli, faster airflow, less pressure, etc.

It could be more complex dealing with airflows around around the frame at different frame angles, velocity, thrust level, etc.  That might be why is shows up more in one direction than the other, and only when stopping (leaning back vs. leaning forward).

[Jaime Machuca]

Well, I was able to get some test flying done before I had this issue with the compass. I did confirm that with AC3.1.5 there is no loss of altitude. Then I put master back on and there seems to be much less loss in loiter, but in Hybrid there is still a lot of altitude loss, specially when it starts to break. I still don’t think this is an aerodynamic effect. I’ll post logs in a bit.

Best Regardos / Saludos,

Jaime Machuca Mercado

Este correo electrónico y cualquier archivo transmitido en él, son confidenciales y para uso exclusivo de los individuos y entidades a quienes está dirigido. Si usted no es el destinatario previsto o la persona encargada de recibirlo, y tiene por error este mensaje, queda prohibido y sin validez el uso, difusión, re-envío, reimpresión o copia. Toda oferta y/o aceptación de propuestas comerciales, celebración de contratos u otros actos tendientes a la adquisición de bienes o servicios, así como el establecimiento de cualquier clase de obligación legal para Droidika S.A. de C.V., deberá confirmarse por escrito firmado autógrafamente por funcionario competente, excepto que se cuente con un contrato vigente que autorice el uso de este medio para tales fines. Si usted recibió este correo por equivocación, favor de notificar inmediatamente por este medio a su remitente, y después borrarlo de su correo

[David Pawlak]

I have a lot on mine, too much to do anything in auto. I assume the same problem exists in any mode that maintains altitude.

I can try putting 3.1.5 on my new octo. If it goes away, it will be very obvious. Alt Hold (which has the problem) is common to the two versions.

I don't go back in versions much. 3-1-5 is pre-EKF right? What happens to parameters? I'll save my present ones to come back to. Anything to watch out for going to 3.1.5?

 

If it doesn't go away, the next step would be to rig a static system.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jaime Machuca]

Well If you tuned the octo with EKF you may need to retune it. At least that's what I found when I went back to 3.1.5. I have not had much luck testing 3.2, every time I load a new version something else is weird. I think I need a guide to all things that could go wrong when moving to 3.2 hehe.. :)

Jaime Machuca Mercado

CTO | Droidika | www.Droidika.com

Mail. Ja...@Droidika.com

Tel. +52 (33) 3777 7327

Cel. +52 1 (33) 3945 3350

Sent from my iPhone

[Randy Mackay]

Jaime,

 

     There shouldn’t be any need to re-tune after switching to EKF.  If there’s a difference in the attitude solution then there’s probably an EKF setting that is incorrect.  The attitude solutions can be compared by setting USE_EKF to false and then compare the ATT.Roll vs EKF1.Roll and ATT.Pitch vs EKF1.Pitch.  If you see a large difference (i.e. more than 1 deg) then reporting it to Tridge and Paul Riseborough would be good.

 

>>>Then I put master back on and there seems to be much less loss in loiter, but in Hybrid there is still a lot of altitude loss, specially when it starts to break. I still don’t think this is an aerodynamic effect. I’ll post logs in a bit.

     The Hybrid and Loiter use the same altitude hold controller.  Hybrid’s breaking is likely making the aerodynamic effect more obvious.  I’ve already analysed your logs and posted a picture which clearly shows it’s the barometer that is dragging the altitude estimate up.

     I appreciate your testing but you should expect issues when flying beta firmware so no apologies.

Sorry Robert, this statement:

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.

[Jonathan Challinger]

Attached is a good example from your log of the effect on the baro.

The red line shows the increase in altitude from the baro, which causes the inav/ekf to drag the altitude solution in that direction. The alt solution is now "too high," so the copter descends. As the real altitude reaches its minimum, the baro starts indicating the correct altitude. The alt solution is dragged down and becomes "too low," causing the copter to rise back up gradually.

[David Pawlak]

This graph is quite representitve, as you say, of the problem. I have noticed the subtle change seen in this graph as velocity increases, but before it starts to come to a stop, there is a slight  loss of altitude as speed increases. You can see in the graph, that there is a slight negative slope in GPS Alt, leading to the point where the stop is initiated. I tested this, because I wondered if the effect only had to do with the pressure changes due to pitch angle or if increasing ram effect also contributed.

If you look at the red curve, there's a "slow" periodic correction (slightly underdamped) as speed increases. The recovery on pitch change (coincidentally?) follows a similar recovery period.

So it looks like theres a rate controller, albeit a potentially virtual one, which is compromised at higher rates. Perhaps it's not an explicit controller and therefore has not recieved "tuning attention (gain adjustments)"

Unfortunately I am not ready for software work for at least another month or two, we'll have a couple of programmers by then. There are several things I'm itching to get into.

As an aside, perhaps a year ago, well before Onion and EKF, I think I saw ad-hoc adjustments of pitch to adjust for altitude under various conditions. As I say, I unfortunately really haven't been able to get the time to delve in, but now that EKF and inav are working more as they should, these ad-hoc adjustments are no longer in there right, competing with inav? Sorry if that's out in left field, but  can't hurt to ask.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discuss+unsubscribe@googlegroups.com.

[Julien Dubois]

This is rather a hardware issue than a software. We could implement some patches to minimize the baro disturbance in the altitude controller during phasis we guess it's disturbed but, anyways, the right solution is in the design of a low disturbed baro.
There is another recent topic on drone-discuss and somebody tryed interesting things...

[Holger Steinhaus]

I think it's not even hardware, but physics: 1Pa of static pressure change is equivalent to about 8m of height difference. At the same time, you get 1Pa of ram pressure if you move a box with a hole in its front at 1.25 m/s (4,5 km/h). 

So from my point of view, the current AltHold performance is outstanding (I guess because of the influence of the INS). 

If you want to see a really bouncy AltHold, just try the following: wait for a windy day and look for a shady place in the lee of a large forrest. There will be almost no wind here. No activate AltHold - the copter will bounce up and down several 10m, just as a effect of the changes in air pressure due to the turbulence.

Holger

[Julien Dubois]

Of course, but by Hardware I wanted to say "an only fix in the program would not be enough".

As you said, dynamic pressure will increase with velocity on one side of the copter but it should decrease the same way on another side (probably the oposite).
So a design of pressure manifold getting and averaging pressures around the copter would give the static pressure = altitude.
I think somebody worked on it, duno if he's got good results

[mlloyd]

Is it possible that improvements in GPS accuracy with the new generation of GPS+GLONASS chips like MAX-M8Q might solve this problem by eliminating the need for a baro when outdoors?

[Julien Dubois]

Maybe a baro correction when GPS has small VDOP to compensate errors when velocity is high

--
You received this message because you are subscribed to a topic in the Google Groups "drones-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/drones-discuss/6lJ5M5OR-pw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to drones-discus...@googlegroups.com.

[David Pawlak]

@Holger

I heard that someone put electrical tape over the opening at the back of the Pixhawk and had an improvement. As a fast test, I tried a 1/4 shell type windshield around the pixhawk.... forget it. Worse. Even a 1m/s caused a fairly big drop. I guess it caused a "vacuum" around the Pixhawk. I also tried the tape at the back, but no change.

I guess I have to go with a modified static system mod that showed some results on my 3DR X8. 

[David Pawlak]

The weight of GPS input could be increased at critical times.

The physical solution is not a simple matter. An IRIS would be much different than a heavily loaded workhorse that has big batteries, and instruments like mine (the one that is just about unmanageable in auto modes.) I have a load of not so aerodynamic stuff hanging below. so I have to find relatively undisturbed air. What 30 cm above the deck?

BTW, the stuff hanging below CofG doesn't cause pitch down in flight. My first tests were without camara up front so C of G was slightly back. If anything the load below would cause pitch up as it decelerated.

Not too long ago this "physics problem" wasn't an issue. At one point it was manageable.

[mlloyd]

Maybe placing more trust in the accelerometer, or combining that with an estimate of what the actual vertical acceleration should be given our current thrust output, might also help. We already have angle boost, so if we maintained constant throttle, presumably we could maintain stable altitude in most circumstances too. I wonder whether this is what the Naza does - I never had issues with alt hold with Naza.

[David Pawlak]

I just did some tests (on 3.2-rc2) adjusting the "throttle for altitude PID". Doesn't really seem better, but I had a bit of wind that was messing with the results.

At first I was happy because it held altitude, but as I brought it back it dropped like a brick. The wind was coming from my back!

I turned around and flew into the wind, but it was difficult to really tell, it was kind of gusty and my gains on this new UAV are still a little squirely.

So I'm going to wait for calmer air and try to tweak her up properly.

On Monday, July 7, 2014 1:59:43 AM UTC-4, Jaime Machuca wrote:

Today I did some test flights with AC3.2rc2, I noticed that after forward flight when stopping the copter losses between 1-3 meters in altitude when stopping. Is there a parameter I need to tweak to fix this? or is this an issue? Also this only happens with forward flight and not with backward flight, and it also is not present with AC3.1.X. 

This is a screenshot from the log:

[Randy Mackay]

David,

 

      Because the problem is the baro affecting the attitude estimate, I’m not surprised that adjusting the altitude control gains doesn’t help.  You could reduce the gains on the control and then the actual altitude wouldn’t track the desired alt as well and this might gloss over the problem a bit.

 

     It’s really the alt estimate that needs help.  Adjusting the INAV_TC_Z to be a higher value (like 7) makes it rely more on the accels and less on the baro which should help but the downside is that the copter will be more susceptible to vibration affecting the altitude estimate.  So break a prop or bend a motor and it’s more likely the vehicle will climb rapidly.

 

     I did a video about a year ago where I tested various time constants and how it affects the alt drop issue.

          https://www.youtube.com/watch?v=Vn-Fg53Or4c

 

-Randy

--

You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.

[David Pawlak]

Thanks Randy, useful. I'll give it a try with 7 while I prepare the static system components.

Should at least get me going meantime. I assume that any auto-mode that uses alt hold in forward movement is affected by the same issue. I haven't flown this

octo in auto yet.

If the tests with 7 show improvement, I That's my next step.

Thanks.

[mlloyd]

Has anyone experimented with turning on EKF and tuning the EKF settings to reduce the alt drop issue?

[Tim F40]

I don't think I read an answer as to why Jaime doesn't see the alt issue with 3.1.5. It's implied that it's "coincidence". E.g., he must be flying 3.1.5 in different barometric conditions which don't exhibit the issue as much. As a software engineer, I don't like coincidences!

[Jaime Machuca]

I will do more testing this weekend hope fully in the morning when there is no wind and tryout 3.1.5 and 3.2 again. Hopefully on the same conditions then in theory if I don’t see it on 3.1.5 I should not see it in 3.2. Also this issue shows more in Hybrid mode when breaking and this is not present in 3.1.5 so I may not be able to test that out. This week I had some problems with the compass and with the Yaw, when I was testing due to other issues. Those seem to have been resolved now so I will give it a try over the weekend.

Jaime Machuca

On Jul 11, 2014, at 11:34 AM, Tim F40 <tim...@gmail.com> wrote:

I don't think I read an answer as to why Jaime doesn't see the alt issue with 3.1.5.  It's implied that it's "coincidence". E.g., he must be flying 3.1.5 in different barometric conditions which don't exhibit the issue as much. As a software engineer, I don't like coincidences!

[David Pawlak]

I changed INAV_TC_Z to 7 and tested in calm weather without a whole lot of improvement. Looking at the logs they seem better, I don't see a GPS altitude drop of more than about 2.5 m but it still feels uncomfortable.

And when it's windy and gusty, it's all exagerated.

@mlloyd, I was thinking about cahnging some of the EKF parameters. I usually have EKF turned on anyways. But I didn't this time, just wanted to test one change at a time.

I'm fairly disappointed. I am not going to be comfortable flying this new octo. This is a rebuild of a previous design, with slight adjustments to close in on a production design.

So I may try adjusting some EKF params, and then give the static system a shot.

It's not so much the "air bubble" over the craft that's the problem, as it is the fairly quick delta in pressure. I can fly forward fairly quickly without it dropping. I noticed it loses maybe 30 cm in forward flight, but you can see in the logs, it's the sudden change in pressure that messes it up. As soon as pitch starts to increase the pressure drops and the craft ove rcompensates.

If it were my code, and I could manage the learning curve, I would somehow try to reduce  the influence of the static pressure during descelleration. GPS altitude is very solid during those times, (and when it's working of course).

On Friday, July 11, 2014 6:57:20 AM UTC-4, David Pawlak wrote:

[David Pawlak]

@Jaime, Did you ever test with 3.1.5 again?

I tested again with 3.2-rc3. My tests are showing better results. They feel worse in person than they look in the logs. I did some tests with sustained forward velocity (withing the space I had - about 50m). I Remember I have INAV_TC_Z set to 7.

I notice that as the octo is accellerating it slowly loses altitude, about 1.3m, and then starts to compensate (fixed pitch and steady forward speed. It comes back up, more or less, to the correct altitude. When I stop, it drops much less. However if I accellerate and then descellerate before it starts to recomensate, It drops the whole 1.3 or more meters in the last few meters of trajectory.

The objective of my tests was to see what I might expect in an auto mission. There are usually no big changes in speed, and large trajectories of more or less constant speed. SO it seems it would drop initially and then stabilize during trajectory. It may be fairly wobbly in turns etc as a result of acceleration changes (affecting delta air pressure).

Even though the drop over the trajectory was less than two meters, it felt like to much for me to chance auto. And it would be worse in wind. 

I don't know, maybe I  have to play with PIDs. The octo weighs 6,1 kg w 15in props (hovers at 40% or a bit less). I adjusted them a little, only lightly lowering the rate P. It handles well, albeit a little aggressively in stab. It might be a touch overactive in PosHold in winds.

Still haven't put in the static system. It's a bit of a pain, I have to take the Pixhawk apart and drill holes, seal the alt sensor etc!!

[David Pawlak]

I have a configuration (in terms of Pixhawk placement) similar to the 3DR X8, and as a matter of fact, both my newest heavy octo-quad and the 3DR X8 have problems with this altitude loss after forward flight.

The heavy more-so, but not because it's heavy (I think), because it idles at a lower throttle that the 3DR and has PLENTY of power. Response is quite crisp in all other regimes.

Basically the Pixhawk is placed on the top plate, with a small platform carrying the compass about 7 cm above it. There is a lot of stuff below, batteries (4x4sx5000) inclosed in a single cartridge "block", camera etc. etc. The space below the top plate measures about 20x16 cm frontal area.

So I suspect that this may have a lot to do with some sort of pressure build up. It is amazingly sensitive. Even a couple of meters per second produces a drop effect.

For those of you who don't seem to have this problem, What are some of your physical configurations?

Also, do you all notice some effect of this issue, but it is light or is it not an issue at all for most of you?

[David Pawlak]

I have some good new to report here (at least from a personal functional standpoint, and probably from a theoretical stanpoint).

I finally got around to testing my modified static system on my 3DR X8, and the results were at least as good as I expected!.

If this is my X8 from the side: the Pixhawk is the small rectangle above the deck and the big rectangle is the payload, in this case batteries. Section A and B show hover and forward travel. The airflow comes from the right, and in forward travel it has to move around the mass splitting from top to bottom.

First of all the large mass creates a resistance which raises pressure in general. Part of the flow goes above and part goes below. The base platform supporting the Pixhawk provides an additional divisional barrier which plays with the wind.

One thing and another, the Pixhawk actually compensates to some extent in forward movement, as the acceleration is relatively slow. But when the vehicle stops, the divisional barrier makes a big change in the airflow, and pressure changes rapidly. The PIDs cannot react fast enough (if they are stable for normal flight), and the net result is that the vehicle falls.

In "C", I put the sensor as indicated, forward and below. It is in the general airstream, somewhat distant from the general pressure build up, but certainly not isolated. However even if pressures build, they are slow and the PIDs respond.

Later as the pitch changes, if anything, the sensor moves into air that may be slightly higher in pressure (more mid-stream). Any effect of pressure change, which would probably be slightly increasing, would tend to cause the control system to correct "up".

The net result is "success"! The X8 does not drop on deceleration. I tested lateral movement and also clean. The sensor "vane" is parallel to forward airflow, and for lateral flow has a hole which passes from side to side, feeding a "T" which leads to the altitude sensor.

Aside from the fact that 3.2-rc5 has a horrendous 5Hz wobble, this test has made my day.

[David Pawlak]

I posted over here https://groups.google.com/forum/#!topic/drones-discuss/SsYbCtSg92c

about a problem on the motor outputs, thinking it could have something to do with the 5 Hz pulsing problem reported over there... the frequency is about 5Hz or so.

But I took a closer look at the baro data, and it's possible (not sure if I'm imagining it) that there's some influence on the baro that is complicating things.

The arrangement has resolved the fall after forward flight, it's very flat! However this showed up.

The log is at the other link so as not to upload data unnecessarily.

I put a physical filter (sponge) in the tube leading to the static system, and a couple of vibration suppressors to hold the tube that was up against the frame, in case LF sound was getting into the tube and causing interference.

As soon as my batteries are charged, I'll give it another test.

As you see, effects are worse in alt hold modes.

[Craig Elder]

That's pretty interesting.  I look forward to reading more of your results.

[David Pawlak]

OK, I'm a pretty happy camper right now.

In the end, the pulsing was an ESC calibration. Dunno', I had to change my radio for another reason, and did the radio calibration earlier. But not all the motors where starting at the same time..

It wasn't too bad, so continued with the tests. After changing the tubing, as mentioned earlier I still had the pulsing so did the ESC cal. and everything as stable as a rock.

Did more flight tests for the stop after forward movement, and rock solid as well!! (probably more than ever. As a matter of fact sometimes it actually raises up about 10-15 cm at the end.) Lateral and reverse motion no problem. So I'm a happy camper!

Where the tube enters the Pixhawk, I drilled a small 1.5mm hole and epoxied a tube interface to the Pixhawk box. The altitude sensor cavity is sealed around the edges with plasticine, one might contemplate something more permanent. I didn't want to use silicone, because I didn't know what the acetic acid might do to the sensor. Perhaps epoxy putty would work, although that might make it difficult to remove the PCB at some later date.

The other end has the plastic "sensor interface", which has a 1.5mm hole drilled through it, left to right, and a "T" drilled to interface this horizontal hole to the silicone tube.

It's not pretty, but it works. I'll clean it up and repeat it for my bigger bird.

Pretty much validates the pressure bubble theory. I think the problem is worse for vehicles with large frontal areas. The pressure build up is not only above but in front as well. The flat plane of the body tends to produce fast pressure changes during the stopping process, which the sytem can't keep up with.

In my case, thepositioning of the sensor is such that it tends to drop into a lower pressure area during forward flight, and therefore, stopping, it helps to compensate the problem by coming back up into a slight higher pressure area. (My guess) still have to look at logs. My tests were fairly short, I'm not sure 

[David Pawlak]

Somehow pressed "post" early.

Not sure if there's enough data to see something certain. On my bigger X8 I have 25 minutes to test in, and the challenge is greater, so the data should be more conclusive.

[Emile Castelnuovo]

Very interesting.

Still don't understand how the competitors deal with all this.

I had a go at a Phantom yesterday, and besides the fact that I find it unusable and had really bad feeling piloting it (), I was pretty amazed how well yaw and altitude hold copes with any forward/lateral movement.

Really there is no whatsoever loss or gain in altitude when moving or stopping. I think we are missing something here.

If I fly my quad or X-Octo in stabilize and move forward, even giving full forward I see very little alitude change.

Now, this is due to the angle boost factor that helps the loss of thrust when tilted, and works pretty good.

Of course the moment you put the copter to level after fast forward flight it will rise like hell due to the air pushing under the props but this is known.

Looking at the code I realized that the angle_boost is never used in any automatic function, only in STABILIZE and DRIFT.

Does anyone know why?

Physics of tiled propellers loosing thrust is valid in all flight modes, why should we not consider this in whatsoever automatic flights?

Emile

[Randy Mackay]

Emile,

 

     I think angle-boost is used in AltHold, etc.   I’d love to find a bug in the code but I had a look at this a few days ago and I think it’s being applied:

 

     Alt hold calls pos_controller for Z-axis:

            https://github.com/diydrones/ardupilot/blob/master/ArduCopter/control_althold.pde#L78

 

     Bottom level of alt controller, accel_to_throttle, calls the attitude control’s set_throttle_out with ‘angle boost’ set to true.

            https://github.com/diydrones/ardupilot/blob/master/libraries/AC_AttitudeControl/AC_PosControl.cpp#L392

 

     Maybe you were thrown off by this line which sets the throttle to zero with angle boost false?

            https://github.com/diydrones/ardupilot/blob/master/ArduCopter/control_althold.pde#L32

 

-Randy

The log is at the other link so as not to upload data unnecessarily.

 

I put a physical filter (sponge) in the tube leading to the static system, and a couple of vibration suppressors to hold the tube that was up against the frame, in case LF sound was getting into the tube and causing interference.

 

As soon as my batteries are charged, I'll give it another test.

 

As you see, effects are worse in alt hold modes.

 

On Monday, July 7, 2014 1:59:43 AM UTC-4, Jaime Machuca wrote:

Today I did some test flights with AC3.2rc2, I noticed that after forward flight when stopping the copter losses between 1-3 meters in altitude when stopping. Is there a parameter I need to tweak to fix this? or is this an issue? Also this only happens with forward flight and not with backward flight, and it also is not present with AC3.1.X. 

 

This is a screenshot from the log:

 

 

This is the video matching this portion of the flight:

 

https://www.dropbox.com/s/topxy39kwmmotkq/IMG_2520.MOV

 

I can provide the log if anyone is interested.

 

 

 

Best Regardos / Saludos,

 

Jaime Machuca Mercado

 

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[john...@gmail.com]

My guess based on how DJI autopilots behave, is that they depend more on IMU dead reckoning in the short term to be able to avoid problems like this.

[Jonathan Challinger]

The phantom is obviously constructed with pretty careful attention to sensor placement. I saw one in my local hobby shop, it had what looked like the magnetometer or baro or both mounted on the landing gear.

They may also weight barometer less heavily than we do. Never flown one.

I will double check on the angle boost tomorrow (today).

[Julien Dubois]

I have built a quad using walkera qr-x350 and put an APM inside (no case, only black foam on baro)

I've noticed almost no altitude drop contrarly to my "open frame" copter that suffers greatly from this issue

So I've 2 hypothesis:
- the air pressure is very well balanced inside the frame. At first sight, we could think that's all but, from log, I can see the baro is disturbed anyways so that is not enough

- the frame aerodynamic helps keeping a constant altitude: during braking phasis even if throttle is reduced, the lift is produced by air under the tilted frame

This frame being very similar to phantom, I guess we would have the same perf.

I agree for the weight of the acc/baro that is the software fix to that issue

--
You received this message because you are subscribed to a topic in the Google Groups "drones-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/drones-discuss/6lJ5M5OR-pw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to drones-discus...@googlegroups.com.

[David Pawlak]

My Iris is in pieces at the moment.... perhaps I can see if I can reconstruct it. With it's enclosed frame, perhaps it is less affected by the problem. If there's someone out there with an Iris, maybe they can help with a few test runs on 3.2-rc7

However. I've had my 3DR X8 for a while now, and initially this wasn't a problem.

I can't really remember at which rev numbers it seemed to get worse, but at one point, it wasn't even something that came to mind. (Same frame)

So, 1) we know there is an aerodynamic disturbance, and we might say that refinements have made our autopilot more sensitive to the phenomenon, or we could say that in the process of refining, something got taken out or replaced without realizing it... 

Perhaps there's a software solution for susceptible frames. (Lets hope) I could try and dig into that.

A hardware solution probably isn't too viable, as there are just too many configurations to consider, although something like my configuration could probably work for a good number of those. (i.e. a good (better) design might be flexible enough to cover most configurations). In any case, it's not a modification for the faint of heart, especially when you start trying to seal the sensor area.

[Randy Mackay]

David,

 

     If you’ve got the X8, any chance you can do back-to-back as-similar-as-possible tests using AC3.1.5 vs AC3.2-rc7?

 

      There’s not really enough info here for me to track down where the issue might be.

 

-Randy

--

[Jonathan Challinger]

Angle boost is enabled in all auto modes, see AC_PosControl.cpp accel_to_throttle function.

[Craig Elder]

The Phantom has the magnetometer on one of the legs.

[Jonathan Challinger]

There's really no software solution to the problem, the best solution is to put a barb connector on the pixhawk's barometer to allow for attaching external probes. Measurement specialties makes a baro with a barb connector on it.

[David Pawlak]

The X8 has the new static interface installed, I'll have to whip up a new interface block which simulates initial sensor positioning (which had more or less the same results as an un-modified sensor system).

I'll verify that 32.-rc7 has the drop during deceleration, then change to 3.1.5 and repeat.

Might take a couple of days, I've only got one set of batteries for the x8 :p

[Marco Robustini]

@Jaime: when you've done these tests was very windy?
Have you tried to turn your drone around 180 degrees and repeat the same test?

Marco

[Marco Robustini]

@Jaime, from what I see in your video when flying against the wind the the quad goes down.
It 'a pretty normal effect when the quad tilts upwind, I assure you that it also does a Phantom with Naza.
If the parameters are set properly however this effect is almost non-existent.

https://www.youtube.com/watch?list=UUPcCCiqkWYZmvxVgHhDZDHA&feature=player_detailpage&v=zNwvxSH6JNQ#t=303

Marco

[David Pawlak]

Hi Marco,

I'm not Jaime, but I did tests upwind and downwind. It is a function of airspeed. On my big Octo which is much more affected (fairly large frontal area), it became almost impossible to fly in a windy day. Just hovering into the wind had it all over the place.

Obviously upwind it was worse. What I found, was that if I tired to maintain a constant forward airspeed, it would drop slightly as the airspeed increased, but stabilize and come back to the correct altitude as the delta velocity stabilized. Then stopping it would just about drop out of the sky.

I only have about 50m to work in so couldn't do a stable accel, maintain velocity and then do a slow stable deccel. I think if the deccel was slow it wouldn't fall as badly.

So it's the fast delta-V that has the most negative effect.

[Paul Riseborough]

Jamie,

You need to verify if this is a measurement error and/or a control error. If you are able to maintain an accurate visual height in stabilise mode, then you can perform some accelerate and stop manoeuvres, both up and down-wind. This should then be repeated in alt-hold mode. The logs from this flight will enable you to determine how much of the effect is measurement vs control error.

If as we suspect, it is a measurement error produced by airflow affecting the baro sensor, then there is something you can try. The weighting on the baro can be reduced by increasing the EKF_ALT_NOISE parameter. Any height measurement error with speed will still occur, but it will change more slowly. I would try doubling then tripling the parameter to see if makes a difference. The EKF uses GPS vertical velocity as a reference and also compensates for vertical accelerometer bias, so it should be able to handle a larger value for this parameter and still maintain acceptable height accuracy.

The longer term solution and something on my EKF to-do list is fusing in GPS height as part of the solution. This will need some thought into the implementation of error traps, but this could be based on the existing EKF GPS glitch logic.

Regards,

Paul

[Jaime Machuca]

Well I had put this to rest after it was deemed to be the aerodynamic effect issue. And I have not flown 3.2 with EKF since. I have still noticed that there is a drop in altitude on some of my copters. Currently I am quite busy trying to integrate a Hyperspectral camera on an OCTO, but I can probably do some testing over the weekend. 

So I can try with EKF on

Fly in Stab, 

Forward flight trying to keep the same altitude manually

Backward flight trying to keep the same altitude manually

Side to side trying to keep the same altitude manually

Fly in Alt-Hold

Forward flight

Backward Flight

Side to side

Fly in Loiter

Forward flight

Backward Flight

Side to side

Fly in PosHold (Hybird)

Forward flight

Backward Flight

Side to side

Then the logs will tell measurement vs control error. 

If this is a measurement error I’ll try to increase EKF_ALT_NOISE and repeat the test. 

So my only question is, how do I know measurement vs control error from the logs?

presumably in the stab flight I should see a drop in altitude measurements even thought I am keeping the same altitude correct? This would mean a measurement error. And if in the alt hold modes I see a drop in altitude and don’t see a drop in the measurements in the logs then its a control error? or am I missing something?

Best Regards / Saludos,

Jaime Machuca Mercado

[David Pawlak]

Jaime,

You mention you see the drop in SOME of your copters. What is the difference between the ones that drop and that don't drop.

My theory is (which seems to be supported by the new static sensor placement) is that units with large frontal area will be affected more where the Pixhawk is installed on top of a larger top plate.

There's a pressure bubble in front of the vehicle, Tilting forward, the Pixhawk moves into the pressure front, which is diverted somewhat upwards by the plate the Pixhawk sits on when it tilts forward. When the vehicle tilts up to stop, the pressure bubble drops below and the pressure changes quickly.

I think the difference in a unit that has less frontal area is that the pressure build up is much less, being more "streamlined" the air flows more cleanly past it. 

The new position of the pressure sensor is below and forward. If anything in forward flight the sensor moves "out" of the pressure bubble. In this way controllers don't compensate for pressure build-up.

When it stops, the sensor tends to move back into a higher pressure area, which would have the effect of causing the controllers to climb. I noticed at least once, the octo "raised" slightly on stopping instead of falling.

[David Pawlak]

@Paul. I think it's a combination.

There seems to be a tendency for the uav to fall slightly as pressure increases in acceleration, but if you maintain speed constant, it finds it's altitude. The altitude loss there is slow but corrected. When the pressure changes rapidly during the stop, the controllers can't keep up, like it unwinds. Like an I term buildup unwinding. Whether that's what's happening or not I couldn't say, but that's what it seems like.  

[Jonathan Challinger]

It is a measurement error. Adding a probe or relocating PIXHAWK is the only solution we've seen working.

[David Pawlak]

@Randy

I did a set of tests with the old sensor position and 3.2-rc7. Done with PosHold and AltHold. The only mode common to 3.1.5 is AltHold, but the two seem to react pretty much exactly the same.

I should probably do a set of stabilize runs as well as Paul suggests with both versions.

I'm all ready to go with 3.1.5, so will do that tomorrow, including stab runs, then go back and do a few more in 3.2-rc7 with AltHold and stab.

On Tuesday, September 9, 2014 10:26:25 PM UTC-3, Randy Mackay wrote:

[Jonathan Challinger]

Oh, are you using EKF or INAV on 3.2? EKF should do better, as it fuses the GPS vertical velocity measurement if available.

[David Pawlak]

@Jonathan, EKF

[Paul Riseborough]

Jamie,

If during the flights in stabilise and whilst you were keeping a constant height the CTUN message shows a variation in measured height, then that is measurement error.

If during flights in alt-hold you see the CTUN waypoint height and measured height move apart, then that is control error. The assessment of control error is complicated by the fact that sudden changes in measurement error in any alt control modes will also cause some control error as the height loops tries to keep up with the change in measurement, so a measurement error issue would need to be addressed first before fine tuning height control.

Regards,

Paul

[David Pawlak]

The log I took yesterday with 3.2-rc7 almost definitely points to measurement error.

Let's see what happens with 3.1.5 today. (whether it drops or not.) It's almost a certainty that it will show measurement error. (same hardware)

[Thorsten]

Hi all,

I am facing similar problems (http://diydrones.com/forum/topics/arducopter-3-2-beta-testing?commentId=705844%3AComment%3A1768432). Following this discussion I decided to test some additional foam around the baro in the Pixhawk case. It seems to help to some degree!

Best regards,

Thorsten

[Jesus Alvarez]

Hi,

My two cents may not be usefull but.... I have been using rctimer dome and foam over baro for a long time now and never found the issue described here. BUT IT IS WITH 3.1.5

http://rctimer.com/product-971.html

[David Pawlak]

Well, case pretty much closed!

Tested 3.1.5 with just about the same conditions as 3.2-rc7 and 3.1.5 is as bad or worse.

Differences:

I did 3.2-rc7 with EKF, 3.1.5 can only be done with DCM

I did tests in stabilize, with 3.1.5. if anything it has a tendency to rise after the stop. In general, I noticed that with forward accel (in stab) it also tended to drop slightly until velocity stabilized. Then stopping it rose up.

Tests in AltHold were very similar to 3.2-rc7, but with any alteration in altitude slightly more exaggerated.

ALmost feel like I don't have to post the results.

It's measurement error, and nothing introduced in 3.2. I think Jonathan is right in one sense, in EKF, it is "slightly" better, but not by a great deal. Once I have 3.2-rc7 back in, I'll try with EKF and without. For the heck of it.

I'm not sure I believe that nothing can be done in software.... isn't one of EKFs abilities to be able to quantize "measurement error".

I'm happy. I have a hardware solution. Hopefully it's enough for my big guy.

If you still want to look at logs, let me know.

[jolyboy]

In that case, you should be able to do what Paul suggested and raise EKF_ALT_NOISE and see an improvement

[Paul Riseborough]

David,

If you increase EKF_ALT_NOISE, then the EKF solutinon will follow the baro error more slowly. The EKF default parameters were initially tuned to provide equivalent response to the inertial nav so that there would be minimal impact on control loop tuning, so it is not surprising that the time constant that it responds to baro errors over is similar.

The EKF can tolerate a significantly higher value for EKF_ALT_NOISE than the default tuning because it  has z accelerometer bias compensation and also uses vertical GPS velocity measurements. I would give that a try.

In the longer term, using a combination of GPS and BARO height and provision for an external static pressure source are required.

Paul

[David Pawlak]

Thanks Paul, I'll adjust EKF_ALT_NOISE. With my new sensor position and adjustments to that I should be solid.

BTW, it did good to go back to 3.1.5 to be reminded of how far we have come!! We're finally coming out the end of 3.2 and it's NICE!

This weekend I'm going to PLAY a bit!

[Thorsten]

Hi all,

I made another test today trying to analyze some strange vibration issue and forgot (parts of) the dome at home. The behavior in AltHold was completely different. This is the history:

1. before putting some more foam into the Pixhawk case and with dome there was a continuous loss in altitude in any flight direction - not an altitude loss after flight
   
2. after putting some foam into the Pixhawk case and with dome there was almost no continuous loss in altitude in any flight direction and no (as far as I can tell) altitude loss after flight
   
3. after putting some foam into the Pixhawk case and without dome there was almost no continuous loss in altitude in any flight direction but a significant altitude loss after flight

The flight in Auto and PosHold without the dome and with wind speeds of 4 to 10 m/s was pretty unstable with short variation in altitude. I assume this is an influence of the noisy baro signal. 

Concerning the AccY vibrations which are higher in Auto mode compared to PosHold (see link above) the baro noise as well as changes in speed seems to play a role as well (see screenshot). One of the CW motors has a bad bearing. This might be part of the problem. Changing the position of the motor from 4 to 1 on the hexa had no effect on AccY.

I will try to increase EKF_ALT_NOISE. Any other suggestions are welcome. :-)

Best regards,

Thorsten

PS: The flight shown in the screenshot was in Auto. I accidentally switched to PosHold and back to auto.

[David Pawlak]

Thorsten,

Initially I thought that the altitude disturbances was from a ram effect directly on the pixhawk, but after my tests with the repositioned static sensor, I'm fairly sure it's more like a pressure bubble around (specifically in front of and somewhat above, when tilted forward). The Pixhawk moves deeper into the pressure bubble, which is furthermore focused upward by the plane of the body in forward flight. Slimmer, and presumably more aerodynamic bodies are less affected, even with the forward tilt, because the overall pressure bubble is less.

I tried at one point, a hemi dome, like yours, but cut in half, almost like a round windshield. Forget it.... made it worse. I guess it increased the frontal area, but wasn't at all aerodynamic. Must have had terrible turbulences behind it. Perhaps your dome provides a much more aerodynamic profile at least controls the air around the Pixhawk.

The good thing about a software fix for this would be consistency across frame types. Hardware solutions will tend to be very frame specific. Perhaps a static sensor on a landing gear strut or maybe even a stabilized camera plattform could be good options. And perhaps we can get more tests of "the dome with foam" :)

[Paul Riseborough]

David,

Any time you force air to flow around an object like a fuselage or fairing you create low pressure along the sides because the flow has had to accelerate to get around the shape, whereas in front, there is a high pressure region because the flow there has been decelerated. Here's a graphic that shows the pressure around a cylindrical shape with air flow going from left to right  (red is high pressure, blue is low pressure). You can see that depending on where the openings are and the direction of flow, the average pressure inside as seen by the baro will vary.



It's all to do with Bernoulli's theorem http://en.wikipedia.org/wiki/Bernoulli%27s_principle.

Filling the space with foam will be changing how the pressure at the sensor relates to the pressure at different access points on the fairing and will have been slowing down airflow inside the fairing caused by difference in pressure at different access points. It's effect is likely to be very airframe specific.

At the moment we are throwing away GPS height information and have not yet optimised tuning of the EKF in the vertical channel to reduce the sensitivity to this effect so there is a more we can do before having to look at external baro sensing options, however there are some users with high speed planes that will still need an external baro reference.

Regards,

Paul

[David Pawlak]

OK, I was going over this in a blog, and someone asked for graphs from logs to explain. Fine.

The graph posted by Jaime seems to represent our problem, and on first glance another one of mine which look quite simlar, also seems to coincide:

 The velocity and Alt graphs are the same.... But, something's not right.

If you compare pressure alt (in red) with GPS RelAlt in blue, the pressure alt change is greater than the actual change alt, and one can assume that the GPS is more correct.

However, for the pressure alt to read as it does, the actual pressures are seemingly backwards. Pressure drops as the velocity increases,  and pressure increases as the vehicle noses up and slows to a stop.

The pressure readings correspond to GPS Alt, but to an exagerated degree.  However they seem more related to actual altitude activity than to aerodynamic effects of a pressure bubble.

Why is my static system mod working?? What's going on??

[Jonathan Challinger]

GPS RelAlt is inertial navigation altitude for some reason. It needs to be removed entirely.

[Craig Elder]

Why do you want to remove it?

[Jonathan Challinger]

Because it doesn't really belong in the GPS message, which is for GPS measurements.

[Jonathan Challinger]

And also these days we log the same thing in CTUN.Alt.

[David Pawlak]

More than once, it had occurred to me that something in the graphs wasn't right..... perhaps a matter of interpreting them properly, but what is certain, what you see in the graphs ISN'T what happens in the field.

I mean, for those that don't have this problem, they probably wouldn't see the apparent anomaly. but looking at this graph:

It indicates that Navegation altitude (the one the autopilot thinks is real in green) is NOT at all the same as what happens in the field. And although the red pressure altitude is not 100% representitive, it's much closer.

So here, it's difficult to see direct cause and effect. The pressures measured at the sensor (not shown here, but represented by the inverse of pressure altitude are the opposite of what you would expect for the pressure bubble theory, Yet the pressure bubble theory seems to be correct because the static system mod works very well. (The mod is not implemented in this example).

So what seems to be happening is that somehow, the nav system is reacting to it's interpretation of altitude which produces the actual swings that we see. Since the nav system altitude is NOT what actually happens, we have a little bit of a problem. One perhaps, that if we can identify why the nav systems's interpretation is erred, might be able to improve this situation with less physical intervention.

[Jonathan Challinger]

Not understanding what you're saying. I believe the copter falls because it is trying to keep that green line flat, while that green line is trying to follow the red line, which is wrong. If that makes sense. Once the copter stops, the red line becomes correct and the green line starts to move towards it, but the copter keep the green line flat so it looks like the red line is moving towards the green line.

[Jonathan Challinger]

Unless you're seeing a RISE when you fly forward, which is what you're suggesting when you say the red line matches reality. That, however, is completely counter to my experience.

[David Pawlak]

The form of the "green line" is closer to reality, but the amplitude is about double (or more). Here it shows a little more than a meter drop which is nothing to really get excited about, but in fact visually, the drop is greater than 2 meters. I have had cases, much worse, with drops of 5 or 6 meters, having to give throttle to prevent the vehicle from hitting the ground. I don't have those graphs, I may have to dig around. When I usually get back to the shop after a test to go over the logs, I usually can't find graphs that show the green line falling more than 2 meters.

So it seems to be correct that the system tries to keep the green line flat. But the green line is flatter than reality, and in that sense the red line is closer to what the autopilot is reacting to.

And that's where the problem lies..... that said, pressure drops during forward accel/movement, and rises during decel. Contrary to the bubble theory.

Unless the vehicle is actually doing what the red line says.

One could probably simulate the conditions adding something that increases the frontal area below the deck.

[Jonathan Challinger]

Here's what I suspect your actual altitude is doing:

[David Pawlak]

Here is a log with the static system mod.

You can see that the pressure altitude seems to flatten out in forward flight. Also is much more reduced. Forward speed in alot of these is as much as 8m/s, and stops on a dime.

I wouldn't dare challenge the other vehicle like this.

CTUN.Alt is quite flat, and represents what is seen in the field. I don't think there's even a meter drop in the field, In cases of very fast stops the vehicle actually raises up a bit.

So the dynamics are quite similar. It is evident the static system mod works. But I don't really understand Baro.Alt. 

[Jonathan Challinger]

Do you want to have a discussion on skype? Maybe I could help explain what is happening, if you're interested?

[Jonathan Challinger]

Also, do you have photos of the probe? I'd love to make one.

[Jonathan Challinger]

Never mind, found it.

[David Pawlak]

Sure, I'm  david.pawlak4.

If I had to draw a "yellow line" based on what I see in the field, it might be similar to yours, but instead of dropping so soon upon accelerating the controller seems to correct. So the drop is much less initially. If you stop accelerating and maintain velocity, it totally corrects and returns to the correct altitude. when you stop it drops down as seen below: