Some questions about the dsdl file under /uavcan/equipment/power about public_regulated_data_types HOT 2 CLOSED

Your questions appear to be rooted in certain architectural deficiencies of UAVCAN v0 that have been addressed in v1.

What is the meaning of hours_to_empty_at_10sec_avg_power_variance in 1. PrimaryPowerSupplyStatus(message type id:1090), and whether the calculation method is directly calculated by the variance formula?

If hours_to_empty_at_10sec_avg_power is the estimated time to empty, then hours_to_empty_at_10sec_avg_power_variance is the error variance of said estimate. Make it zero if unknown.

2.1 What does circuit_id refer to?
3.2 battery_id：If one battery pack is 0, but there are multiple battery packs, how to allocate this ID?

This is the most critical design fault of v0: the data type definition makes undue assumptions about the architecture of the distributed system it is supposed to facilitate. The field in question is intended to segregate different electrical circuits within the vehicle. For instance, your primary power source could bear the ID of 0, the power supply of a servo would be id=1, and so on.

In v1, this is handled in an entirely different manner that is aligned with the principles of modern software design: instead of dealing with IDs, your data types contain only the application-level items, and the task of functional segregation is implemented based on port-IDs instead of instance IDs. This is reviewed in The Guide.

Whether the voltage and current here are consistent with the voltage and current of 1092 does not represent what it means

The semantics of these measurements are application-defined. You need to know the architecture of the vehicle to understand what does every ID represent. Similarly, in v1, you need to know the architecture of the vehicle to understand what port-IDs should be used.

3.1 temperature：Only one temperature? How to send if there are multiple temperatures?

Find a sensible reduction. For instance, send the maximum temperature, or average.

3.3 Bit 5 STATUS_FLAG_OVERLOAD: Does it mean that the power is too large, or the current is too large?

This flag indicates that a critical parameter that is directly coupled with the instantaneous power output of the device is outside of the recommended operating conditions. This could be the electric power, electric current, temperature, voltage, or any other quantitiy depending on the construction of the device. The objective of this flag is to communicate to the controller (whether human or automatic) that the current conditions are abnormal and the controller should seek to reduce the power consumption.

You should know that UAVCAN v0 will become obsolete in the foreseeable future. The UAVCAN Consortium is currently working on the new application-layer standard that will replace the design that you are currently working with. If you want to take part in this effort, consider applying here: https://uavcan.org/consortium

Also, the correct place for discussions of this variety is on the forum at https://forum.uavcan.org/. If you have any further questions, please, post them over there. I am going to close this issue now.

from public_regulated_data_types.

Your questions appear to be rooted in certain architectural deficiencies of UAVCAN v0 that have been addressed in v1.

What is the meaning of hours_to_empty_at_10sec_avg_power_variance in 1. PrimaryPowerSupplyStatus(message type id:1090), and whether the calculation method is directly calculated by the variance formula?

If hours_to_empty_at_10sec_avg_power is the estimated time to empty, then hours_to_empty_at_10sec_avg_power_variance is the error variance of said estimate. Make it zero if unknown.

2.1 What does circuit_id refer to?
3.2 battery_id：If one battery pack is 0, but there are multiple battery packs, how to allocate this ID?

This is the most critical design fault of v0: the data type definition makes undue assumptions about the architecture of the distributed system it is supposed to facilitate. The field in question is intended to segregate different electrical circuits within the vehicle. For instance, your primary power source could bear the ID of 0, the power supply of a servo would be id=1, and so on.

In v1, this is handled in an entirely different manner that is aligned with the principles of modern software design: instead of dealing with IDs, your data types contain only the application-level items, and the task of functional segregation is implemented based on port-IDs instead of instance IDs. This is reviewed in The Guide.

Whether the voltage and current here are consistent with the voltage and current of 1092 does not represent what it means

The semantics of these measurements are application-defined. You need to know the architecture of the vehicle to understand what does every ID represent. Similarly, in v1, you need to know the architecture of the vehicle to understand what port-IDs should be used.

3.1 temperature：Only one temperature? How to send if there are multiple temperatures?

Find a sensible reduction. For instance, send the maximum temperature, or average.

3.3 Bit 5 STATUS_FLAG_OVERLOAD: Does it mean that the power is too large, or the current is too large?

This flag indicates that a critical parameter that is directly coupled with the instantaneous power output of the device is outside of the recommended operating conditions. This could be the electric power, electric current, temperature, voltage, or any other quantitiy depending on the construction of the device. The objective of this flag is to communicate to the controller (whether human or automatic) that the current conditions are abnormal and the controller should seek to reduce the power consumption.

You should know that UAVCAN v0 will become obsolete in the foreseeable future. The UAVCAN Consortium is currently working on the new application-layer standard that will replace the design that you are currently working with. If you want to take part in this effort, consider applying here: https://uavcan.org/consortium

Also, the correct place for discussions of this variety is on the forum at https://forum.uavcan.org/. If you have any further questions, please, post them over there. I am going to close this issue now.

Thank you so much

from public_regulated_data_types.