AP_TemperatureSensor: Support Servo_Telem sources

[rob-clarke]

Add support for updating motor and PCB temperatures in Servo_Telem from AP_TemperatureSensor backends.

Supports integrating temperature reports from DroneCAN servos using ActuatorStatus, as that message does not include a temperature field.

Testing

Tools/scripts/build_all.sh completes successfully.

Tested by sending uavcan.equipment.device.Temperature messages from DroneCAN GUI's interactive console to SITL initially configured with:

• LOG_DISARMED: 1
• TEMP1_TYPE: 6 (DroneCAN)
• TEMP1_MSG_ID: 5
• TEMP1_SRC_ID: 1
• TEMP1_SRC: 3 (Battery_Index)

DroneCAN temperature messages were sent with a temperature of approximately 23 C and were recorded as battery temperature (BAT[0].Temp) in the log.

TEMP1_SRC was then modified to a value of 7 (ServoMotor), added in this PR. Temperature messages were sent with a value of approximately 100 C and were recorded as servo motor temperature (CSRV[0].MotT) in the log.

Finally, TEMP1_SRC was then modified to a value of 8 (ServoPCB), also added in this PR. Temperature messages were sent with a value of approximately -100 C and were recorded as servo PCB temperature (CSRV[0].PCBT) in the log.

Graph of the log from MissionPlanner:

Queries

1. I'm not sure about the placement of AP_Servo_Telem::get_singleton. Running that for every report feels like a waste. This could be done in the switch case.
2. Is there a reason the current code initialises variables outside of the switch? It feels cleaner to have:

switch ((AP_TemperatureSensor_Params::Source)_params.source.get()) {
    //...
    case AP_TemperatureSensor_Params::Source::ServoMotor: {
        AP_Servo_Telem *servo_telem = AP_Servo_Telem::get_singleton();
        if (servo_telem == nullptr) {
            break;
        }
        AP_Servo_Telem::TelemetryData servo_telem_data;
        servo_telem_data.motor_temperature_cdeg = temperature * 100;
        servo_telem_data.present_types = AP_Servo_Telem::TelemetryData::Types::MOTOR_TEMP;
        servo_telem->update_telem_data(_params.source_id-1, servo_telem_data);
        break;        
    }
    //...
}

[IamPete1]

Nice, I think this looks good. Dealers choice on that variable stuff, I agree with you that its nicer to do it in the switch. You could do inline initialization of the telem object.

        const AP_Servo_Telem::TelemetryData servo_telem_data {
            .motor_temperature_cdeg = temperature * 100
            .present_types =  AP_Servo_Telem::TelemetryData::Types::MOTOR_TEMP
        }

[rob-clarke]

Looks like moving the declarations impacts binary size. Text size for plane is:

• 4273359B with declarations and get_singleton() outside the switch cases
• 4273375B (+16B) with only servo_telem pointer declaration and get_singleton() inside the cases
• 4273423B (+64B) with everything inside the cases

For consistency with the existing style I'll stick with declarations outside the switch, but will move the get_singleton() call inside to avoid making the call when not needed.

[IamPete1]

Looks good.

It is worth noting that ESC has a explicit "external" temperature source type which allows replacing a ESC provided temperature. I don't think we necessarily need that here but it is worth noting that is a servo already has a temperature reading this will not work as expected. It may also result in servo telem data seeming to be upto date when in fact its just the temperature changing from this external source. But I don't think all that needs to be done in this PR.