As the title says, my hardware is throwing errors immediately on boot, and they don’t go away. It’s a BeagleBoneBlue running the latest version of Copter (I don’t remember what that is, but I only compiled it a week ago).
The errors are “EKF3 IMU0 forced reset” immediately after I get the “EKF3 IMU0 initialized” message, and “Bad Baro Health” on the main screen. Also, I have vertical speeds of ± 50mph while sitting on a still desk, with altitude variances of ± 300ft even after minutes of idle time to settle out.
I have no idea why I’m getting these errors, as this board has never even flown before, just sat in a box for a few months. Maybe one of you will have some ideas as to my issue, and if it’s fixable or not?
Update. I let the board sit powered off for a few days and the “EKF3 IMU0 forced reset” errors have gone away, but the barometer health warnings haven’t, and I can tell that the barometer is wrong, because it thinks I am at 5250ft when I’m actually at 1201ft. I was also getting mag errors, but I realized that the windowsill I put it on was directly over an outlet, so moving away from that solved my mag issues.
INS_FAST_SAMPLE is set to 1 currently.
Try disabled - set to 0 and see if will solve your imu issue.
Nope, it’s still resetting every 15sec or so. It actually wasn’t last night, so I’ll try re-enabling that setting and seeing where that gets me.
Well, dummy me that’s never worked with params before forgot to actually click write. I have now, and rebooted just in case, and it still is dropping out, as well as the barometer is still not working.
Any idea what is causing this to happen? Do I have a bad/unreliable IMU?
the blue uses the mpu9250, and I got problems with ardu4 version because the mpu - at least the boards I use, doesn’t support fast imu sample.
After the write, have you had rebooted the board or restart arducopter ?
Because after changing this, in my case, the messages gone away.
Yep, I rebooted the board twice after the write, with no change either time.
Well, it has finally settled down after just being on for a long time.
- The EKF is not happy (keeps flipping to orange momentarily on the main screen), but it is working.
- The barometer is also stable. Wrong (it thinks 18ft, I’m at 1201ft), but stable.
Now I’ve just got a “check mag field: 1086, max 875, min 185” error that I don’t understand. The board is sitting on my porch railing, far away from any magnetic interference. There are no wires near the IMU to mess with it magnetically.
What gives? Normally electronics behave for me…
I believe you can compile the test programs - ./waf examples - or ./was samples to check each component (Imu, compass and baro) individually.
I didn’t make tests with blue, because instead use SPI for IMU and Baro as you can see on BBBmini or pocket, the blue uses I2C interface for baro and imu - and this make a big difference.
I’ll try to do that then, because it’s driving me crazy to not know if my hardware is bad or not. Thanks for your help!
Where would I find the code that I’m supposed to compile? I assumed that it was either already bundled with my install of Copter or available from the firmware.ardupilot.org site, but was mistaken on both counts.
I am seeing the same EKF3 IMU0 Forced reset message every 15 seconds on Arduplane running latest 4.1 dev version on an Omnibus F4 Pro v3 board. I also set NS_FAST_SAMPLE=0 to see if that helped, with no improvement. So unable to arm or fly at the moment.
Unfortunately I don’t know what fixed my issue to try and help you. It seems to be fixed (as of last night on gitter) by just recompiling Copter-4.1 and leaving INS_FAST_SAMPLE set to 0, but I’m really not sure that it’s fixed until I get my drone done and in the air.
Edit: Fired up my old compile of Copter-4.1, and it works fine with both the Baro and IMU now. Weird.
I downgraded to current 4.0.9 release and issue went away. Upgraded back to 4.1.0 custom dev version I was using before and issue re-appeared. Set the INS_FAST_SAMPLE=0, reset the FC and issue still present. Upgraded again to the Latest dev version of today, and still the issue is present. I then tried disabling EKF3 (EK3_ENABLE=0) - and switched AHRS_EKF_TYPE=2, then reset the FC, and no matter how many times I tried this, after the reset the EKF would be back at 3. Downgraded again to 4.0.9 and issue cleared again (noticed EKF is set to 2 on this 4.0.9 version).
If I enable EKF3 on the 4.0.9 version, then I don’t see this issue - even with INS_FAST_SAMPLE=1. I just get loads of Error Compass Variance messages instead 
Nice! Thank you for all your troubleshooting work on this, the information you have found is very useful! I found out the same sort of thing last night by using Copter-3.6 (which is EKF2), and got my board apparently working. I didn’t want to trumpet the news yet because I still haven’t flown (I’m still printing the center portion of my frame), and wasn’t sure it was fully fixed, but your findings give me even more hope that my problems are gone. I’ll try backing up a version from Copter-4.1 and see if EKF3 works there.
One other think I haven’t mentioned - I have another plane - a flying wing which also has the Omnibus F4 Pro board (albeit the v2.1 version) installed and with the same 4.1.0 dev firmware (which I reported on earlier) works fine on this board in my z84 flying wing. No forced reset issues at all on this plane. Its a very weird issue!
Well, after adding an external barometer, changing kernel and Debian versions, and a lot of other fuss, my copter now works, even running 4.1 with EKF3. It’s less physically stable on EKF3 than EKF2, for some odd reason, but it does work. No more resets. INS_FAST_SAMPLE is off, though.