Any ideas what this is all about? Do I need to worry about it? I am seeing it in the Messages window roughly every 30 seconds after I connect MP to the UAV via USB (MavLink).
My understanding is that this error message is triggered by our IMU driver when it is noticing problems with the Invensense IMU on the board. Does it always happen or is it just an intermittent problem? Does it maybe only happen when the board is powered via USB but not while powered using a battery?
If you’ve got an onboard log that would be great. It may be necessary to set LOG_DISARMED in order for the log file to be produced while the vehicle is disarmed.
By the way, if possible it would be great if you could use the beta instead of “latest”. Of course you’re free to use whichever you’re happiest with but it is easier for us to provide support for “stable” or “beta” but not “latest” because it changes multiple times per day so it is difficult for us to know exactly which version is being used.
Thanks for the report and helping us with beta testing.
@rmackay9 Perfect! I have enabled LOG_DISARMED and dumped a first log, while waiting the 30 seconds necessary for the internal error to show up in messages. I will PM you the file if that’s OK. Let me know how else I can help.
Thanks for the suggestion about stable/beta vs. latest. It’s a good suggestion . I may revert back to stable if I encounter too many issues. So far the biggest issues I have hit are the Internal Errors imu_reset (this post) and the errors on Level calibration. I don’t know if either one is isolated to dev/latest or not.
Just wondering if there’s been any development/debugging on this issue? Does anyone have any ideas what might be causing it, and if there’s anything I can do from my side to avoid it?
I finally got more time to work on this project and after setting up the video connection I can see the same error pop up on the OSD right in the middle of the video frame (in addition to the HUD in Mission Planner). So it seems like a critical error …
Thanks @rmackay9! I have switched back to fw 4.0.7, and on that version I am seeing an error about “gyros not healthy”. This surely must be the same underlying bug… This also may be the reason why the “Calibrate Level” operation under “Setup -> Mandatory Hardware” fails on this board (Matek H743-slim) with an error that states “Command Failed to Execute”. Perhaps the bug is that the IMU is not fully supported on this board, so the accelerometer and gyro aren’t properly getting initialized.
This came up again on the weekly dev call and @tridge said that he thought it was actually a hardware issue rather than a bug in the AP IMU driver. My understanding is that only some of these Matek H743 boards are affected and this IMU works fine on some of the Matek H743 boards and also on other types of boards.
@andyp1per – the bdshot version of the firmware? Will that work with blheli32 4-in-1 escs? I am assuming that bdshot refers to bi-directional dshot; I am not sure if that’s supported by all blheli32 escs or not, do you know?
Thanks @andyp1per. My understanding from the docs is that only the Kakute F7 and Beast F7/H7 have bdshot versions of the firmware. I am not seeing one for the Matek H743. Perhaps I am not looking in the right place?
@andyp1per , I flashed the beta version you pointed out, and with that I see alternating messages: “Internal error 0x1000000”, “Bad gyro health”, and “Bad accels health”.
Could these symptoms be due to the fact that the Matek H743 has not one but two IMUs (MPU6000 (SPI1) & ICM20602 (SPI4))?
As discussed on the other thread, it’s great to keep trying but I think it really is a hardware issue and there is little we can do about it in software.
Good to hear a confirmation, @andyp1per, thank you! I will get another one of these boards soon. Hopefully it’s just mine that’s bad. Shipped from China (sigh)
If “seattleiteFPV” means Seattle, WA these Matek boards are available from domestic sources. And less than Banggood for example. I don’t find it necessary to buy much from China sources anymore.