Copter-4.0.1-rc2 has been released for beta testing and is available for download using the ground stations’s Beta Firmwares link. The changes are in the ReleaseNotes and also copied below:
FrSky SPort Passthrough telemetry status text handling fix (Critical Fix)
Circle mode allows pilot control of radius and rotation speed
CAN servo feedback logged
Magnetic declination tables updated
Serial0 protocol forced to MAVLink (avoids accidental disabling of USB port)
Bug Fixes:
a) TradHeli RSC RC passthrough fixed
b) CubeOrange and Durandal I2C timing fixed (was running slow)
c) Compass calibration auto orientation skips “pitch 7” which could cause cal to fail
d) Durandal’s fourth I2C port fixed
e) Linux boards with CAN support fixed
f) Neopixel added to SERVOx_FUNCTION param description
g) NMEA Output fixed (was sending an extra CR)
h) Optflow messages sent even if EKF has no height estimate
i) SkyViper build fixed
j) Spektrum/DSM 22ms RC input fixed
k) “UC Node Down” message removed (was unnecessarily scary)
The first item is a critical fix meaning it resolves an issue that can cause vehicles with FrSky SPort Passthrough telemetry to crash. The issue was first reported this morning and we hope to release this as the official version within a few days. By the way, the independent CPU watchdog logging was critical in tracking down the issue because it logs some important state of the vehicle. This issue does not exist in Copter-3.6.x.
@Pedals2Paddles and I are very interested to hear feedback on the Circle mode changes (good or bad!).
Any other testing and feedback is also greatly appreciated!
@rmackay9 I’m interested in testing the #1 critical fix because I’m using described configuration.
Do you know how it is possible to reproduce the issue?
It looks like the crash could happen on a message transmittion through telemetry. So you must somehow force ApduPilot to generate messages and to be lucky enough to catch the race condition issue.
Few days ago I had a 40-minutes flight with “Compass variation” message sent every 3 second. So this may be hard to reproduce…
I did three autotunes on two different quads with 4.0 and S-Port passthrough and didn’t encounter the watchdog bug in any of that message avalanche.
And now it dawned on me that while in 3.6.x doing an autotune would freeze the sensors, I definitely had pack voltage and current working throughout the tunes.
Does the “latest” Builds have this fix in them? Or do I have to build from source? Typically I have been grabbing the latest .apj file and upload it. And not 100% sure on how the RC builds work
Not sure what happened but after downloading the latest version of MP and installing Copter-4.0.1-rc2 I have lost all of my params. Doesn’t seem to like loading from an older param file with several errors.
Edit: Changing my frame type back to Hexa, loading 4.0.0, and grabbing the param file from a log download seems to have me back where I belong. I’ll give the beta another try.
Edit 2: Ok, the RC2 upgrade took that time. I very thankful for the param files included with log downloads. Saved my rear end this time. MP updated within minutes of my first download so wonder if there was a connection.
Edit 3: Looks like I will need to re-calibrate my compass though. Lost those settings.
Thanks for the testing and feedback. It may be hard to reproduce. We only found it because the watchdog gave us enough details of the problem so we could track down the bug through “inspection” (i.e. searching through the code). We then made a temporary code change to replicate the issue.
Yes, I think the NeoPixel is included for all boards. There is a discussion thread here with some other users trying to get the NeoPixels working and they seem to be struggling so I’ve added this to our Copter-4.0 issues list so we will investigate and won’t forget about it.
Thanks for the report and sorry for the parameters getting reset to their defaults. This happens occasionally (issue is here) although it seems to be quite rare. I’ve seen it myself once about 6 months ago and I was quite shocked but I haven’t had it happen again since even though I upload new firmwares all the time.
We think it happens when there is an error reading a critical marker that is placed at the start of the eeprom (where we store parameters). This makes AP think that the eeprom hasn’t been initailised and it wipes all parameters. We’re going to change this so it reads this critical byte multiple times to greatly reduce the chance of a parameter wipe.
Im getting this message in the Status window on MP, “EKF2 IMU0 forced reset”, several times. Im using the 4.0.1 rc2. I did not fly the drone, was just a bench test yet. Should I worry?
Sorry if this has been reported already, but I wanted to mention that I updated my 700 heli from 3.6.10 to 4.0.1-rc2 and it turned BATT_MONITOR off. After I realized this had happened, I turned it back on and all my previous BATT params showed up. AP is a CubeBlack.
@rmackay9 - for clarification - since losing my params due to this issue will reloading from a backup only require re-calibrating the compass, or will I need to calibrate the accelerometers again as well?
Not looking forward the to the compass dance with a 810mm drone, and recalibrating the accels again would involve removing the FC from the frame.
I think you shouldn’t need to re-do the accelerometer calibration if you’ve loaded the older parameters.
It’s possible to avoid the compass calibration as well by tricking the compass calibration check by temporarily setting the COMPASS_DEVIDx params to another value (like 999) and then back to their original value.
The compass trick worked, but the FC is requesting an accel calibration now. Probably for the best, but I would love to see that little bug fixed. Back to the bench!
Edit: I needed to move the buzzer to a better location anyway!
