I have a quad that I’ve been flying for a year without a single problem until I recently updated to the latest FW. No any HW or settings changes were made. Only FW changed. And that made the quad not flyable any more, because every flight now it starts toilet bowling at approximately 10 minutes of the flight.
I flashed the old FW back and now it holds position precisely again.
I’ve calibrated the mag every time before the flight.
What can be the problem? Why new FW can’t work properly any more with my setup?
Logs of good and bad flight attached.
Good FW was also 4.1 latest but nine month old built.
I also saw this toilet bowl effect in a few flights with my CubeOrange and Here+ v2 using Copter-4.1-beta3. I thought I solved it by calibrating the mag but I haven’t flown longer than 10min since then.
Try BRD_BOOT_DELAY,3000 and see if it makes any difference, but you dont appear to have CAN connected devices.
You can definitely see the difference between the good flight:
That was the reason I’ve opened this topic. To me it looks like only a FW problem, because it was the same place, the same batteries, but about 6 flights in total with the same problem on different days.
No CAN.
Good one …
Log File C:\Users\Me\AppData\Local\Temp\tmp9270.tmp.log
Size (kb) 73698.5458984375
No of lines 801836
Duration 0:47:11
Vehicletype ArduCopter
Firmware Version V4.1.0-dev
Firmware Hash 246126e2
Hardware Type
Free Mem 0
Skipped Lines 0
Test: Autotune = UNKNOWN - No ATUN log data
Test: Brownout = GOOD -
Test: Compass = GOOD - mag_field interference within limits (7.75%)
Test: Dupe Log Data = GOOD -
Test: Empty = GOOD -
Test: Event/Failsafe = GOOD -
Test: GPS = GOOD -
Test: IMU Mismatch = NA -
Test: Motor Balance = WARN - Motor channel averages = [1360, 1466, 1405, 1495]
Average motor output = 1431
Difference between min and max motor averages = 135
Test: NaNs = FAIL - Found NaN in CTUN.TAlt
Found NaN in CTUN.DSAlt
Test: OpticalFlow = FAIL - FAIL: no optical flow data
Test: Parameters = FAIL - ‘MAG_ENABLE’ not found
Test: PM = GOOD -
Test: Pitch/Roll = GOOD -
Test: Thrust = GOOD -
Test: VCC = UNKNOWN - No CURR log data
Bad one …
Log File C:\Users\Me\AppData\Local\Temp\tmp69D.tmp.log
Size (kb) 39356.0322265625
No of lines 444607
Duration 0:23:09
Vehicletype ArduCopter
Firmware Version V4.1.0-dev
Firmware Hash d0b44ff5
Hardware Type
Free Mem 0
Skipped Lines 0
Test: Autotune = UNKNOWN - No ATUN log data
Test: Brownout = GOOD -
Test: Compass = FAIL - Large change in mag_field (99.60%)
Max mag field length (743.76) > recommended (550.00)
Test: Dupe Log Data = GOOD -
Test: Empty = GOOD -
Test: Event/Failsafe = GOOD -
Test: GPS = GOOD -
Test: IMU Mismatch = NA -
Test: Motor Balance = UNKNOWN - ‘QUAD/X’
Test: NaNs = FAIL - Found NaN in CTUN.TAlt
Found NaN in CTUN.DSAlt
Test: OpticalFlow = FAIL - ‘FLOW_FXSCALER’ not found
Test: Parameters = FAIL - ‘MAG_ENABLE’ not found
Test: PM = GOOD -
Test: Pitch/Roll = GOOD -
Test: Thrust = GOOD -
Test: VCC = UNKNOWN - No CURR log data
Thanks for the report. I’ve had a look and I can see that the EKF is unhappy it’s velocity estimates but I’m also not sure why so I will ask @priseborough. It doesn’t appear to be interference on the compass from the motors.
By the way, it would be great if you could reproduce the issue with -beta3. In general we don’t provide support for “latest” because it makes it difficult to determine what features are included/excluded.
This might be some proof that there is something weird going on with the EKF3. The drone is the same in all flights, only the firmware is different. The drone is a quadcopter using a CubeOrange.
Also, sometimes I’m getting a “yaw alignment anomaly” warning after take-off. I performed mag calibrations several times and that seems to temporarily fix the issue but it comes back after a few flights.
We haven’t heard back from you so I’m thinking about closing this issue.
We’ve had quite a few EKF improvements and bug fixes since your report so if you have time it would be great if you could re-test with one of the more recent beta releases (the current beta is beta7 but we are planning on releasing an update over the next few days).
One thing that concerns me is that your vehicle has an AHRS_ORIENT of 15 which is a little unusual and we have another report of bad behaviour which also involves a non-default AHRS_ORIENT.
Yeah sorry I went inactive for a while. However, this issue was fixed by software in one of the beta releases (beta6 if my memory serves me well). I haven’t changed anything in the drone, I kept the hardware arrangement exactly the same. As you said, it is likely that the additional EKF3 improvements fixed it. Here goes a plot showing the yaw of each EKF instance which are both tracking well. Nice job!
Thanks for your help!
