ardupilot
ardupilot copied to clipboard
ArduPilot
Scale adjusted because QMC5883L modules deliver a multiple value
I have several airplanes and drones that I have equipped with GPS modules. Among them are BN-880 and HGLRC M80 PRO. I have used the BN-880s that are also suitable for APM and Pixhawk according to the description. Most of the time, however, a QMC5883 was fitted. The compass could never be calibrated with this chip. In the telemetry of the remote control transmitter I saw that the Gaussian values reached the 4000 mark quite quickly and showed virtually no sine function with further rotation. I then used the really great MAGFit web tool to calibrate the compass by generating the correction parameters. I noticed that the measured Gaussian values were very large and the error message "PreArm: Check mag field (xy diff:373>100)" appeared in the messages. Of course several times and with different values.
I then started to read out the compass modules with a Raspberry Pi Pico via i2c and took a closer look at the measured Gauss values. I also played around with the parameter settings. I noticed that setting the Gauss Scale Rate does not change the output value, except for a single module and that was an Arduino test board.
So I think it makes sense to leave the Gaussian rate at the default and simply divide the output value by 4. I also got the idea from an INAV, as there is a scale factor that was set to ~4000 for my tested modules.
The other idea I had was to introduce such a scale factor in Adopilot, which would probably be more complex.
Best regards and thank you very much for your great work (sorry - I mistakenly deleted the first request)
Looks like this would break my MiniPix here:
Your branch is the first part of the graph, master is the second half of the graph.
Your counts are about the same as my measurement
Yep. So we can't merge this as-is, we'll need an option bit to change the scale.
This is complicated by the fact that you might have multiple QMC5883L devices, some of them external to the autopilot.
Hey, is there any plan on implementing this? Ive had lots of mag field diff 234>100 errors and simmilar and this seems like a possible fix? Im using a GM10 RPO V3 with an QMC5883L chip.
Hey, is there any plan on implementing this? Ive had lots of mag field diff 234>100 errors and simmilar and this seems like a possible fix? Im using a GM10 RPO V3 with an QMC5883L chip.
Have you tried flashing a firmware based on this branch and seeing if it resolves the issue? If so I can perhaps push this alonng if @dg9oaa has lost interest.
The complication is that we don't have option bitmasks per compass backend - so we can't choose which compasses to apply a different scaling to.
Ideally, we somehow detect the different QMC5883L and adjust scaling accordingly.
Hello, sorry, I only saw the message now. Which firmware is/was used? And yes, the problem can probably be solved via the scale factor. The QMC5883L chips behave differently when you use the gain factors. Sometimes they work and sometimes they don't. My experience value is a factor of 4, which may be taken into account. --> COMPASS_SCALE 0.25
I also use the ArduPilot MAGFit tool. There, the logs can be evaluated quite well after the flight and values that are too large are visualized nicely. Perhaps it would also be an idea to extend the ArduPilot MAGFit tool so that it also spits out the scaling factors.
I wonder if something like what Andy did here: https://github.com/ArduPilot/ardupilot/issues/29612 might be applicable to the L-series. Strangely the patch @andyp1per referenced as closing that issue isn't actually in master...
I wonder if something like what Andy did here: #29612 might be applicable to the L-series. Strangely the patch @andyp1per referenced as closing that issue isn't actually in master...
It actually just worked, so no patch necessary
ChatGPT tells me this is a well-known problem. There is apparently no way to tell a-priori if your silicon has the issue. So assuming 2G scaling and dividing seems like a robust way of coping.
ChatGPT tells me this is a well-known problem. There is apparently no way to tell a-priori if your silicon has the issue. So assuming 2G scaling and dividing seems like a robust way of coping.
So best we can do is document (@Hwurzburg) and perhaps add scaling to the online tools (@IamPete1 ).
@dg9oaa we can't accept this PR as it breaks existing setups. From what Andy says the problem isn't solvable within the ArduPilot codebase.
Are we OK to close this PR?
@peterbarker happy to add something in the wiki, if someone writes up a clear explanation of who/what/when/why as to how to recognize the issue, on what devices, and how to fix...even a online cautionary note of units to avoid, if the previous info is too complex, might be worthwhile
@dg9oaa we can't accept this PR as it breaks existing setups. From what Andy says the problem isn't solvable within the ArduPilot codebase.
We obviously could create an option ...
We do have a scale parameter, we could detect the QMC and allow MAGFit to accept a wider range of valid values for that sensor.
We do have a scale parameter, we could detect the QMC and allow MAGFit to accept a wider range of valid values for that sensor.
The point is that not all QMC's exhibit this