@MartyMcFly, can you tell me which autopilot you’re using? The PC is Windows10?
1 Like
Im using the Cube Orange and a windows 10 and the latest firmware in the EFD mod and air unit,just to let you no the cube orange connects very fast by usb cable and thank you for your time
Had a fall from the sky when switched from STAB to AltHold.
For the first look the reason was the Desired Climb Rate got sharp negative value right after switch to AltHold.
But what caused DCrt to be negative?
Unfortunately this is BeastF7 board with small internal mem chip so have to disable some standard log parames.
I’m using GSF (GPS with no compass).
Here is the log 13 1-1-1970 2-00-01 AM.bin (924.1 KB)
And the onboard video https://www.youtube.com/watch?v=83pDvm_Qnkk
@rmackay9 could you please take a look?
Pretty sure part of the problem is your throttle is at 20% when you switch - for AltHold the throttle needs to be at 50% to hover and so the copter will try and descend. You get the opposite effect if you switch from AltHold to stab.
My throttle (RCIN C3) was exactly 50% at moment of switch to AltHold, it is on my screenshot.
What you noticed (on OSD) is throttle hover
Recently I had another strange experience where I am not sure if it was an issue with the EKF3 implementation in beta3 or a defective Cube Orange. You can find the detailed description here: EKF3 Position going mad - Bug in 4.1.0-beta3 or defective Cube Orange?
@rmackay9
Yes, you are right, I try to reproduce the situation. I switch to a new autopilot, and connect two telemetries and USB It’s not evaporating anymore… 
Hi, first thanks all devs for a great work.
Is it only me or do we have an issue in beta3 or latest stable QGroundControl?
If I revert settings to default I won’t be able to fully communicate with the APM afterwards. Have a Matek405-CTR, tested Beta3, bdshot Beta3 and latest.
It seems that EKF3 never gets out of startup and I’m not allowed to change any parameters in this phase. Most options in “Vehicle Setup” is missing only Summary, Firmware and Parameters are visible. Parameters can be read but not written.
To get it operational I have to revert to 4.0.7 and then update from that. Might be me or my FC that have created the problem.
Yea im experiencing the same symptoms hopefully sorted soon the dev’s do A good job
@lebarsfa
well…I don’t think we are facing same situation, in my case, after click connect button and start getting parameters, I can see checking for Param MAVFTP, then the MP evaporating immediately, It happened every time, same situation.
I confirm I have the same behavior, but it does not happen all the time depending on the parameters set in the Pixhawk, and potentially other things…
1 Like
I am not sure if it is related,but when I was messing about on the bench my cube orange reset it self im certain I did nothing to make this happen ,the plot widens
@lebarsfa, @MartyMcFly, @XinChengGe,
Thanks for the reports. I’ve passed this onto @meee1. MichaelO is struggling to reproduce it which is slowing the ability to get it fixed.
2 Likes
Thanks for the report. This definitely sounds like a QGC bug. I’ve added it to the list and perhaps we can reproduce it and report it to the QGC people it seems unlikely to be an autopilot issue. Important of course… but… seems like a ground station issue.
if anyone with the disappearing problem can run mission planner under the debugger that would help.
Hi @sergbokh,
Sorry for not seeing this post earlier. The log is difficult to analyse because there is so little information in it but still, the desired climb rate is suspicious.
The vehicle is falling at 2.7m/s at the moment it switches from Stabilize to AltHold and because PILOT_ACCEL_Z = 250 it will take it more than 1 second to recover back to a zero desired climb rate… it is slightly odd though that the desired climb falls to 3.2m/s.
I’ve added this to the 4.1 list of issues to be investigated and I’ll see if I can reproduce the issue in SITL.
Thanks Randy,
At time I did the flight I didn’t noticed the “EK3 Core 0 unhealthy” message. But as per log it fired before arm.
Could this bring some affect for the case?
Generally, how pilot should react on “EK3 Core 0 unhealthy” message if he not yet armed (suppose there are single EKF core)?
I would not fly with an “EK3 Core x unhealthy” message although if you’re only flying in manual modes (Stabilize or Acro) it is probably fine. This message is quite rare I think but can appear if:
- EKF has not completed initialisation
- compass values are failing to be fused because they don’t fit with other sensor data
- horizontal or vertical position or velocity estimates are bad
Re the issue above where the vehicle falls in AltHold mode. I think the issue is just that the vehicle was falling too quickly and it was too close to the ground when it was switched to AltHold mode. It just didn’t have enough time to regain altitude control. The vehicle was perhaps 3m from the ground when it was switched to AltHold but it was falling at 2.7m/s so it had very little time.
Re my earlier question of “why does desired climb rate fall to -3.2m/s”, I think this is just “input shaping” which means we smooth out the desired climb rate and acceleration using the PILOT_ACCEL_Z parameter (which is set to the default of 250 = 2.5m/s/s). So the “input shaper” is initialised when the vehicle switches into AltHold using the vehicle’s speed and acceleration at that time. Then then starts reversing the desired climb rate back towards zero but this takes a bit of time because PILOT_ACCEL_Z = 250. If the number was higher it might have recovered in time.
Here is a similar situation I reproduced in the simulator
1 Like
@rmackay9 thanks for the explanation, I wasn’t aware of “input shaping”.
Did I understand the behavior correctly: if switching from STAB to AltHold/Loiter then DCrt is initialized with current Crt value? And only after that DCrt is aligned with Input Throttle value, respecting PILOT_ACCEL_Z.
On my compass-less copter with GSF mode this error appears often. Maybe this is because this step was not performed:
Before arming, but after GPS lock has been obtained and EKF origin has been set and is “using GPS”, pick up the vehicle and walk around in a circle a few meters in diameter. This should allow the GSF to acquire yaw alignment and the message “EKF yaw alignment complete” would be sent to the ground station.
BTW most of the times it flies in GSF very well, without doing this manual circle yaw alignment. I’m thinking of reconfigure my mid-size copter to use GSF too. No more compass calibration issues 
1 Like
Hello,
How can I run mission planner under the debugger? I want to help