Hi,
Two weeks ago I took my TBS Discovery Pro out for an Autotune and in the end of autotune it skyrocketed up to 105 meters. It was still doing autotune when this happened.
Setup:
PX4 with 3.1.5
4s battery
stock pids before autotune.
As logging does not work on PX4 in 3.1.5 I can only rely on the tlogs from Andropilot.
I know altitude control does not have any sanity checks for its output, but I want to minimize the risk of it doing it again,
Auto tune is carried out in the Altitude Hold mode. Fairly obviously, your ship wasn’t holding height.
Since APM gets height info from the Baro for altitude hold, it is possible there is an issue with the data the Baro is supplying. Is your PX4 cased or is the Baro protected from wind and light with foam and tape?
I don’t have a PX4 but this is an issue with the APM Baro and they are likely to be the same component.
Check the instruction manual Wiki for details.
What was the weather like? Changes in air pressure caused by wind or other atmospherics can cause Baro glitches. Mind you, your experience on the day was a little extreme for a local change in air pressure
Hi, thanks for your response.
And it was not that windy
It was fairly windless, it drifted a little bit in autotune but not much.
I use foam sandwiched between the boards and it has been working quite good before, no case.
I can tell you that the wind didn’t made it skyrocket (a sudden full power!!)
I just want someone to look at the logs and see what failed first, baro or gps or DCM.
I think I will try 3.2rc2 and use EKF so that whatever the cause it will have less impact.
Something got royally, royally screwed up. Logging isn’t working at all on PX4? I’d love to get a dataflash log. Nothing wrong with your baro - you can look at SCALED_PRESSURE.press_abs and it behaves normally. Nothing wrong with your GPS, nothing wrong with your accelerometers as far as I can tell.
VFR_HUD.alt went to zero and stayed there. So did GLOBAL_POSITION_INT.relative_alt. They’re both based on current_loc.alt in the code, which is our main altitude reference that is filled in by the inertial navigation. The only thing that could cause this is a bug in or around the inertial navigation.
I don’t see any mechanism for this to happen. Maybe if something in inertialnav went nan.
You do have a giant baro spike later in your log, either caused by a bug or by a flash of light getting into the baro (I err on the side of suspecting a bug, others think its just light). I suppose it is possible that one of these caused the inav to go nan, but I have no way to tell based on your log.
Hi, thank you for your input, weird isn’t it?
I have not flown since then as I am afraid it will happen again.
Yes, on firmware 3.1.5 the logs do not work on PX4, on 3.2 it does but its beta so I have to consider other possible bugs.
Hopefully its no hardware issue, like baro failure. And I will have to see if 3.2rc2 will work in alt hold in a few days.
As I have compressed black foam I do not think much light can go into the baro, maybe some but not much. the PX4 is inside the frame of the TBS so it is kind of hidden.
So, when I fly 3.2rc2 or rc3 if it will be out then, Hopefully I can switch back to stabilize if it happens again, assuming internal nav is not trashed like you said
Also, do you recommend that I try using EKF, maybe it will cope with it better?
(a sudden full power!!)