Message SCALED_IMU - magnetic field

[MrTypename]

According documentation message SCALED_IMU, magnetic field values (xmag, ymag, zmag) represent the magnetic field in [mT]. According to wikipedia the earth magnetic field is, in worst case, something around 65[uT]. Which is equal to 0.065[mT]. So casting 0.065[mT] to (int) results always in 0. It seems that value should be expressed in [uT] not [mT] ?

[hamishwillee]

Yes, that sounds like a screw up. @auturgy @julianoes You got any thoughts on thsi?

[auturgy]

ArduPilot uses mG internally. I’m not sure if there’s a 10^-4 somewhere to convert or we send mG not mT. Regards, James

…

On 11 Jul 2019, at 5:48 pm, Hamish Willee ***@***.***> wrote: Yes, that sounds like a screw up. @auturgy @julianoes You got any thoughts on thsi? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[hamishwillee]

Hmm. PX4 source docs think it is dealing in mT and there is no obvious scaling.

[auturgy]

(I should clarify that ArduPilot doesn’t send SCALED_IMU, but does send RAW_IMU)

…

On 12 Jul 2019, at 10:57 am, Hamish Willee ***@***.***> wrote: Hmm. PX4 source docs think it is dealing in mT and there is no obvious scaling. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[julianoes]

I had a look in PX4 and it looks like we send the "raw" sensor values, so not "scaled" at all but scaled by whatever is acquired from the sensors.
I checked the often used hmc5883 and it looks like the range is set to +/-2 Ga mapping to 12 bits -2048..2047. Of course that might differ for other sensors.

Also, PX4 doesn't seem to implement RAW_IMU.

So it looks like we should send what is currently in SCALED_IMU in RAW_IMU and implement SCALED_IMU correctly (to whatever spec makes sense).

https://github.com/PX4/Firmware/blob/2fbb70d9ca94f442de1345221be18ba738cda952/src/modules/mavlink/mavlink_messages.cpp#L957-L959

https://github.com/PX4/Firmware/blob/2fbb70d9ca94f442de1345221be18ba738cda952/msg/sensor_mag.msg#L13-L15

https://github.com/PX4/Firmware/blob/2fbb70d9ca94f442de1345221be18ba738cda952/src/drivers/magnetometer/hmc5883/hmc5883.cpp#L891-L894

[julianoes]

Would it make sense to add a message RAW_IMU2 and RAW_IMU3 for consistency?

[hamishwillee]

Thanks @julianoes

So it looks like we should send what is currently in SCALED_IMU in RAW_IMU

Yes.

Would it make sense to add a message RAW_IMU2 and RAW_IMU3 for consistency?

I would do it if someone will use the message. What is RAW_IMU used for now, and will the logic apply also to 2, and 3?

implement SCALED_IMU correctly (to whatever spec makes sense).

Sounds good. Do you have a view on what is sensible?

With x,y,z int16 fields we have decimal values of +/- 32767. Earth max field strength is 65 µT. This particular sensor gives us +/- 2 Gauss = 200 µT = 20000nT.

Even though they are not an SI unit, I am tempted by mili gauss [mG].

• This is what ardupilot use. It gives a fairly good granularity (-2000 to + 2000) for this sensor.
• Using µT gives us a range of =/- 200 which seems wasteful for range and low resolution
• Using nT gives us great resolution, but we'd have to cap scaled values to around 3 Ga. That might be fine - do we know what values systems like EKF can actually use?

@auturgy do you have a view on all that?

[auturgy]

mG is zero change for ArduPilot, so sounds good to me. Whilst it’s not the SI unit, it’s in common use and is simple to convert with zero loss for anyone who needs T. Regards, James

…

On 25 Jul 2019, at 5:07 pm, Hamish Willee ***@***.***> wrote: Thanks @julianoes So it looks like we should send what is currently in SCALED_IMU in RAW_IMU Yes. Would it make sense to add a message RAW_IMU2 and RAW_IMU3 for consistency? I would do it if someone will use the message. What is RAW_IMU used for now, and will the logic apply also to 2, and 3? implement SCALED_IMU correctly (to whatever spec makes sense). Sounds good. Do you have a view on what is sensible? With x,y,z int16 fields we have decimal values of +/- 32767. Earth max field strength is 65 µT. This particular sensor gives us +/- 2 Gauss = 200 µT = 20000nT. Even though they are not an SI unit, I am tempted by mili gauss [mG]. This is what ardupilot use. It gives a fairly good granularity (-2000 to + 2000) for this sensor. Using µT gives us a range of =/- 200 which seems wasteful for range and low resolution Using nT gives us great resolution, but we'd have to cap scaled values to around 3 Ga. That might be fine - do we know what values systems like EKF can actually use? @auturgy do you have a view on all that? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[julianoes]

Using µT gives us a range of =/- 200 which seems wasteful for range and low resolution
Using nT gives us great resolution, but we'd have to cap scaled values to around 3 Ga. That might be fine - do we know what values systems like EKF can actually use?

That's what I'm wondering too. What are common and outlier values?

[hamishwillee]

OK, so mG is a good fallback. To do due diligence I've asked about range on the PX4 slack estimation channel: https://px4.slack.com/archives/C643UJTB7/p1564098198007100
Ideally they will say range greater than 3Ga needed, and we can just settle on mG.

If we can't get an answer within a week or 2 then I vote we just settle on mG.

[hamishwillee]

Would it make sense to add a message RAW_IMU2 and RAW_IMU3 for consistency?

I would do it if someone will use the message. What is RAW_IMU used for now, and will the logic apply also to 2, and 3?

Don't know if either of you had answer to this. But further thought is that IF these are needed, then we should consider using a message with an IMU ID.

[auturgy]

ArduPilot uses RAW_IMU for the primary, SCALED_IMU2/3 for additionals. That’s known not to be ideal. There might be history as to why RAW_IMU2/3 weren’t added, I don’t know. It makes sense to me to add them. Regards, James

…

On 26 Jul 2019, at 9:47 am, Hamish Willee ***@***.***> wrote: Would it make sense to add a message RAW_IMU2 and RAW_IMU3 for consistency? I would do it if someone will use the message. What is RAW_IMU used for now, and will the logic apply also to 2, and 3? Don't know if either of you had answer to this. But further thought is that IF these are needed, then we should consider using a message with an IMU ID. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[hamishwillee]

Thanks @auturgy .

1. So I propose that we add an extension field id to RAW_IMU to support multiple IMUs, with values from 1 up.
   • I know this is inconsistent with SCALED_IMU having versions 2, 3, but I think it is a generally more logical approach. Happy to discuss.
   • For this message, is it reasonable to specify "now" that max value of int16_t for all fields mean "not supported"? Or will all values always be supported?
2. Still no response re the units for scaled IMU and default position still to use mGa.

[hamishwillee]

Discussed in dev call. I have created #1199 and #1200 to address.