PX4Magnetometer.cpp: Workaround for sensors not initializing with all the magnetometers #23972
+11
−0
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ors not initializing with all the magnetometers There is some issue with "sensors" module; it only takes into account the magnetometers which have published data before the module start. Workaround this issue by publishing some initial "0" data right at the time of constructing the magnetometer driver. If the probing of the sensor fails, the orb gets anyhow unadvertised, so there is no extra sensor data lying around in the case the magnetometer is not present. This also forces the magnetometer numbering to follow the startup order; without advertising the data the orb numbering depends on magnetometer initialization sequence - a magnetometer started later in the init scripts may publish it's first data before some other mag, which was started earlier. This is especially problematic when using the same scripts on different HW platforms which run on different speeds. Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
jlaitine
force-pushed
the
workaround_sensors_not_reading_all_mags
branch
from
c87f18e
to
e714f37
Compare
It shouldn't break calibration since the CAL parameters are tied to the DeviceID, eg CAL_MAG0_ID But I agree it would be nice to have consistent uORB order for log analysis and debugging |
Thanks for the comment, I stand corrected! Maybe the "calibration issues" which have been reported to me were about confusion created by attempting to disable a specific sensor or such on different HWs. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a workaround for two issues I am having with the magnetometers. I am running still on 1.14.3, and I tried to study if there are related fixes in 1.15, but didn't find any. So I am offering this one to upstream as well.
If there are better ways to fix these issues, or if they are somehow fixed already and I missed it, please let me know / reject this PR.
So, I am having 2 issues with magnetometers using the following setup:
2 magnetometers in the drone, one internal (bmm350) and one external (ist8310). BMM350 is started first in the rc scripts, ist8310 is started second.
1st issue:
The magnetometers get initialized with state machines running in a work queue, and the initializing RC script runs in parallel to the work queue. On a slightly faster FMU, the ist8310 magnetometer (started second in the rc script) manages to advertise it's uORB before the bmm350. So on this HW the external mag becomes "MAG_0", while on the slightly slower FMU the bmm350 (which was started first by the RC script) manages to advertise it's uORB first, so on that HW the internal mag becomes "MAG_0". With a very bad luck, the numbering becomes random, that is, it varies from boot to boot which one is 0 and which one is 1. This breaks many things (like calibration) and confuses people.
2nd issue
On a certain drone chassis I want to disable the internal magnetometer. I am doing that by setting parameter "CAL_MAG0_PRIO" to 0 ( now assuming that it happens to be 0, considering the first issue above ).
Now, RC script is still running in parallel with the work queues running the magnetometer initialization. It may happen that the "sensors" module gets started by the RC script before my "MAG_1" publishes it's first data. For some reason, the sensors module is not taking the newly appearing magnetometer into account any more.
** workaround for the issues above **
This patch publishes some initial "0" data right at the time of constructing the magnetometer driver. If the probing of the sensor fails, the orb gets anyhow unadvertised, so there is no extra sensor data lying around in the case the magnetometer is not present.
This also forces the magnetometer numbering to follow the startup order; without advertising the data the orb numbering depends on magnetometer initialization sequence - a magnetometer started later in the init scripts may publish it's first data before some other mag, which was started earlier. This is especially problematic when using the same scripts on different HW platforms which run on different speeds.