mavlink
Move SCALED_PRESSURE (and SCALED_PRESSURE2/3) to standard
This moves the SCALED_PRESSURE messages (and 2/3) variants to standard.xml.
These are present in both PX4 and ArduPilot - tests show they are emitted in at least copter for both cases, and also checked source for PX4.
The message are all identical with Ardupilot/mavlink and the move is 100% straight copy.
@peterbarker OK? @julianoes OK?
There is scope here differences between how PX4 populates these fields and how ArduPilot populates these fields.
We should make sure we're doing something similar, at least.
We send a number of SCALED_PRESSURE messages equal to the maximum of the number of barometers and the number of airspeed sensors you have. so if if you have 3 baros and 1 airspeed sensor then we will send three messages.
Zero is used to signify "no data". So in the above case you would expect to see non-zero data in press-abs and temperature in all three messages, and the first would have non-zero data in temperature-press-diff and press-diff.
Is that the same on PX4 Autopilot?
@peterbarker I think we are the same, but I need to confirm with @julianoes or others that uorb topics default to zero. Certainly this is what I think the intent is.
The detail is below.
A bit of debug (primarily for me).
- All three streamed outputs have the same implementations such as SCALED_PRESSURE but grab different UORB topic instances and output to the three messages.
- They are affected by updates to SensorBaro and DifferentialPressure. They will only update if either of these topics change.
- timestamp: Both sensor update and baro update populate timestamp, but only if their message is non-zero. Should be zero if both messages are zero. If either topic is zero and the other is not then it will be the populated timestamp. If both, then I believe the baro message used by preference [that might be wrong if there is a diff update but baro is non-zero already]. To check.
- From Baro
- msg.press_abs = sensor_baro.pressure * 0.01f; // Pa to hPa
- msg.temperature = roundf(sensor_baro.temperature * 100.f); // cdegC (centidegrees)
- From diff-pressure
- msg.press_diff = differential_pressure.differential_pressure_pa * 0.01f; // Pa to hPa
- msg.temperature_press_diff = roundf(differential_pressure.temperature * 100.f); // cdegC (centidegrees) - NAN if unknown according to docs
We send a number of SCALED_PRESSURE messages equal to the maximum of the number of barometers and the number of airspeed sensors you have. so if if you have 3 baros and 1 airspeed sensor then we will send three messages.
The data for a single message comes from the baro/diff-pressure that have the same id. So if you have three baro or three diffs you get three messages. However if you have two baro and one diff you get two message, because one baro and one diff "combine".
I think this is what you mean by your use example case.
Zero is used to signify "no data".
@julianoes Is that correct? I think uorb topic default to zero. The topic itself does not define this except for diff temperature which defaults to NaN.? If so, then this should be correct.
So in the above case you would expect to see non-zero data in press-abs and temperature in all three messages, and the first would have non-zero data in temperature-press-diff and press-diff.
The above case is "We send a number of SCALED_PRESSURE messages equal to the maximum of the number of barometers and the number of airspeed sensors you have. so if if you have 3 baros and 1 airspeed sensor then we will send three messages."
In this case we would send three messages populated from the three baros. The first would have info from the airspeed sensor. The other two would have zero values (confirming with Julian). That's what you mean right?
PS We will need to update the docs to say this before we move (at least the 0 default for not supplied). Isn't zero a valid value for the fields though?
timestamp: Both sensor update and baro update populate timestamp, but only if their message is non-zero. Should be zero if both messages are zero. If either topic is zero and the other is not then it will be the populated timestamp. If both, then I believe the baro message used by preference [that might be wrong if there is a diff update but baro is non-zero already]. To check.
There is the check if either of the topics is updated. If neither is, then no message is sent in the first place. So we shouldn't ever send out a message with timestamp 0.
I think uorb topic default to zero. The topic itself does not define this except for diff temperature which defaults to NaN.?
The message is initialized with 0, right here:
https://github.com/PX4/PX4-Autopilot/blob/d85994b521d5e9da7d376b2f8d71260c42cee9e2/src/modules/mavlink/streams/SCALED_PRESSURE.hpp#L69
So whatever isn't written is left 0.
The above case is "We send a number of SCALED_PRESSURE messages equal to the maximum of the number of barometers and the number of airspeed sensors you have. so if if you have 3 baros and 1 airspeed sensor then we will send three messages."
We only subscribe to diff pressure and baro uORB instance 0 for SCALED_PRESSURE:
https://github.com/PX4/PX4-Autopilot/blob/d85994b521d5e9da7d376b2f8d71260c42cee9e2/src/modules/mavlink/streams/SCALED_PRESSURE.hpp#L63-L64
Then we use uORB instance 1 for SCALED_PRESSURE2:
https://github.com/PX4/PX4-Autopilot/blob/d85994b521d5e9da7d376b2f8d71260c42cee9e2/src/modules/mavlink/streams/SCALED_PRESSURE2.hpp#L63-L64
And uORB instance 2 for SCALED_PRESSURE3:
https://github.com/PX4/PX4-Autopilot/blob/d85994b521d5e9da7d376b2f8d71260c42cee9e2/src/modules/mavlink/streams/SCALED_PRESSURE3.hpp#L63-L64
Does that answer all your questions @hamishwillee?
Does that answer all your questions @hamishwillee?
Thanks @julianoes - yes it does - essentially you've confirmed zero filled and the rest is as I thought.
@peterbarker The answer to your question is yes, PX4 and ArduPilot do behave the same way w.r.t. the specific cases you outlined. Are you OK with this update to the docs to reflect this: https://github.com/mavlink/mavlink/pull/2359/files#r2434142846 ?
NOTE, I haven't spelled out the number of sensors mapping because to my mind that is captured by the fact that the description indicates the sources are paired in the typical topic.
There is one caveat. See the comment on the extension field
Report values of 0 (or 1) as 1 cdegC.
PX4 does not do this. Does ArduPilot. IMO they should all do it for at least all the temperature fields, since 0C is a valid value. Thoughts?
On Tue, 21 Oct 2025, Hamish Willee wrote:
OK, I think good to go @peterbarker - let me know if you're happy. Noting that the ArduPilot version will no longer be quite aligned with the description.
Sorry, could you highlight where we've diverged, please?
On Tue, 21 Oct 2025, Hamish Willee wrote: OK, I think good to go @peterbarker - let me know if you're happy. Noting that the ArduPilot version will no longer be quite aligned with the description. Sorry, could you highlight where we've diverged, please?
- Addition of the invalid attributes as per https://github.com/mavlink/mavlink/pull/2359/files#r2434142846
- Titles change slightly from "Barometer readings for 2nd barometer" to "Pressure readings for a second setup, consisting of one absolute and one differential pressure sensor. Values are 0 if not supplied."
Meaning the same, just consistency updates between the three messages. Previously we aligned the messages and then moved them.
Thinking about Barometer, yes, it probably does make sense to have that too, and eventually deprecate this.
This may not be the right place to bring this up, but FYI ArduSub currently (ab)uses SCALED_PRESSURE3 as the mechanism for sending temperature sensor values, if there is a temperature sensor connected. Making dedicated messages for barometers and temperature sensors would be potentially valuable for reducing confusion and conflicts, and expanding possibilities.
I'd also be inclined to recommend such messages have explicit ID fields, rather than the message duplication approach taken by SCALED_PRESSURE and SCALED_IMU and the like, which seem needlessly hardcoded to small instance counts, and difficult for interfacing software to handle additions to dynamically.
This discussion sorta tells me that maybe SCALED_PRESSURE shouldn't go into standard and instead stay something odd in common and instead we'll have a proper baro and airspeed message in standard instead.
This discussion sorta tells me that maybe SCALED_PRESSURE shouldn't go into standard and instead stay something odd in common and instead we'll have a proper baro and airspeed message in standard instead.
@julianoes That might be sensible, IFF we can actually implement the AIRSPEED message in PX4.
On PX4 DifferentialPressure provides per-instance data, written to by each sensor driver. The sensors module then synthesizes an airspeed out of this and writes the result to the Airspeed topic, which is then used by EKF2 etc.
Actually, the airspeed reports at timestamp raw, so it may well be that this is actually mapped to a particular source (and not a true synthesized value), but either way we don't have that mapping I don't think.
The point here is that we don't have per instance airspeed - we have per instance source data and a final airspeed - but we have per instance AIRSPEED message.
So I'm not sure what we should do to implement. So how can we make this work?
GIven this is supposed to be per instance it probably should have been AIRSPEED_RAW to allow AIRSPEED to be a synthesized value.
@hamishwillee I think your assessment is correct, however, I would argue that this shouldn't hold us back to come up with the right MAVLink message. In the meantime, PX4 can send as id 0, or it can leave airspeed NAN, as you suggested.
I think it makes sense to be able to see the calculated airspeed of two sensors as telemetry, and so PX4 should make that happen. It already does this in a similarly for other sensors which are individually calibrated and published.
Thanks @julianoes - as always, the someone who "should make that happen" is the bottleneck. I can do the NaN option, but I don't think I could safely pull out the code to calculate the airspeed and create additional airspeed instances.
I wouldn't do the 0 index option unless ArduPilot is indexing from 1, which I suspect they are not. I might not anyway since to my mind this is more or less an "AIRSPEED_RAW" message - the fused message would have more information.