-
Notifications
You must be signed in to change notification settings - Fork 13.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clean up temperature msg fields #24272
base: main
Are you sure you want to change the base?
Conversation
e60a339
to
695bfb9
Compare
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: -96 byte (-0 %)]
px4_fmu-v6x [Total VM Diff: -72 byte (-0 %)]
Updated: 2025-02-06T17:33:25 |
{ | ||
vehicle_air_data_s air_data; | ||
|
||
if (_vehicle_air_data_sub.update(&air_data)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will need a small edit of the comment in the MAVLink message.
"Air temperature from airspeed sensor" is no longer valid.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sfuhrer It doesn't work that way - if this PR merges PX4 is no longer compliant with the MAVLink specification. The message itself is fine :-)
Whether we can update the message in MAVLink depends on whether there is a semantic difference that matters to consumers. I don't know, but that requires agreement with other stakeholders.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know, and we'll update the wording on the mavlink RP. Never the less, we're convinced that this is the right approach.
@haumarco to be compliant with the mavlink message we can for now also subscribe to differential_pressure.temperature here.
float32 baro_pressure_pa # Absolute pressure in Pascals | ||
float32 ambient_temperature # Abient temperature in degrees Celsius |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add a flag for the source of this field? Differential pressure, external baro, default ambient air temperature?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok. added enum for temperature source
0: Default value, i.e. 15°C
1: External baro
2: Airspeed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe "default" should be more like "not available" (N/A)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean I should only change the naming from Default to NA or also change the Default/NA data?
I want to have the default temperature (15 deg) to be published when we dont have a external sensor. Also to avoid multiple definitions of "default" temperature values at the subscribers as mentioned in my previous comment. #24272 (comment)
Can you clarify if you simply care about the naming or also the value? NA would not be a good match IMO when I still enter a default value
@@ -193,7 +193,7 @@ class MavlinkStreamHighresIMU : public MavlinkStream | |||
msg.abs_pressure = air_data.baro_pressure_pa; | |||
msg.diff_pressure = differential_pressure.differential_pressure_pa; | |||
msg.pressure_alt = air_data.baro_alt_meter; | |||
msg.temperature = air_data.baro_temp_celcius; | |||
msg.temperature = air_data.ambient_temperature; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't that field be filled with the IMU temperature? How about subscribing to vehicleImuStatus.msg/temperature_accel or _gyro?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The temperature field in HIGHRES_IMU seems a bit arbitrary. Since it takes the other data-fields from the air_data, I would keep it like that.
If the user wants the IMU data, one can access it over SCALED_IMU or RAW_IMU
vehicle_air_data_s air_data; | ||
|
||
if (_vehicle_air_data_sub.update(&air_data)) { | ||
_temperature.add_value(air_data.ambient_temperature, _update_rate_filtered); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we only publish a value if it's actually coming a sensor and is not the hard coded 15°C?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I now also added the enum to specify the temperature source to the msg, I think having the default value published can be useful. It avoids a sanity check and definition of another default temperature at the Subscriber...
Solved Problem
Currently, multiple temperature measurements are used across different functionalities to represent ambient temperature. This creates ambiguity regarding which temperature measurement should be designated as
vehicle_temperature
. We lack dedicated temperature sensors or topics to consistently rely on a single source.Solution
Implement a prioritized selection of temperature sensors. When an external airspeed sensor is available, its temperature is used as the primary source. If an external barometer is present, its temperature serves as the secondary option. The temperature from the internal barometer is disregarded due to its unreliability, which is caused by inconsistent PCB heat dissipation across different flight controllers.
Changelog Entry
Create a distinct ambient_temperature field in the VehicleAirData message.
Alternatives
An alternative approach would be to create a dedicated temperature uORB topic to centralize ambient temperature data.
Test Coverage
Tested with various setups and hardcoded measurements in simulation environments to ensure reliability and accuracy.