Michael OborneToday at 18:09
the compass was moved from a non top 3 position so it has no orientation
ie not init’ed
and no param until reboot
Below is a Link to the log file
The LIS3MDL has always been compass 1 since the upgrade to Version 4
David Ardis
Maybe this shows you the exact version I was running, the copy of 4.0.3 that works with the LIS3MDL…
This is the initial startup messages from the messages screen in MP.
When I use USB Power I get the following Compass
Powering the copter from the LIPO and connecting via WIFI Telemetry I get he Following
Over the last few days I have been flying with 531465 (LIS3MLD) selected as compass1 with no issues
I have done this test with 3 different Cube Black’s with HERE GPS and get the same issue
1 Like
Another thing I noticed…
All the FC Stats are changed after updating to 4.0.4. bootcnt, flttime, etc. I thought those were supposed to stay consistent for the life of the board, but I could very well be wrong about that.
1 Like
The FC stats get overwritten when you upload a parameter file. I have a PR that fixes that, but it is not merged upstream yet.
This was by simply updating, w/out uploading any params. And trying to upload parms, at least from Mission Planner, tells me those fields cannot be overwritten, so the new wrong values remain.
1 Like
Open a bug in github.
Hello, I have a 2.4.8 pixhawk controller, I bought a sonar for it
https://botland.com.pl/pl/czujniki-multifunkcyjne/14048-dfrobot-gravity-urm09-ultradzwiekowy-czujnik-odleglosci-2-500cm-i-temperatury-i2c.html
I can’t run it in any way. There is a chance that this sonar will work because I was hoping that it will work after the upgrade but none of that.
I’m afraid this lidar is not on our list of supported lidar (see here) so someone would need to write a driver for it.
Thanks very much for testing
I have heard this reported before but I was unable to reproduce it. I think it’s best we to try and reproduce it before raising an issue in the GitHub issues list. At the moment, I think the issue is that somehow the STAT_RESET parameter was reset to zero. The wiki page for this feature is here: https://ardupilot.org/copter/docs/common-flight-time-recorder.html
I have had two boards do it. Omnibus Nano and Kakute Mini.
And, they weren’t simply reset. But set to different, seemingly random numbers.
I thought maybe it was picking up values from the wrong fields or something.
It doesn’t matter to me, I was just letting you know. So if it’s not common, maybe nothing to worry about.
I’ll try to reproduce it again. I think going back to 4.0.3 put them back to the correct values… But let me do some testing and verify that and see if I notice any other patterns.
Thanks for the report. This is most likely a power issue. Depending upon the number of accessories and the PC useD, the PC’s USB port may not be able to provide enough power for everything.
Some things to try:
- a different PC or different USB port may be able to provide more power
- disconnecting some accessories may allow it to work. In particular telemetry radios often draw a lot of power.
- increase the BRD_BOOT_DELAY parameter to give the accessories more time to startup before AP starts trying to talk to them
I suspect this issue is not related to the firmware version so for example switching back to Copter-4.0.3 probably won’t make any difference but if it does I’m very interested to hear about that.
Thanks again for testing
Thanks very much for testing and providing feedback. We will be releasing an -rc3 with these compasses enabled for all boards. Hopefully the -rc3 will happen late this week we just need to resolve one final issue regarding adding and removing compasses (issue is here).
1 Like
The problem is the same on both my desktop and laptop have tried using the USB port direct into the computer and through a powered hub.
I have also tried removing all the accessories just leaving the HERE module on both the copter and test Cube Black and it makes no difference.
Boot delay has been increased to 10 second with no affect
I agree that it probably not a firmware issue but in order to rule that out I will take my test cube Black and install the last stable release of version 3, reset the parameters back to default and roll forward through the versions while noting which compasses are activated
1 Like
@rmackay9
Eric and I are working on a few copters that have a Here2 on them. We actually have a collection of vehicles exhibiting this problem, but in focusing on one copter, the PreArm check is failing because of high HDOP and high variances between EKF and DCM Yaw offsets. The problem is, we’ve configured GPS_HDOP_GOOD for 250 (which we’re under) and have also configured EK2_GPS_CHECK to 28, which removes the HDOP requirement from the PreArm check. Oddly, I’ve found that every “PreArm: High GPS HDOP” is accompanied by the dreaded “PreArm: EKF2 Yaw inconsistent by NN deg” message, but not every “PreArm: EKF2 Yaw inconsistent by NN deg” message is accompanied by the “PreArm: High GPS HDOP” message. I’m unsure if these are related but figured I’d share… Curious if you have any thoughts on this. I can provide a log to check if you’d like:
@rmackay9
As discussed earlier I have run a number of tests on different firmware’s of Arducopter from version 3.6.9 on wards after version 4.0.1 compass 466441 (HMC5883) disappears from the list of available compasses when powering through Power 1 on the cube carrier board enclosed is a file with is a zip file with details of the test layout details of each stage of the test process.
Compass Tests.zip (612.8 KB)
@ardisd there are only two relevant versions: 3.6.12 and 4.0.4-rc2.
What are the results with those versions?
I have found that there is a separate HDOP check, which is hardcoded in AP_NavEKF2\AP_NavEKF2_VehicleStatus.cpp
Might be related?
@amilcarlucas
3.6.9 was the first version that came to hand and the 4.0.4-rc2 was missed when coping all the files but (Type Mask 0 Arducopter 4.0.4 rc2 Power ) shows almost the same thing. The main point was in my case compass 466441 disappeared between version 4.0.0 and 4.0.1 when powered through power 1 on the pixhawk.