Offboard temp cal: check topic instance

[bresch]

relates to #14776

I found out that the script was assuming that the multi topics instance are appearing in order but it isn't always the case. In my case, the instance 1 appears before the 0.
Before fix (the 2nd IMU was assumed 0)

After fix (primary is 0)

[dagar]

In my case, the instance 1 appears before the 0.
Before fix (the 2nd IMU was assumed 0)

I'm not sure I follow, what do you mean "instance 1 appears before the 0"? Are you saying the instance numbering of the logged topic (ulg) is inconsistent with the system?

[dagar]

You might as well add sensor_baro 2. We're already carrying the parameters. https://github.com/PX4/Firmware/blob/c96b5246ffc50eeceef5aad0a31068a00f2b672b/src/modules/temperature_compensation/temp_comp_params_baro.c#L233-L319

[bresch]

I added that in f938b17 . I followed the copy-paste pattern...

[bresch]

I'm not sure I follow, what do you mean "instance 1 appears before the 0"? Are you saying the instance numbering of the logged topic (ulg) is inconsistent with the system?

When looping through the topics:

for d in data:
    if d.name == 'sensor_accel':

The instance 1 of sensor_accel appeared before the instance 0

[dagar]

I'm not sure I follow, what do you mean "instance 1 appears before the 0"? Are you saying the instance numbering of the logged topic (ulg) is inconsistent with the system?

When looping through the topics:

for d in data:
    if d.name == 'sensor_accel':

The instance 1 of sensor_accel appeared before the instance 0

Right ok, so even though we're now careful to advertise the drivers consistently we still have a race condition for first publication.

Removing all ordering assumptions and always referencing device id is still the way to go, but we may want to look at log changes later to remove the potential discrepancy.

[bkueng]

As the script uses device id's, I don't see anything wrong per se, just the plotting that is confusing.