@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
About the evaporation with me, I noticed a few things:
It only happens when the rover is sending the message ubx-nav-pvt, if I disable , it won’t happen, but happens as soon as I enable .
If you configure the parameters in a way the information is gps1 instead of gps2, it does not happen,
2 Likes
Yes, when switching from Stabilze to AltHold (or Loiter or any other mode where the pilot controls the climb rate) the target climb rate is initialised to the current climb rate and then it is shifted back to the pilot’s input but only as fast as PILOT_ACCEL_Z allows.
I’ve added the “EKF3 Core x Unhealthy” to the 4.1 issues list for investigation. I can’t promise we will resolve this before 4.1 goes out because we weren’t really intending GSF to be used as the primary yaw source but it might be possible. In any case we are very happy that you’re testing it and uncovering these issues!
Thanks very much for this info re MP evaporation. I’ve reproduced this work-around and found that MP stops evaporating for me as well if I disable my 2nd GPS. I’ve passed this onto @meee1 (Michael Oborne). This could be quite an important find, thanks!
There are instructions for building MP at the bottom of this page which I followed but eventually MO helped me out to get it running so I’m not totally sure if the instructions are complete.
Txs again.
@GRS26 and all suffering from the MP evaporation issue, it appears to be fixed in the latest beta (1.3.74.2).
@meee1 was able to reproduce the issue once it was clear that it was the dual GPS that was causing the issue so special thanks to @GRS26 for finding this!
1 Like
Hello,
Glad my struggle helped haha
1 Like
Havent flown this multirotor in a year or so not sure when this error would have popped up, but using a june 1st build on a pixhawk 2.4.5 I’m getting this error when I attempt to arm and fly.
7/6/2021 1:05:51 PM : PreArm: Internal errors 0x800 l:240 watchdog_rst
7/6/2021 1:05:50 PM : E32768 IEC14 TN:
7/6/2021 1:05:50 PM : WDG: T6 SL0 FL0 FT0 FA0 FTP0 FLR0 FICSR0 MM0 MC0 I
7/6/2021 1:05:40 PM : E32768 IEC14 TN:
7/6/2021 1:05:40 PM : WDG: T6 SL0 FL0 FT0 FA0 FTP0 FLR0 FICSR0 MM0 MC0 I
7/6/2021 1:05:30 PM : E32768 IEC14 TN:
7/6/2021 1:05:30 PM : WDG: T6 SL0 FL0 FT0 FA0 FTP0 FLR0 FICSR0 MM0 MC0 I
7/6/2021 1:05:21 PM : PreArm: Internal errors 0x800 l:240 watchdog_rst
7/6/2021 1:05:20 PM : E32768 IEC14 TN:
7/6/2021 1:05:20 PM : WDG: T6 SL0 FL0 FT0 FA0 FTP0 FLR0 FICSR0 MM0 MC0 I
7/6/2021 1:05:10 PM : E32768 IEC14 TN:
7/6/2021 1:05:10 PM : WDG: T6 SL0 FL0 FT0 FA0 FTP0 FLR0 FICSR0 MM0 MC0 I
7/6/2021 1:05:09 PM : Frame: QUAD/X
7/6/2021 1:05:09 PM : IMU0: fast sampling enabled 8.0kHz/1.0kHz
7/6/2021 1:05:09 PM : RCOut: PWM:1-12
7/6/2021 1:05:09 PM : Pixhawk1-1M 00330022 3134510B 35313935
7/6/2021 1:05:09 PM : ChibiOS: 08877972
7/6/2021 1:05:09 PM : ArduCopter V4.1.0-dev (26ea80fc)
7/6/2021 1:05:09 PM : Frame: QUAD/X
7/6/2021 1:05:09 PM : IMU0: fast sampling enabled 8.0kHz/1.0kHz
7/6/2021 1:05:09 PM : RCOut: PWM:1-12
7/6/2021 1:05:09 PM : Pixhawk1-1M 00330022 3134510B 35313935
7/6/2021 1:05:08 PM : ChibiOS: 08877972
7/6/2021 1:05:08 PM : ArduCopter V4.1.0-dev (26ea80fc)
7/6/2021 1:05:08 PM : Frame: QUAD/X
7/6/2021 1:05:08 PM : IMU0: fast sampling enabled 8.0kHz/1.0kHz
Not sure what to make of it or how to proceded. Should I gather a log with the logging before arming? I thought maybe my earlier messing with NTF_LED_TYPES might have caused it so during the above log I unchecked some of the LED types and rebooted. But still got the watchdog error when I tried to arm.
Thanks for the report. A watchdog reset isn’t good because it means the autopilot is rebooting. It looks like you’re using the dev version of the software by the way, if possible it would be good to stick with the beta versions because that makes it a lot easier to know exactly what version is on the autopilot.
Sorry to be annoying but could you try again with -beta5?
No prob, I can do that. The firmware that generated the errors was this one https://firmware.ardupilot.org/Copter/2021-06/2021-06-01-00:06/Pixhawk1-1M/arducopter.apj
Ran out of time yesterday but was going to test 4.0.7 to see if that error popped up with the current hardware configuration. That firmware is loaded on, later today I’ll see if it’ll take off without errors then I’ll try the beta5. I don’t think I’ve flown it since 3.4
1 Like
Can confirm 4.0.7 works, did a short flight. Loaded on beta5 and tried to fly, the pixhawk led was flashing green then as I tried to arm it went yellow but not sure why. I neglected to set the config properly to log before arming so it didn’t generate a .bin on the sd card, so I’ll have to try again tomorrow. I tried to see what code it threw on my base station but by the time I got down to the computer a few minutes later the messages console looked normal (it wasn’t connected via mavlink at flight time). I’ll give it a try tomorrow.
1 Like
I have a log but not sure its value. I wasn’t able to take off due to my transmitter fritzing out. A wire pulled out and after I soldered it back on, the transmitter turns on and off rapidly then not at all. The movement in the log is when I picked up the multirotor and moved it from right next to the house to where it was going to take off from (it can’t get reception from the base station that’s in my house unless the multirotor is next to my house). I figured I would I let it warm up for a few minutes, let the gps come on before I started the logging (file would be big enough I thought). So I wanted to connect from my base station and issue the logging while disarmed parameter then reboot the pixhawk with that button in ctrl-f so as to reboot without cutting power for the GPS to stay on. Anyways. I have another transmitter but I need to check my wiring and Frsky Taranis to see if there’s some other issue before I put in a new transmitter (don’t want to ruin another one). Supposed to rain today so it might be a day or two before the next log. Are there any other parameters I should log or is this ok?
https://mega.nz/file/4bxHla7S#f69VmwKE4ur6NJObD4MkpVerJV8jDgGS8kb6vaJ74k4
Found this short on my transmitter, not sure if its the cause but doesn’t seem like it’ll help https://streamable.com/919y6k
1 Like
Txs for the log and the link to the firmware used. That’s quite a bit of detail actually so hopefully we can figure it out. I’ve added it to our list of things to be investigated for 4.1 so it won’t be forgotten.
If you see it again (or don’t) with -beta5 we’re very interested to hear about that. By the way, was it a one time thing on this board when using the June 1st firmware linked or did it happen more often?
1 Like
@peterbarker has had a look at the watchdog reset and says we have resolved a couple of issues in 4.1-beta5 that could cause this. Did it happen just as you tried to arm the vehicle or at some other time?
1 Like