TemperatureSensor: Add Rangefinder to the TEMPx_SRC sensor source options

[ES-Alexander]

Feature request

Is your feature request related to a problem? Please describe.
Rover (and hopefully soon Sub) make use of a WATER_DEPTH MAVLink message, which includes temperature data from a downward-facing rangefinder. Rangefinders don't always include temperature sensors (or they may not be super accurate), so it could be nice to be able to sub that in from a dedicated temperature sensor.

Describe the solution you'd like
Add a Rangefinder option to the temperature sensor source options, to allow the rangefinder driver temperature data to be overshadowed via the TEMPx_SRC parameters.

Describe alternatives you've considered

1. The WATER_DEPTH message could automatically fall back to another temperature source if one is provided, but that either reliant on the rangefinder not providing temperature data, or makes it ambiguous as to what is being used
2. The source could be specified as "water temperature" instead of specifically rangefinder, which could make it more broadly useful in future, but also makes it less clear when and where it's likely to be used.
3. We could add dedicated MAVLink reporting for temperature sensors, and/or specifically for water temperature, which are both potentially good ideas, but then it's potentially unclear what source is being used for the temperature data in the WATER_DEPTH message

Platform
[ ] All
[ ] AntennaTracker
[ ] Copter
[ ] Plane
[x] Rover
[x] Submarine

Additional context
#31616 may be a good reference for the temperature sensor library side of things.

[Parshv-sudo]

Hi @ES-Alexander,

I’ve been going over the AP_TemperatureSensor_Params setup and wanted to confirm my understanding before I move ahead.
It looks like this could fit into the current temperature routing model without needing changes to MAVLink or rangefinder drivers.

Here’s my idea:

• Add a Rangefinder option to AP_TemperatureSensor_Params::Source, similar to the ESC and Servo sources in AP_TemperatureSensor: Support Servo_Telem sources #31616.
• When TEMPx_SRC = Rangefinder, treat the temperature sensor as an explicit external override for the rangefinder frontend.
• Make the rangefinder frontend prefer this value over driver-reported temperatures for WATER_DEPTH while keeping MAVLink packing and backend code the same.

This keeps the feature optional, maintains defaults, and follows the same override pattern. I would appreciate your thoughts on whether this approach makes sense or if you’d recommend a different direction.

I’m happy to make changes before proceeding.

[ES-Alexander]

Hi @Parshv-sudo,

I think the approach you've outlined generally makes sense, with a minor caveat:

• When TEMPx_SRC = Rangefinder, treat the temperature sensor as an explicit external override for the rangefinder frontend.
• Make the rangefinder frontend prefer this value over driver-reported temperatures for WATER_DEPTH while keeping MAVLink packing and backend code the same.

This combination doesn't completely make sense to me. If the temperature sensor is acting as an override in the rangefinder frontend (which does seem like the desired behaviour 👍 ), then the code for WATER_DEPTH MAVLink message creation (and anywhere else the rangefinder's temperature is being used) shouldn't need to know or care that that's happening - they just use whatever value the rangefinder frontend is reporting.

I agree that MAVLink packing and backend code should not be affected.

This keeps the feature optional, maintains defaults, ...

Indeed - the feature will only be accepted if it is optional, and does not break any existing functionality or expectations.

[Parshv-sudo]

Thanks for the feedback @ES-Alexander. That makes sense.

In other words, the override will be handled entirely in the rangefinder frontend. Any users downstream, including WATER_DEPTH MAVLink packing, won’t know if the temperature comes from the driver or an external sensor. They will just use whatever value the frontend provides.

With that clarification, I think I can proceed with the approach we discussed. The feature will be completely optional, and existing behavior will be kept by default.

[anishk85]

Hey @ES-Alexander! I think i have solved this issue i will be submitting a pr by tomorrow eod
are there any testing method by which i can get this tested too

AP_TemperatureSensor_Params.h
AP_TemperatureSensor_Params.cpp
AP_RangeFinder.h
AP_RangeFinder.cpp
Rover/GCS_MAVLink_Rover.cpp
Rover/config.h

these were the files which i changed
below are logs through which i confirmed is there any other way too

[ES-Alexander]

I think i have solved this issue i will be submitting a pr

Nice - thanks!

are there any testing method by which i can get this tested too

You should be able to test it by confirming the temperature sensor value gets used somewhere that's ordinarily using the rangefinder temperature. You could run a check for where that is, but from the issue context it's at least the case that Rover uses it for the WATER_DEPTH messages when configured as a boat.

I'm not yet very familiar with ArduPilot's standard testing procedures but it does look like there are simulation options for both rangefinders and temperature sensors in SITL, so it should be possible to load those in a Rover boat simulation, then check if the WATER_DEPTH message displays non-zero temperature values. As specific example instances, I know there are TSYS01 packages that are rated for use underwater, and both the BLPing and MAVLink-based rangefinders can be used in water and don't provide temperature readings (so should default to 0.0 temperature values in the WATER_DEPTH message).

Note that SITL testing could be turned into an autotest like this one, in which case it could be used to ensure the functionality keeps working as the codebase evolves.

I should also be able to do a test with physical hardware, but I'm about to go on a trip, so if I don't get to it in early January then I won't be able to until the end of January. I may be able to get someone else to do a physical test, but no guarantees on timeliness.

Rover/GCS_MAVLink_Rover.cpp

I am uncertain why this would need to be changed, as my understanding (which may be incorrect) is that the overrides should happen at / just over the driver level, so the "user" code shouldn't need to know about them. That said, I should be able to find out the details of your approach in your PR, and it's quite possible you've done something reasonable that I just haven't thought of :-)

[anishk85]

Rover/GCS_MAVLink_Rover.cpp - Changed WATER_DEPTH to use [get_temp_with_override()] which was defined in AP_RangeFinder.cpp

Rover/GCS_MAVLink_Rover.cpp

I am uncertain why this would need to be changed, as my understanding (which may be incorrect) is that the overrides should happen at / just over the driver level, so the "user" code shouldn't need to know about them. That said, I should be able to find out the details of your approach in your PR, and it's quite possible you've done something reasonable that I just haven't thought of :-)

[has1172]

Hello @ES-Alexander, I would like to work on this. I found the Source enum in AP_TemperatureSensor_Params.h and plan to add the Rangefinder = 9 backend. I'm starting to work on the implementation in AP_TemperatureSensor.cpp now.