Description of a generic musical note in terms of basic physical quantities.

This type may be used to control sound notification emitters assuming the best effort policy:
if the requested parameters exceed the capabilities of the emitter, the closest possible values should be assumed.

+ uavcan.si.unit.frequency.Scalar (v1.0) frequency [extent 4.0 bytes] [max length 4.0 bytes]

+ uavcan.si.unit.duration.Scalar (v1.0) duration [extent 4.0 bytes] [max length 4.0 bytes]

+ uavcan.si.unit.power.Scalar (v1.0) acoustic_power [extent 4.0 bytes] [max length 4.0 bytes]

DC or AC line electric power quantities. Generally, the following current sign convention applies:

  - Positive current flows from the electric power supply network to the load (e.g., an actuator).

  - If the electric network is the load itself powered from a source (e.g., battery), the current is negative.

+ uavcan.si.unit.electric_current.Scalar (v1.0) current [extent 4.0 bytes] [max length 4.0 bytes]

+ uavcan.si.unit.voltage.Scalar (v1.0) voltage [extent 4.0 bytes] [max length 4.0 bytes]

+ uavcan.time.SynchronizedTimestamp (v1.0) timestamp [extent 7.0 bytes] [max length 7.0 bytes]

Nested data type used for representing a network-wide synchronized timestamp with microsecond resolution.
This data type is highly recommended for use both in standard and vendor-specific messages alike.

The number of microseconds that have passed since some arbitrary moment in the past.
The moment of origin (i.e., the time base) is defined per-application. The current time base in use
can be requested from the time synchronization master, see the corresponding service definition.

This value is to never overflow. The value is 56-bit wide because:

  - 2^56 microseconds is about 2285 years, which is plenty. A 64-bit microsecond counter would be
    unnecessarily wide and its overflow interval of 585 thousand years induces a mild existential crisis.

  - Classic-CAN (not FD) transports carry up to 7 bytes of payload per frame.
    Time sync messages shall use single-frame transfers, which means that the value can't be wider than 56 bits.

Zero means that the time is not known.

+ reg.drone.physics.electricity.Power (v0.1) value [extent 8.0 bytes] [max length 8.0 bytes]

DC or AC line electric power quantities. Generally, the following current sign convention applies:

  - Positive current flows from the electric power supply network to the load (e.g., an actuator).

  - If the electric network is the load itself powered from a source (e.g., battery), the current is negative.

A generic source or sink of electric power (battery, turbogenerator, braking resistor, etc.).
Low-pass filtering should be applied to avoid aliasing effects (as is the case everywhere else).

+ reg.drone.physics.electricity.Power (v0.1) power [extent 8.0 bytes] [max length 8.0 bytes]

DC or AC line electric power quantities. Generally, the following current sign convention applies:

  - Positive current flows from the electric power supply network to the load (e.g., an actuator).

  - If the electric network is the load itself powered from a source (e.g., battery), the current is negative.

Total instant load power.
Positive current flows into the source (power sinking).
Negative current flows from the source to the power supply network (power sourcing).

+ uavcan.si.unit.energy.Scalar (v1.0) energy [extent 4.0 bytes] [max length 4.0 bytes]

A pessimistic estimate of the amount of energy that can be reclaimed from the source in its current state.
This may be dependent on the state of charge/health (for batteries), temperature, load profile, humidity, etc.
Negative values may be reported to indicate overdischarge or depletion of the reserve energy.

This value approximates (full_energy + int(load_power dt)) plus the environmental influences on the source.

Having the instant power, the time to depletion is estimated as (energy/-power).
When charging (for batteries), the remaining time to full charge can be found similarly as
((full_energy-energy)/power).

For the sake of illustration, if this type was used to represent the state of a braking resistor,
then this value would be negative indicating the amount of dissipated energy.

+ uavcan.si.unit.energy.Scalar (v1.0) full_energy [extent 4.0 bytes] [max length 4.0 bytes]

A pessimistic estimate of the amount of energy that can be reclaimed from a fresh source (fully fueled generator
or a fully charged battery) under the current conditions (SoH, temperature, load profile, etc).

+ uavcan.time.SynchronizedTimestamp (v1.0) timestamp [extent 7.0 bytes] [max length 7.0 bytes]

Nested data type used for representing a network-wide synchronized timestamp with microsecond resolution.
This data type is highly recommended for use both in standard and vendor-specific messages alike.

The number of microseconds that have passed since some arbitrary moment in the past.
The moment of origin (i.e., the time base) is defined per-application. The current time base in use
can be requested from the time synchronization master, see the corresponding service definition.

This value is to never overflow. The value is 56-bit wide because:

  - 2^56 microseconds is about 2285 years, which is plenty. A 64-bit microsecond counter would be
    unnecessarily wide and its overflow interval of 585 thousand years induces a mild existential crisis.

  - Classic-CAN (not FD) transports carry up to 7 bytes of payload per frame.
    Time sync messages shall use single-frame transfers, which means that the value can't be wider than 56 bits.

Zero means that the time is not known.

+ reg.drone.physics.electricity.Source (v0.1) value [extent 16.0 bytes] [max length 16.0 bytes]

A generic source or sink of electric power (battery, turbogenerator, braking resistor, etc.).
Low-pass filtering should be applied to avoid aliasing effects (as is the case everywhere else).

DC or AC line electric power quantities. Generally, the following current sign convention applies:

  - Positive current flows from the electric power supply network to the load (e.g., an actuator).

  - If the electric network is the load itself powered from a source (e.g., battery), the current is negative.

Total instant load power.
Positive current flows into the source (power sinking).
Negative current flows from the source to the power supply network (power sourcing).

A pessimistic estimate of the amount of energy that can be reclaimed from the source in its current state.
This may be dependent on the state of charge/health (for batteries), temperature, load profile, humidity, etc.
Negative values may be reported to indicate overdischarge or depletion of the reserve energy.

This value approximates (full_energy + int(load_power dt)) plus the environmental influences on the source.

Having the instant power, the time to depletion is estimated as (energy/-power).
When charging (for batteries), the remaining time to full charge can be found similarly as
((full_energy-energy)/power).

For the sake of illustration, if this type was used to represent the state of a braking resistor,
then this value would be negative indicating the amount of dissipated energy.

A pessimistic estimate of the amount of energy that can be reclaimed from a fresh source (fully fueled generator
or a fully charged battery) under the current conditions (SoH, temperature, load profile, etc).

Color in the standard 16-bit 5-6-5 RGB format (green is wider due to non-uniform color sensitivity of the human eye).
https://en.wikipedia.org/wiki/High_color

For reasons of unification, a monochrome light can be modeled using the same type,
where the brightness is defined as the mean of the color components normalized to one:

  brightness = (red/MAX_RED + green/MAX_GREEN + blue/MAX_BLUE) / 3

saturated uint5 red [max length 5 bits]

saturated uint6 green [max length 6 bits]

saturated uint5 blue [max length 5 bits]

saturated uint5 MAX_RED = 31

saturated uint6 MAX_GREEN = 63

saturated uint5 MAX_BLUE = 31

Timestamped fluid pressure and temperature (sampled synchronously) with covariance.
Observe that this is a structural subtype of uavcan.si.sample.pressure.Scalar.1.0.

+ uavcan.time.SynchronizedTimestamp (v1.0) timestamp [extent 7.0 bytes] [max length 7.0 bytes]

Nested data type used for representing a network-wide synchronized timestamp with microsecond resolution.
This data type is highly recommended for use both in standard and vendor-specific messages alike.

The number of microseconds that have passed since some arbitrary moment in the past.
The moment of origin (i.e., the time base) is defined per-application. The current time base in use
can be requested from the time synchronization master, see the corresponding service definition.

This value is to never overflow. The value is 56-bit wide because:

  - 2^56 microseconds is about 2285 years, which is plenty. A 64-bit microsecond counter would be
    unnecessarily wide and its overflow interval of 585 thousand years induces a mild existential crisis.

  - Classic-CAN (not FD) transports carry up to 7 bytes of payload per frame.
    Time sync messages shall use single-frame transfers, which means that the value can't be wider than 56 bits.

Zero means that the time is not known.

+ uavcan.si.unit.pressure.Scalar (v1.0) pressure [extent 4.0 bytes] [max length 4.0 bytes]

+ uavcan.si.unit.temperature.Scalar (v1.0) temperature [extent 4.0 bytes] [max length 4.0 bytes]

+ saturated float16[3] covariance_urt [max length 6.0 bytes]

The upper-right triangle of the covariance matrix (following the matrix packing rules defined in Specification).
  0 -- pascal^2
  1 -- pascal*kelvin
  2 -- kelvin^2

Standard TAI64N time label (https://cr.yp.to/libtai/tai64.html). Quote from the source:

  TAI stands for Temps Atomique International, the current international real-time standard.
  One TAI second is defined as the duration of 9192631770 periods of the radiation corresponding
  to the transition between the two hyperfine levels of the ground state of the cesium atom.
  TAI also specifies a frame of reference. Further discussion of special relativity is outside
  the scope of this document.

  A TAI64 label is an integer between 0 and 2^64 referring to a particular second of real time. Integer s refers to:

      - the TAI second beginning exactly 2^62 - s seconds before the beginning of 1970 TAI,
        if s is between 0 inclusive and 2^62 exclusive; or

      - the TAI second beginning exactly s - 2^62 seconds after the beginning of 1970 TAI,
        if s is between 2^62 inclusive and 2^63 exclusive.

saturated int64 tai64n [max length 8.0 bytes]

[nanosecond] Nanoseconds elapsed since 1970-01-01T00:00:00Z TAI.

+ reg.drone.physics.time.TAI64 (v0.1) value [extent 8.0 bytes] [max length 8.0 bytes]

Standard TAI64N time label (https://cr.yp.to/libtai/tai64.html). Quote from the source:

  TAI stands for Temps Atomique International, the current international real-time standard.
  One TAI second is defined as the duration of 9192631770 periods of the radiation corresponding
  to the transition between the two hyperfine levels of the ground state of the cesium atom.
  TAI also specifies a frame of reference. Further discussion of special relativity is outside
  the scope of this document.

  A TAI64 label is an integer between 0 and 2^64 referring to a particular second of real time. Integer s refers to:

      - the TAI second beginning exactly 2^62 - s seconds before the beginning of 1970 TAI,
        if s is between 0 inclusive and 2^62 exclusive; or

      - the TAI second beginning exactly s - 2^62 seconds after the beginning of 1970 TAI,
        if s is between 2^62 inclusive and 2^63 exclusive.

[nanosecond] Nanoseconds elapsed since 1970-01-01T00:00:00Z TAI.

saturated float32 error_variance [max length 4.0 bytes]

[second^2]
Error variance, in second squared, of the time estimate.
Infinity indicates that the time estimates are not yet available.
A non-positive value indicates that the error variance is unknown.

+ uavcan.time.SynchronizedTimestamp (v1.0) timestamp [extent 7.0 bytes] [max length 7.0 bytes]

Nested data type used for representing a network-wide synchronized timestamp with microsecond resolution.
This data type is highly recommended for use both in standard and vendor-specific messages alike.

The number of microseconds that have passed since some arbitrary moment in the past.
The moment of origin (i.e., the time base) is defined per-application. The current time base in use
can be requested from the time synchronization master, see the corresponding service definition.

This value is to never overflow. The value is 56-bit wide because:

  - 2^56 microseconds is about 2285 years, which is plenty. A 64-bit microsecond counter would be
    unnecessarily wide and its overflow interval of 585 thousand years induces a mild existential crisis.

  - Classic-CAN (not FD) transports carry up to 7 bytes of payload per frame.
    Time sync messages shall use single-frame transfers, which means that the value can't be wider than 56 bits.

Zero means that the time is not known.

+ reg.drone.physics.time.TAI64Var (v0.1) value [extent 12.0 bytes] [max length 12.0 bytes]

Standard TAI64N time label (https://cr.yp.to/libtai/tai64.html). Quote from the source:

  TAI stands for Temps Atomique International, the current international real-time standard.
  One TAI second is defined as the duration of 9192631770 periods of the radiation corresponding
  to the transition between the two hyperfine levels of the ground state of the cesium atom.
  TAI also specifies a frame of reference. Further discussion of special relativity is outside
  the scope of this document.

  A TAI64 label is an integer between 0 and 2^64 referring to a particular second of real time. Integer s refers to:

      - the TAI second beginning exactly 2^62 - s seconds before the beginning of 1970 TAI,
        if s is between 0 inclusive and 2^62 exclusive; or

      - the TAI second beginning exactly s - 2^62 seconds after the beginning of 1970 TAI,
        if s is between 2^62 inclusive and 2^63 exclusive.

[nanosecond] Nanoseconds elapsed since 1970-01-01T00:00:00Z TAI.

[second^2]
Error variance, in second squared, of the time estimate.
Infinity indicates that the time estimates are not yet available.
A non-positive value indicates that the error variance is unknown.

Generic error codes reported by the service provider.
An error is reported when the corresponding parameter exceeds its safe operating area (SOA) as defined by the vendor;
see https://en.wikipedia.org/wiki/Safe_operating_area.
As long as an error condition is present, the service health should not be NOMINAL.

If there are multiple error conditions present, the most severe one should be reported. The severity ordering
is implementation-defined. Barring special requirements, it is recommended to give preference to errors whose
code is smaller (e.g., BAD_BATTERY trumps TEMPERATURE_COLD).

saturated uint8 value [max length 1.0 bytes]

saturated uint8 NONE = 0

Normal operation.

saturated uint8 BAD_BATTERY = 10

The battery should not be used anymore. Detection criteria are implementation-defined.

saturated uint8 NEEDS_SERVICE = 11

The battery requires offline maintenance.

saturated uint8 BMS_ERROR = 20

An internal error in the battery management system, not related to the battery itself.

saturated uint8 CONFIGURATION = 30

The battery/BMS/node/service configuration is missing or invalid.

saturated uint8 OVERDISCHARGE = 50

The battery is discharged beyond the design limits and may have incurred damage.

saturated uint8 OVERLOAD = 51

The charge or discharge rate exceeds the safe operating limits.

saturated uint8 CELL_OVERVOLTAGE = 60

saturated uint8 CELL_UNDERVOLTAGE = 61

Voltage of one of the battery cells exceeds its SOA.

saturated uint8 CELL_COUNT = 62

The sum of cell voltages is far from the total pack voltage.
The threshold is implementation-defined.

saturated uint8 TEMPERATURE_HOT = 100

saturated uint8 TEMPERATURE_COLD = 101

At least one cell is above/below the temperature SOA.

Smart battery parameter message. It is mostly intended for automated battery charging and maintenance systems.
This message is modeled after the Smart Battery Data Specification (SBS) and the MAVLink battery status messages.

The values carried by this message are either constant or slow-changing, so, generally, the publishing frequency
should not be higher than 0.2 Hz, and the priority should be either OPTIONAL or SLOW.

All parameters are required unless specifically stated otherwise.
For non-rechargeable batteries all "charge_*" parameters should be NaN.

truncated uint64 unique_id [max length 8.0 bytes]

A statistically unique number that can be used to identify this exact battery for logging and diagnostic purposes.
This value should be invariant to the identity of the reporting node unless it is an integral part of the battery.
If the battery supports SBS, the recommended way to populate this field is from two CRC-32C (Castagnoli) values as:
  - 32 most significant bits identify the vendor as:   CRC32C(ManufacturerName)
  - 32 least significant bits identify the battery as: CRC32C(DeviceName + ManufactureDate + SerialNumber)
If the battery does not support SBS, the vendor may choose arbitrary random numbers.
Note that these are mere recommendations. The only hard requirement for this field is to be statistically unique.

+ uavcan.si.unit.mass.Scalar (v1.0) mass [extent 4.0 bytes] [max length 4.0 bytes]

The total mass of the battery, including the packaging, electronics, cabling, and all auxiliary items, if any.
May be used for predicting the kinematic parameters of the vehicle.
NaN if unknown.

+ uavcan.si.unit.electric_charge.Scalar (v1.0) design_capacity [extent 4.0 bytes] [max length 4.0 bytes]

The maximum total charge of the pack, at 100% SoH, specified by the manufacturer.

+ uavcan.si.unit.voltage.Scalar.1.0[2] design_cell_voltage_min_max [max length 8.0 bytes]

The minimum (end of discharge) and the maximum (end of charge) resting cell voltage specified by the manufacturer
at 100% SoH. Example: {2.8, 4.2} V. These voltages correspond to resting voltages; i.e., the stabilized voltages after
the discharge/charge has been terminated. Voltage below the min may be observed during discharge due to the cell's
internal resistance. Voltage above the max voltage may be observed during regenerative braking/charging etc due to
the cell's internal resistance.

+ uavcan.si.unit.electric_current.Scalar (v1.0) discharge_current [extent 4.0 bytes] [max length 4.0 bytes]

Recommended continuous discharge current of the battery.

+ uavcan.si.unit.electric_current.Scalar (v1.0) discharge_current_burst [extent 4.0 bytes] [max length 4.0 bytes]

Maximum current that may be safely discharged at least for 5 seconds.

+ uavcan.si.unit.electric_current.Scalar (v1.0) charge_current [extent 4.0 bytes] [max length 4.0 bytes]

Recommended continuous charge current of the battery.

+ uavcan.si.unit.electric_current.Scalar (v1.0) charge_current_fast [extent 4.0 bytes] [max length 4.0 bytes]

Recommended safest highest continuous charge current for the battery.
This may cause accelerated aging of the battery.

+ uavcan.si.unit.electric_current.Scalar (v1.0) charge_termination_threshold [extent 4.0 bytes] [max length 4.0 bytes]

End-of-charging current threshold. Charging may be terminated when the current falls below this threshold.

+ uavcan.si.unit.voltage.Scalar (v1.0) charge_voltage [extent 4.0 bytes] [max length 4.0 bytes]

The total voltage(not per-cell) that may be used by the charger to charge the battery pack.

saturated uint16 cycle_count [max length 2.0 bytes]

The number of charge-discharge cycles. Zero if the battery is new. May increase at runtime.
What constitutes a charge-discharge cycle is implementation-defined.

void16 [max length 2.0 bytes]

Was used in v0.1 for cell_count. It is now deducible from cell_voltages in Status.0.2.

saturated uint7 state_of_health_pct [max length 7 bits]

[percent]
The SoH of the battery, or best guess thereof; ranges from 0 (unusable) to 100 (new).

void1 [max length 1 bits]

+ reg.drone.service.battery.Technology (v0.1) technology [extent 1.0 bytes] [max length 1.0 bytes]

Battery chemistry type and its form-factor.
Observe that there is no item to represent unknown technology because it is required to be known.
This information may be used by charging systems to select the appropriate charging strategy.
If the battery is of an uncommon type, it may be preferred to report the closest-matching type listed here
instead of OTHER.

The technology is not specified in this enumeration. Please submit a pull request.

Lithium-thionyl chloride (Li-SOCl2)

Lithium-thionyl chloride + bromine chloride (Li-BCX)

Lithium-manganese dioxide (Li-MnO2) (e.g., lithium coin cell, lithium 9V)

Zinc-Air

Aluminum-Air

Zinc-manganese dioxide - ammonium chloride electrolyte (aka zinc-carbon)

Zinc-manganese dioxide - zinc chloride electrolyte (aka heavy duty zinc-carbon)

Zinc-manganese dioxide - potassium hydroxide electrolyte (aka alkaline)

Lithium cobalt oxide (commonly known as just "lithium-ion")

Lithium iron phosphate (LiFePO4)

Lithium nickel manganese cobalt oxide

Lithium nickel cobalt aluminium oxide

Lithium manganese oxide

Lithium-sulfur (LiS)

LiCoO2 in pouch form factor, commonly known as "lithium-ion polymer" or "LiPo".

LiFePO4 in pouch form factor, commonly known as "LiFePO4 polymer".

Nickel-metal hydride

Nickel-cadmium

Nickel-zinc

Nickel-iron

Lead acid

Also known as SLA

Electrostatic double-layer capacitor

The battery technology information may be leveraged by the charger to choose the appropriate charging strategy.

+ uavcan.si.unit.voltage.Scalar (v1.0) nominal_voltage [extent 4.0 bytes] [max length 4.0 bytes]

The nominal voltage of the battery pack (not per-cell) as defined by the vendor.
E.g., a typical 22S LiCoO2 pack would usually report 81.4 V here.

Smart battery parameter message. It is mostly intended for automated battery charging and maintenance systems.
This message is modeled after the Smart Battery Data Specification (SBS) and the MAVLink battery status messages.

The values carried by this message are either constant or slow-changing, so, generally, the publishing frequency
should not be higher than 0.2 Hz, and the priority should be either OPTIONAL or SLOW.

All parameters are required unless specifically stated otherwise.
For non-rechargeable batteries all "charge_*" parameters should be NaN.

truncated uint64 unique_id [max length 8.0 bytes]

A statistically unique number that can be used to identify this exact battery for logging and diagnostic purposes.
This value should be invariant to the identity of the reporting node unless it is an integral part of the battery.
If the battery supports SBS, the recommended way to populate this field is from two CRC-32C (Castagnoli) values as:
  - 32 most significant bits identify the vendor as:   CRC32C(ManufacturerName)
  - 32 least significant bits identify the battery as: CRC32C(DeviceName + ManufactureDate + SerialNumber)
If the battery does not support SBS, the vendor may choose arbitrary random numbers.
Note that these are mere recommendations. The only hard requirement for this field is to be statistically unique.

+ uavcan.si.unit.mass.Scalar (v1.0) mass [extent 4.0 bytes] [max length 4.0 bytes]

The total mass of the battery, including the packaging, electronics, cabling, and all auxiliary items, if any.
May be used for predicting the kinematic parameters of the vehicle.
NaN if unknown.

+ uavcan.si.unit.electric_charge.Scalar (v1.0) design_capacity [extent 4.0 bytes] [max length 4.0 bytes]

The maximum total charge of the pack, at 100% SoH, specified by the manufacturer.

+ uavcan.si.unit.voltage.Scalar.1.0[2] design_cell_voltage_min_max [max length 8.0 bytes]

The minimum (end of discharge) and the maximum (end of charge) resting cell voltage specified by the manufacturer
at 100% SoH. Example: {2.8, 4.2} V. These voltages correspond to resting voltages; i.e., the stabilized voltages after
the discharge/charge has been terminated. Voltage below the min may be observed during discharge due to the cell's
internal resistance. Voltage above the max voltage may be observed during regenerative braking/charging etc due to
the cell's internal resistance.

+ uavcan.si.unit.electric_current.Scalar (v1.0) discharge_current [extent 4.0 bytes] [max length 4.0 bytes]

Recommended continuous discharge current of the battery.

+ uavcan.si.unit.electric_current.Scalar (v1.0) discharge_current_burst [extent 4.0 bytes] [max length 4.0 bytes]

Maximum current that may be safely discharged at least for 5 seconds.

+ uavcan.si.unit.electric_current.Scalar (v1.0) charge_current [extent 4.0 bytes] [max length 4.0 bytes]

Recommended continuous charge current of the battery.

+ uavcan.si.unit.electric_current.Scalar (v1.0) charge_current_fast [extent 4.0 bytes] [max length 4.0 bytes]

Recommended safest highest continuous charge current for the battery.
This may cause accelerated aging of the battery.

+ uavcan.si.unit.electric_current.Scalar (v1.0) charge_termination_threshold [extent 4.0 bytes] [max length 4.0 bytes]

End-of-charging current threshold. Charging may be terminated when the current falls below this threshold.

+ uavcan.si.unit.voltage.Scalar (v1.0) charge_voltage [extent 4.0 bytes] [max length 4.0 bytes]

The total voltage(not per-cell) that may be used by the charger to charge the battery pack.

saturated uint16 cycle_count [max length 2.0 bytes]

The number of charge-discharge cycles. Zero if the battery is new. May increase at runtime.
What constitutes a charge-discharge cycle is implementation-defined.

void16 [max length 2.0 bytes]

Was used in v0.1 for cell_count. It is now deducible from cell_voltages in Status.0.2.

saturated uint7 state_of_health_pct [max length 7 bits]

[percent]
The SoH of the battery, or best guess thereof; ranges from 0 (unusable) to 100 (new).

void1 [max length 1 bits]

+ reg.drone.service.battery.Technology (v0.1) technology [extent 1.0 bytes] [max length 1.0 bytes]

Battery chemistry type and its form-factor.
Observe that there is no item to represent unknown technology because it is required to be known.
This information may be used by charging systems to select the appropriate charging strategy.
If the battery is of an uncommon type, it may be preferred to report the closest-matching type listed here
instead of OTHER.

The technology is not specified in this enumeration. Please submit a pull request.

Lithium-thionyl chloride (Li-SOCl2)

Lithium-thionyl chloride + bromine chloride (Li-BCX)

Lithium-manganese dioxide (Li-MnO2) (e.g., lithium coin cell, lithium 9V)

Zinc-Air

Aluminum-Air

Zinc-manganese dioxide - ammonium chloride electrolyte (aka zinc-carbon)

Zinc-manganese dioxide - zinc chloride electrolyte (aka heavy duty zinc-carbon)

Zinc-manganese dioxide - potassium hydroxide electrolyte (aka alkaline)

Lithium cobalt oxide (commonly known as just "lithium-ion")

Lithium iron phosphate (LiFePO4)

Lithium nickel manganese cobalt oxide

Lithium nickel cobalt aluminium oxide

Lithium manganese oxide

Lithium-sulfur (LiS)

LiCoO2 in pouch form factor, commonly known as "lithium-ion polymer" or "LiPo".

LiFePO4 in pouch form factor, commonly known as "LiFePO4 polymer".

Nickel-metal hydride

Nickel-cadmium

Nickel-zinc

Nickel-iron

Lead acid

Also known as SLA

Electrostatic double-layer capacitor

The battery technology information may be leveraged by the charger to choose the appropriate charging strategy.

Smart battery parameter message. It is mostly intended for automated battery charging and maintenance systems.
This message is modeled after the Smart Battery Data Specification (SBS) and the MAVLink battery status messages.

The values carried by this message are either constant or slow-changing, so, generally, the publishing frequency
should not be higher than 0.2 Hz, and the priority should be either OPTIONAL or SLOW.

All parameters are required unless specifically stated otherwise.

truncated uint64 unique_id [max length 8.0 bytes]

A statistically unique number that can be used to differentiate this exact battery from others.
Needed for logging purposes. If the battery supports SBS, this value may be computed as CRC64WE of
(ManufacturerName + DeviceName + ManufactureDate + SerialNumber).
This value shall be invariant to the identity of the reporting node unless it is an integral part of the battery.
Vendors may use a constant random number for the 40 most significant bits for vendor identification purposes.

+ uavcan.si.unit.mass.Scalar (v1.0) mass [extent 4.0 bytes] [max length 4.0 bytes]

The total mass of the battery, including the packaging, electronics, cabling, and all auxiliary items, if any.
May be used for predicting the kinematic parameters of the vehicle.
NaN if unknown.

+ uavcan.si.unit.electric_charge.Scalar (v1.0) design_capacity [extent 4.0 bytes] [max length 4.0 bytes]

The maximum total charge of the pack, at 100% SoH, specified by the manufacturer.

+ uavcan.si.unit.voltage.Scalar.1.0[2] design_cell_voltage_min_max [max length 8.0 bytes]

The minimum (end of discharge) and the maximum (end of charge) cell voltages specified by the manufacturer
at 100% SoH. Example: {2.8, 4.2} V

+ uavcan.si.unit.electric_current.Scalar (v1.0) discharge_current [extent 4.0 bytes] [max length 4.0 bytes]

+ uavcan.si.unit.electric_current.Scalar (v1.0) discharge_current_burst [extent 4.0 bytes] [max length 4.0 bytes]

At least for 5 seconds.

+ uavcan.si.unit.electric_current.Scalar (v1.0) charge_current [extent 4.0 bytes] [max length 4.0 bytes]

+ uavcan.si.unit.electric_current.Scalar (v1.0) charge_current_fast [extent 4.0 bytes] [max length 4.0 bytes]

+ uavcan.si.unit.electric_current.Scalar (v1.0) charge_termination_treshold [extent 4.0 bytes] [max length 4.0 bytes]

End-of-charging current threshold.

+ uavcan.si.unit.voltage.Scalar (v1.0) charge_voltage [extent 4.0 bytes] [max length 4.0 bytes]

Total charging voltage (not per-cell).
The key (dis-)charge parameters specified by the manufacturer for the pack.
This is a reflection of similar parameters from the Smart Battery Data Specification.
For non-rechargeable batteries all "charge_*" parameters should be NaN.

saturated uint16 cycle_count [max length 2.0 bytes]

The number of charge-discharge cycles. Zero if the battery is new. May increase at runtime.
What constitutes a charge-discharge cycle is implementation-defined.

void8 [max length 1.0 bytes]

Reserved for possible expansion because batteries with >255 cells exist.

saturated uint8 series_cell_count [max length 1.0 bytes]

The number of cells connected in series.

saturated uint7 state_of_health_pct [max length 7 bits]

[percent]
The SoH of the battery, or best guess thereof; ranges from 0 (unusable) to 100 (new).

void1 [max length 1 bits]

+ reg.drone.service.battery.Technology (v0.1) technology [extent 1.0 bytes] [max length 1.0 bytes]

Battery chemistry type and its form-factor.
Observe that there is no item to represent unknown technology because it is required to be known.
This information may be used by charging systems to select the appropriate charging strategy.
If the battery is of an uncommon type, it may be preferred to report the closest-matching type listed here
instead of OTHER.

The technology is not specified in this enumeration. Please submit a pull request.

Lithium-thionyl chloride (Li-SOCl2)

Lithium-thionyl chloride + bromine chloride (Li-BCX)

Lithium-manganese dioxide (Li-MnO2) (e.g., lithium coin cell, lithium 9V)

Zinc-Air

Aluminum-Air

Zinc-manganese dioxide - ammonium chloride electrolyte (aka zinc-carbon)

Zinc-manganese dioxide - zinc chloride electrolyte (aka heavy duty zinc-carbon)

Zinc-manganese dioxide - potassium hydroxide electrolyte (aka alkaline)

Lithium cobalt oxide (commonly known as just "lithium-ion")

Lithium iron phosphate (LiFePO4)

Lithium nickel manganese cobalt oxide

Lithium nickel cobalt aluminium oxide

Lithium manganese oxide

Lithium-sulfur (LiS)

LiCoO2 in pouch form factor, commonly known as "lithium-ion polymer" or "LiPo".

LiFePO4 in pouch form factor, commonly known as "LiFePO4 polymer".

Nickel-metal hydride

Nickel-cadmium

Nickel-zinc

Nickel-iron

Lead acid

Also known as SLA

Electrostatic double-layer capacitor

The battery technology information may be leveraged by the charger to choose the appropriate charging strategy.

This low-rate battery status should be published at least once per second.

+ reg.drone.service.common.Heartbeat (v0.1) heartbeat [extent 2.0 bytes] [max length 2.0 bytes]

The function of the service heartbeat is similar to that of the node heartbeat defined in the standard namespace,
except that it is used on a per-service basis, meaning that there may be more than one publisher per node.

The service heartbeat should be published either on a separate subject, or as a structural supertype of a
service-specific status subject. The publication rate is service-specific but it should not be lower than 1 Hz.

This is a structural subtype of the Readiness type.

The readiness state is used to command or report the availability status of a networked service (subsystem).

Any system shall have at least one readiness command subject that acts as a global power switch.
Every subsystem controlled in such way would usually report its readiness status back to account for the fact that
the transition between different readiness states may not be instantaneous.
The readiness status reporting is done by means of the service heartbeat type that is also defined in this namespace;
the service heartbeat type is a structural subtype of this type.

  +------------+
  | Controller |----------+----------------+----------------+---------...     readiness command subject
  +------------+          |                |                |
    ^   ^   ^             v                v                v
    |   |   |        +---------+      +---------+      +---------+
    |   |   |        | Service |      | Service |      | Service |    ...
    |   |   |        +---------+      +---------+      +---------+
    |   |   |             |                |                |
    |   |   +-------------+                |                |
    |   +----------------------------------+                |                 service heartbeat subjects
    +-------------------------------------------------------+

In a less trivial use case there may be an arbitrary number of such readiness command subjects (local power switches)
controlling various systems within the vehicle (e.g., propulsion, perception sensors, communication, etc).

The publication rate is defined on a per-service basis, but it should never be lower than 1 Hz,
excepting services that are in the SLEEP state, in which case it is permitted to cease all network activity.

The long-term state of minimal power consumption.
Typically, most subsystems are switched into the SLEEP mode when the vehicle is parked and powered off.
Subsystems that do not support the SLEEP state should treat it as an equivalent of STANDBY.

A subsystem may require a substantial amount of time to exit the sleep mode (for example, time may be needed to
boot the operating system and run the self test procedures).

While in the SLEEP mode, the subsystem is allowed to cease service provision and stop all network activity
regardless of other requirements, except that it shall be able to reactivate itself if a Readiness message is
received commanding any state other than SLEEP.

The state of being ready to enter the normal operating mode in a short order.
A subsystem that is in STANDBY state should be able to participate in the normal network activity.
This is the default state that the subsystem should reside in after power-on until explicitly commanded otherwise.

When ENGAGED, the subsystem is performing its main intended function at the nominal performance characteristics.
A subsystem may require a short amount of time, possibly under a few seconds, to switch between the ENGAGED and
STANDBY states (in any direction).
Some subsystems may not differentiate between STANDBY and ENGAGED (e.g., offboard communication hardware).
The subsystem may disengage itself autonomously in the event of a fatal malfunction, in which case
the reported service health status should be WARNING.

Abstract component health information. If the node performs multiple activities (provides multiple network services),
its health status should reflect the status of the worst-performing activity (network service).
Follows:
  https://www.law.cornell.edu/cfr/text/14/23.1322
  https://www.faa.gov/documentLibrary/media/Advisory_Circular/AC_25.1322-1.pdf section 6

The component is functioning properly (nominal).

A critical parameter went out of range or the component encountered a minor failure that does not prevent
the subsystem from performing any of its real-time functions.

The component encountered a major failure and is performing in a degraded mode or outside of its designed limitations.

The component suffered a fatal malfunction and is unable to perform its intended function.

Any service that is not in the SLEEP state should publish its heartbeat (or a derived status) at least at this rate.

Note that the health code generally should not reflect the battery charge unless the service provider knows
that the availability of energy in the battery is critical for the safe operation of the vehicle, which is usually
not the case. For example, if the vehicle is equipped with several batteries that are discharged in series, one
after another, the depletion of energy in the first battery is not a fault condition and it should not be reported
as such. This follows from the good service design principles reviewed in https://uavcan.org/guide.

The readiness state depicts the ability of the battery (or its power electronics) to deliver full rated power
and whether the overdischarge protections are active.
When the battery is not ENGAGED, it may limit the output power below the nominal rated value and disconnect the load
should the charge level fall below the critical level.
When the battery is ENGAGED, it is not permitted to limit the output power or energy regardless of the risk of damage.
If the adaptive protection is not supported, the battery should always report its status as ENGAGED.

+ uavcan.si.unit.temperature.Scalar.1.0[2] temperature_min_max [max length 8.0 bytes]

The minimum and maximum readings of the pack temperature sensors.
For example, if the pack is equipped with three distributed temperature sensors that read {288, 258.15, 360.5} K,
the reported array value would be {258.15, 360.5} K.
If there is only one temperature sensor, both elements shall be of the same value.

void64 [max length 8.0 bytes]

Was cell_voltage_min_max in v0.1. Deprecated in favor of cell_voltages array.

+ uavcan.si.unit.electric_charge.Scalar (v1.0) available_charge [extent 4.0 bytes] [max length 4.0 bytes]

The estimated electric charge currently stored in the battery. This is intended for charging and maintenance only.
Do not use this parameter for endurance prediction! Instead, use the correct energy type from the physics namespace.
The depth of discharge (DoD), or the state of charge (SoC), can be derived by dividing this value by the
nominal battery capacity reported in the Parameters message.

+ reg.drone.service.battery.Error (v0.1) error [extent 1.0 bytes] [max length 1.0 bytes]

Generic error codes reported by the service provider.
An error is reported when the corresponding parameter exceeds its safe operating area (SOA) as defined by the vendor;
see https://en.wikipedia.org/wiki/Safe_operating_area.
As long as an error condition is present, the service health should not be NOMINAL.

If there are multiple error conditions present, the most severe one should be reported. The severity ordering
is implementation-defined. Barring special requirements, it is recommended to give preference to errors whose
code is smaller (e.g., BAD_BATTERY trumps TEMPERATURE_COLD).

Normal operation.

The battery should not be used anymore. Detection criteria are implementation-defined.

The battery requires offline maintenance.

An internal error in the battery management system, not related to the battery itself.

The battery/BMS/node/service configuration is missing or invalid.

The battery is discharged beyond the design limits and may have incurred damage.

The charge or discharge rate exceeds the safe operating limits.

Voltage of one of the battery cells exceeds its SOA.

The sum of cell voltages is far from the total pack voltage.
The threshold is implementation-defined.

At least one cell is above/below the temperature SOA.

+ saturated float16[<=255] cell_voltages [max length 511.0 bytes]

[volt]
The voltages of individual cells in the battery pack.

saturated uint8 MAX_CELLS = 255

This low-rate battery status should be published at least once per second.

+ reg.drone.service.common.Heartbeat (v0.1) heartbeat [extent 2.0 bytes] [max length 2.0 bytes]

The function of the service heartbeat is similar to that of the node heartbeat defined in the standard namespace,
except that it is used on a per-service basis, meaning that there may be more than one publisher per node.

The service heartbeat should be published either on a separate subject, or as a structural supertype of a
service-specific status subject. The publication rate is service-specific but it should not be lower than 1 Hz.

This is a structural subtype of the Readiness type.

The readiness state is used to command or report the availability status of a networked service (subsystem).

Any system shall have at least one readiness command subject that acts as a global power switch.
Every subsystem controlled in such way would usually report its readiness status back to account for the fact that
the transition between different readiness states may not be instantaneous.
The readiness status reporting is done by means of the service heartbeat type that is also defined in this namespace;
the service heartbeat type is a structural subtype of this type.

  +------------+
  | Controller |----------+----------------+----------------+---------...     readiness command subject
  +------------+          |                |                |
    ^   ^   ^             v                v                v
    |   |   |        +---------+      +---------+      +---------+
    |   |   |        | Service |      | Service |      | Service |    ...
    |   |   |        +---------+      +---------+      +---------+
    |   |   |             |                |                |
    |   |   +-------------+                |                |
    |   +----------------------------------+                |                 service heartbeat subjects
    +-------------------------------------------------------+

In a less trivial use case there may be an arbitrary number of such readiness command subjects (local power switches)
controlling various systems within the vehicle (e.g., propulsion, perception sensors, communication, etc).

The publication rate is defined on a per-service basis, but it should never be lower than 1 Hz,
excepting services that are in the SLEEP state, in which case it is permitted to cease all network activity.

The long-term state of minimal power consumption.
Typically, most subsystems are switched into the SLEEP mode when the vehicle is parked and powered off.
Subsystems that do not support the SLEEP state should treat it as an equivalent of STANDBY.

A subsystem may require a substantial amount of time to exit the sleep mode (for example, time may be needed to
boot the operating system and run the self test procedures).

While in the SLEEP mode, the subsystem is allowed to cease service provision and stop all network activity
regardless of other requirements, except that it shall be able to reactivate itself if a Readiness message is
received commanding any state other than SLEEP.

The state of being ready to enter the normal operating mode in a short order.
A subsystem that is in STANDBY state should be able to participate in the normal network activity.
This is the default state that the subsystem should reside in after power-on until explicitly commanded otherwise.

When ENGAGED, the subsystem is performing its main intended function at the nominal performance characteristics.
A subsystem may require a short amount of time, possibly under a few seconds, to switch between the ENGAGED and
STANDBY states (in any direction).
Some subsystems may not differentiate between STANDBY and ENGAGED (e.g., offboard communication hardware).
The subsystem may disengage itself autonomously in the event of a fatal malfunction, in which case
the reported service health status should be WARNING.

Abstract component health information. If the node performs multiple activities (provides multiple network services),
its health status should reflect the status of the worst-performing activity (network service).
Follows:
  https://www.law.cornell.edu/cfr/text/14/23.1322
  https://www.faa.gov/documentLibrary/media/Advisory_Circular/AC_25.1322-1.pdf section 6

The component is functioning properly (nominal).

A critical parameter went out of range or the component encountered a minor failure that does not prevent
the subsystem from performing any of its real-time functions.

The component encountered a major failure and is performing in a degraded mode or outside of its designed limitations.

The component suffered a fatal malfunction and is unable to perform its intended function.

Any service that is not in the SLEEP state should publish its heartbeat (or a derived status) at least at this rate.

Note that the health code generally should not reflect the battery charge unless the service provider knows
that the availability of energy in the battery is critical for the safe operation of the vehicle, which is usually
not the case. For example, if the vehicle is equipped with several batteries that are discharged in series, one
after another, the depletion of energy in the first battery is not a fault condition and it should not be reported
as such. This follows from the good service design principles reviewed in https://uavcan.org/guide.

The readiness state depicts the ability of the battery (or its power electronics) to deliver full rated power
and whether the overdischarge protections are active.
When the battery is not ENGAGED, it may limit the output power below the nominal rated value and disconnect the load
should the charge level fall below the critical level.
When the battery is ENGAGED, it is not permitted to limit the output power or energy regardless of the risk of damage.
If the adaptive protection is not supported, the battery should always report its status as ENGAGED.

+ uavcan.si.unit.temperature.Scalar.1.0[2] temperature_min_max [max length 8.0 bytes]

The minimum and maximum readings of the pack temperature sensors.
For example, if the pack is equipped with three distributed temperature sensors that read {288, 258.15, 360.5} K,
the reported array value would be {258.15, 360.5} K.
If there is only one temperature sensor, both elements shall be of the same value.

+ uavcan.si.unit.voltage.Scalar.1.0[2] cell_voltage_min_max [max length 8.0 bytes]

If v(i) is the voltage of cell number i (or a group of cells connected in parallel), and there are N cells,
then the first array element is: min(v(x) for x in [0, N))
and the second array element is: max(v(x) for x in [0, N))
This information is used for gauging the degree of cell disbalance.
Note that the average cell voltage can be obtained by dividing the battery voltage by the number of cells.

+ uavcan.si.unit.electric_charge.Scalar (v1.0) available_charge [extent 4.0 bytes] [max length 4.0 bytes]

The estimated electric charge currently stored in the battery. This is intended for charging and maintenance only.
Do not use this parameter for endurance prediction! Instead, use the correct energy type from the physics namespace.
The depth of discharge (DoD), or the state of charge (SoC), can be derived by dividing this value by the
nominal battery capacity reported in the Parameters message.

+ reg.drone.service.battery.Error (v0.1) error [extent 1.0 bytes] [max length 1.0 bytes]

Generic error codes reported by the service provider.
An error is reported when the corresponding parameter exceeds its safe operating area (SOA) as defined by the vendor;
see https://en.wikipedia.org/wiki/Safe_operating_area.
As long as an error condition is present, the service health should not be NOMINAL.

If there are multiple error conditions present, the most severe one should be reported. The severity ordering
is implementation-defined. Barring special requirements, it is recommended to give preference to errors whose
code is smaller (e.g., BAD_BATTERY trumps TEMPERATURE_COLD).

Normal operation.

The battery should not be used anymore. Detection criteria are implementation-defined.

The battery requires offline maintenance.

An internal error in the battery management system, not related to the battery itself.

The battery/BMS/node/service configuration is missing or invalid.

The battery is discharged beyond the design limits and may have incurred damage.

The charge or discharge rate exceeds the safe operating limits.

Voltage of one of the battery cells exceeds its SOA.

The sum of cell voltages is far from the total pack voltage.
The threshold is implementation-defined.

At least one cell is above/below the temperature SOA.

Battery chemistry type and its form-factor.
Observe that there is no item to represent unknown technology because it is required to be known.
This information may be used by charging systems to select the appropriate charging strategy.
If the battery is of an uncommon type, it may be preferred to report the closest-matching type listed here
instead of OTHER.

saturated uint8 value [max length 1.0 bytes]

saturated uint8 OTHER = 0

The technology is not specified in this enumeration. Please submit a pull request.

saturated uint8 LI_SOCL2 = 10

Lithium-thionyl chloride (Li-SOCl2)

saturated uint8 LI_BCX = 11

Lithium-thionyl chloride + bromine chloride (Li-BCX)

saturated uint8 LI_MNO2 = 12

Lithium-manganese dioxide (Li-MnO2) (e.g., lithium coin cell, lithium 9V)

saturated uint8 ZN_O2 = 20

Zinc-Air

saturated uint8 AL_O2 = 21

Aluminum-Air

saturated uint8 ZN_MNO2_NH4CL = 30

Zinc-manganese dioxide - ammonium chloride electrolyte (aka zinc-carbon)

saturated uint8 ZN_MNO2_ZNCL2 = 31

Zinc-manganese dioxide - zinc chloride electrolyte (aka heavy duty zinc-carbon)

saturated uint8 ZN_MNO2_KOH = 32

Zinc-manganese dioxide - potassium hydroxide electrolyte (aka alkaline)

saturated uint8 LI_LCO = 100

Lithium cobalt oxide (commonly known as just "lithium-ion")

saturated uint8 LI_LFP = 101

Lithium iron phosphate (LiFePO4)

saturated uint8 LI_NMC = 102

Lithium nickel manganese cobalt oxide

saturated uint8 LI_NCA = 103

Lithium nickel cobalt aluminium oxide

saturated uint8 LI_LMO = 104

Lithium manganese oxide

saturated uint8 LI_S = 105

Lithium-sulfur (LiS)

saturated uint8 LI_LCO_POUCH = 110

LiCoO2 in pouch form factor, commonly known as "lithium-ion polymer" or "LiPo".

saturated uint8 LI_LFP_POUCH = 111

LiFePO4 in pouch form factor, commonly known as "LiFePO4 polymer".

saturated uint8 NI_MH = 120

Nickel-metal hydride

saturated uint8 NI_CD = 121

Nickel-cadmium

saturated uint8 NI_ZN = 122

Nickel-zinc

saturated uint8 NI_FE = 123

Nickel-iron

saturated uint8 PB_AC = 130

Lead acid

saturated uint8 PB_AC_SEALED = 131

Also known as SLA

saturated uint8 EDLC = 200

Electrostatic double-layer capacitor

The function of the service heartbeat is similar to that of the node heartbeat defined in the standard namespace,
except that it is used on a per-service basis, meaning that there may be more than one publisher per node.

The service heartbeat should be published either on a separate subject, or as a structural supertype of a
service-specific status subject. The publication rate is service-specific but it should not be lower than 1 Hz.

This is a structural subtype of the Readiness type.

+ reg.drone.service.common.Readiness (v0.1) readiness [extent 1.0 bytes] [max length 1.0 bytes]

The readiness state is used to command or report the availability status of a networked service (subsystem).

Any system shall have at least one readiness command subject that acts as a global power switch.
Every subsystem controlled in such way would usually report its readiness status back to account for the fact that
the transition between different readiness states may not be instantaneous.
The readiness status reporting is done by means of the service heartbeat type that is also defined in this namespace;
the service heartbeat type is a structural subtype of this type.

  +------------+
  | Controller |----------+----------------+----------------+---------...     readiness command subject
  +------------+          |                |                |
    ^   ^   ^             v                v                v
    |   |   |        +---------+      +---------+      +---------+
    |   |   |        | Service |      | Service |      | Service |    ...
    |   |   |        +---------+      +---------+      +---------+
    |   |   |             |                |                |
    |   |   +-------------+                |                |
    |   +----------------------------------+                |                 service heartbeat subjects
    +-------------------------------------------------------+

In a less trivial use case there may be an arbitrary number of such readiness command subjects (local power switches)
controlling various systems within the vehicle (e.g., propulsion, perception sensors, communication, etc).

The publication rate is defined on a per-service basis, but it should never be lower than 1 Hz,
excepting services that are in the SLEEP state, in which case it is permitted to cease all network activity.

The long-term state of minimal power consumption.
Typically, most subsystems are switched into the SLEEP mode when the vehicle is parked and powered off.
Subsystems that do not support the SLEEP state should treat it as an equivalent of STANDBY.

A subsystem may require a substantial amount of time to exit the sleep mode (for example, time may be needed to
boot the operating system and run the self test procedures).

While in the SLEEP mode, the subsystem is allowed to cease service provision and stop all network activity
regardless of other requirements, except that it shall be able to reactivate itself if a Readiness message is
received commanding any state other than SLEEP.

The state of being ready to enter the normal operating mode in a short order.
A subsystem that is in STANDBY state should be able to participate in the normal network activity.
This is the default state that the subsystem should reside in after power-on until explicitly commanded otherwise.

When ENGAGED, the subsystem is performing its main intended function at the nominal performance characteristics.
A subsystem may require a short amount of time, possibly under a few seconds, to switch between the ENGAGED and
STANDBY states (in any direction).
Some subsystems may not differentiate between STANDBY and ENGAGED (e.g., offboard communication hardware).
The subsystem may disengage itself autonomously in the event of a fatal malfunction, in which case
the reported service health status should be WARNING.

+ uavcan.node.Health (v1.0) health [extent 1.0 bytes] [max length 1.0 bytes]

Abstract component health information. If the node performs multiple activities (provides multiple network services),
its health status should reflect the status of the worst-performing activity (network service).
Follows:
  https://www.law.cornell.edu/cfr/text/14/23.1322
  https://www.faa.gov/documentLibrary/media/Advisory_Circular/AC_25.1322-1.pdf section 6

The component is functioning properly (nominal).

A critical parameter went out of range or the component encountered a minor failure that does not prevent
the subsystem from performing any of its real-time functions.

The component encountered a major failure and is performing in a degraded mode or outside of its designed limitations.

The component suffered a fatal malfunction and is unable to perform its intended function.

saturated uint8 MAX_PUBLICATION_PERIOD = 1

Any service that is not in the SLEEP state should publish its heartbeat (or a derived status) at least at this rate.

The readiness state is used to command or report the availability status of a networked service (subsystem).

Any system shall have at least one readiness command subject that acts as a global power switch.
Every subsystem controlled in such way would usually report its readiness status back to account for the fact that
the transition between different readiness states may not be instantaneous.
The readiness status reporting is done by means of the service heartbeat type that is also defined in this namespace;
the service heartbeat type is a structural subtype of this type.

  +------------+
  | Controller |----------+----------------+----------------+---------...     readiness command subject
  +------------+          |                |                |
    ^   ^   ^             v                v                v
    |   |   |        +---------+      +---------+      +---------+
    |   |   |        | Service |      | Service |      | Service |    ...
    |   |   |        +---------+      +---------+      +---------+
    |   |   |             |                |                |
    |   |   +-------------+                |                |
    |   +----------------------------------+                |                 service heartbeat subjects
    +-------------------------------------------------------+

In a less trivial use case there may be an arbitrary number of such readiness command subjects (local power switches)
controlling various systems within the vehicle (e.g., propulsion, perception sensors, communication, etc).

The publication rate is defined on a per-service basis, but it should never be lower than 1 Hz,
excepting services that are in the SLEEP state, in which case it is permitted to cease all network activity.

truncated uint2 value [max length 2 bits]

saturated uint2 SLEEP = 0

The long-term state of minimal power consumption.
Typically, most subsystems are switched into the SLEEP mode when the vehicle is parked and powered off.
Subsystems that do not support the SLEEP state should treat it as an equivalent of STANDBY.

A subsystem may require a substantial amount of time to exit the sleep mode (for example, time may be needed to
boot the operating system and run the self test procedures).

While in the SLEEP mode, the subsystem is allowed to cease service provision and stop all network activity
regardless of other requirements, except that it shall be able to reactivate itself if a Readiness message is
received commanding any state other than SLEEP.

saturated uint2 STANDBY = 2

The state of being ready to enter the normal operating mode in a short order.
A subsystem that is in STANDBY state should be able to participate in the normal network activity.
This is the default state that the subsystem should reside in after power-on until explicitly commanded otherwise.

saturated uint2 ENGAGED = 3

When ENGAGED, the subsystem is performing its main intended function at the nominal performance characteristics.
A subsystem may require a short amount of time, possibly under a few seconds, to switch between the ENGAGED and
STANDBY states (in any direction).
Some subsystems may not differentiate between STANDBY and ENGAGED (e.g., offboard communication hardware).
The subsystem may disengage itself autonomously in the event of a fatal malfunction, in which case
the reported service health status should be WARNING.

The standard DOP estimates (https://en.wikipedia.org/wiki/Dilution_of_precision).
DOP values should not be confused with accuracy estimates -- those are expressed through the covariance matrices.

Applicable relations:
  gdop = (ndop^2 + edop^2 + vdop^2 + tdop^2)^0.5
  pdop = (ndop^2 + edop^2 + vdop^2)^0.5
  hdop = (ndop^2 + edop^2)^0.5

Fields whose values are unknown should be set to NaN.

saturated float16 geometric [max length 2.0 bytes]

GDOP

saturated float16 position [max length 2.0 bytes]

PDOP

saturated float16 horizontal [max length 2.0 bytes]

HDOP

saturated float16 vertical [max length 2.0 bytes]

VDOP

saturated float16 time [max length 2.0 bytes]

TDOP

saturated float16 northing [max length 2.0 bytes]

NDOP

saturated float16 easting [max length 2.0 bytes]

EDOP

Optional, extended information on the performance of the GNSS sensor.

+ reg.drone.service.common.Heartbeat (v0.1) heartbeat [extent 2.0 bytes] [max length 2.0 bytes]

The function of the service heartbeat is similar to that of the node heartbeat defined in the standard namespace,
except that it is used on a per-service basis, meaning that there may be more than one publisher per node.

The service heartbeat should be published either on a separate subject, or as a structural supertype of a
service-specific status subject. The publication rate is service-specific but it should not be lower than 1 Hz.

This is a structural subtype of the Readiness type.

The readiness state is used to command or report the availability status of a networked service (subsystem).

Any system shall have at least one readiness command subject that acts as a global power switch.
Every subsystem controlled in such way would usually report its readiness status back to account for the fact that
the transition between different readiness states may not be instantaneous.
The readiness status reporting is done by means of the service heartbeat type that is also defined in this namespace;
the service heartbeat type is a structural subtype of this type.

  +------------+
  | Controller |----------+----------------+----------------+---------...     readiness command subject
  +------------+          |                |                |
    ^   ^   ^             v                v                v
    |   |   |        +---------+      +---------+      +---------+
    |   |   |        | Service |      | Service |      | Service |    ...
    |   |   |        +---------+      +---------+      +---------+
    |   |   |             |                |                |
    |   |   +-------------+                |                |
    |   +----------------------------------+                |                 service heartbeat subjects
    +-------------------------------------------------------+

In a less trivial use case there may be an arbitrary number of such readiness command subjects (local power switches)
controlling various systems within the vehicle (e.g., propulsion, perception sensors, communication, etc).

The publication rate is defined on a per-service basis, but it should never be lower than 1 Hz,
excepting services that are in the SLEEP state, in which case it is permitted to cease all network activity.

The long-term state of minimal power consumption.
Typically, most subsystems are switched into the SLEEP mode when the vehicle is parked and powered off.
Subsystems that do not support the SLEEP state should treat it as an equivalent of STANDBY.

A subsystem may require a substantial amount of time to exit the sleep mode (for example, time may be needed to
boot the operating system and run the self test procedures).

While in the SLEEP mode, the subsystem is allowed to cease service provision and stop all network activity
regardless of other requirements, except that it shall be able to reactivate itself if a Readiness message is
received commanding any state other than SLEEP.

The state of being ready to enter the normal operating mode in a short order.
A subsystem that is in STANDBY state should be able to participate in the normal network activity.
This is the default state that the subsystem should reside in after power-on until explicitly commanded otherwise.

When ENGAGED, the subsystem is performing its main intended function at the nominal performance characteristics.
A subsystem may require a short amount of time, possibly under a few seconds, to switch between the ENGAGED and
STANDBY states (in any direction).
Some subsystems may not differentiate between STANDBY and ENGAGED (e.g., offboard communication hardware).
The subsystem may disengage itself autonomously in the event of a fatal malfunction, in which case
the reported service health status should be WARNING.

Abstract component health information. If the node performs multiple activities (provides multiple network services),
its health status should reflect the status of the worst-performing activity (network service).
Follows:
  https://www.law.cornell.edu/cfr/text/14/23.1322
  https://www.faa.gov/documentLibrary/media/Advisory_Circular/AC_25.1322-1.pdf section 6

The component is functioning properly (nominal).

A critical parameter went out of range or the component encountered a minor failure that does not prevent
the subsystem from performing any of its real-time functions.

The component encountered a major failure and is performing in a degraded mode or outside of its designed limitations.

The component suffered a fatal malfunction and is unable to perform its intended function.

Any service that is not in the SLEEP state should publish its heartbeat (or a derived status) at least at this rate.

+ reg.drone.service.gnss.Sources (v0.1) sources [extent 6.0 bytes] [max length 6.0 bytes]

There are multiple satellite networks and other data sources which provide autonomous geo-spatial positioning
with global coverage. These flags are used for identifying which of those data sources
are the source of the location data provided by the GNSS sensor node.

Note that these fields convey no information about the status the navigation solution. Here is a specific example:

- Heartbeat.fix     - indicates that a standalone navigation solution is available.

- Heartbeat.rtk_fix - indicates that an RTK fix is established and the integer wavelength ambiguity is resolved.

- Sources.rtk_base  - indicates that base station data (usually encapsulated into RTCM stream) is available
                      to the receiver, but it says nothing about the status of the navigation solution.

1575.42 MHz

1227.60 MHz

1176.45 MHz

1602 + k 0.5625 MHz, k in [-7,6]

1246 + k 0.4375 MHz, k in [-7,6]

TBA

1575.42 MHz

1176.45 MHz

1207.14 MHz

1278.75 MHz

1531.098 MHz

1207.140 MHz

Reserved for other constellations.

Satellite-Based Augmentation System (WAAS, EGNOS, GAGAN, QZSS, etc.)

Ground-Based Augmentation System, DGPS (IMES, etc.)

Real-Time Kinematics base station data

Reserved for other RTK-related sources.

Inertial Measurement Unit

Any dead reckoning equipment (e.g., wheel odometry)

Ultra-wideband positioning

Add new items here to ensure backward compatibility.

+ reg.drone.service.gnss.DilutionOfPrecision (v0.1) dop [extent 14.0 bytes] [max length 14.0 bytes]

The standard DOP estimates (https://en.wikipedia.org/wiki/Dilution_of_precision).
DOP values should not be confused with accuracy estimates -- those are expressed through the covariance matrices.

Applicable relations:
  gdop = (ndop^2 + edop^2 + vdop^2 + tdop^2)^0.5
  pdop = (ndop^2 + edop^2 + vdop^2)^0.5
  hdop = (ndop^2 + edop^2)^0.5

Fields whose values are unknown should be set to NaN.

GDOP

PDOP

HDOP

VDOP

TDOP

NDOP

EDOP

saturated uint8 num_visible_satellites [max length 1.0 bytes]

The number of space vehicles visible when the solution was computed.

saturated uint8 num_used_satellites [max length 1.0 bytes]

The number of space vehicles whose signals have been utilized to derive the solution.

saturated bool fix [max length 1 bits]

True if a GNSS fix is established (of any dimensionality, e.g., time-only).
Data consumers should not use this flag and rely on the error estimates reported via covariance matrices instead.
If the sensor is equipped with other means of deriving the navigation solution (dead reckoning, VIO, UWB, etc.),
then this flag may not be representative of the actual status of the solution (only matrices are).

saturated bool rtk_fix [max length 1 bits]

True if the current mode is RTK and an RTK fix has been established.
This flag should not be set unless `fix` is also set.
The availability of base station data is indicated using a separate (orthogonal) flag defined in Sources.

There are multiple satellite networks and other data sources which provide autonomous geo-spatial positioning
with global coverage. These flags are used for identifying which of those data sources
are the source of the location data provided by the GNSS sensor node.

Note that these fields convey no information about the status the navigation solution. Here is a specific example:

- Heartbeat.fix     - indicates that a standalone navigation solution is available.

- Heartbeat.rtk_fix - indicates that an RTK fix is established and the integer wavelength ambiguity is resolved.

- Sources.rtk_base  - indicates that base station data (usually encapsulated into RTCM stream) is available
                      to the receiver, but it says nothing about the status of the navigation solution.

saturated bool gps_l1 [max length 1 bits]

1575.42 MHz

saturated bool gps_l2 [max length 1 bits]

1227.60 MHz

saturated bool gps_l5 [max length 1 bits]

1176.45 MHz

saturated bool glonass_l1 [max length 1 bits]

1602 + k 0.5625 MHz, k in [-7,6]

saturated bool glonass_l2 [max length 1 bits]

1246 + k 0.4375 MHz, k in [-7,6]

saturated bool glonass_l3 [max length 1 bits]

TBA

saturated bool galileo_e1 [max length 1 bits]

1575.42 MHz

saturated bool galileo_e5a [max length 1 bits]

1176.45 MHz

saturated bool galileo_e5b [max length 1 bits]

1207.14 MHz

saturated bool galileo_e6 [max length 1 bits]

1278.75 MHz

saturated bool beidou_b1 [max length 1 bits]

1531.098 MHz

saturated bool beidou_b2 [max length 1 bits]

1207.140 MHz

void5 [max length 5 bits]

Reserved for other constellations.

saturated bool sbas [max length 1 bits]

Satellite-Based Augmentation System (WAAS, EGNOS, GAGAN, QZSS, etc.)

saturated bool gbas [max length 1 bits]

Ground-Based Augmentation System, DGPS (IMES, etc.)

saturated bool rtk_base [max length 1 bits]

Real-Time Kinematics base station data

void3 [max length 3 bits]

Reserved for other RTK-related sources.

saturated bool imu [max length 1 bits]

Inertial Measurement Unit

saturated bool visual_odometry [max length 1 bits]

saturated bool dead_reckoning [max length 1 bits]

Any dead reckoning equipment (e.g., wheel odometry)

saturated bool uwb [max length 1 bits]

Ultra-wideband positioning

void4 [max length 4 bits]

saturated bool magnetic_compass [max length 1 bits]

saturated bool gyro_compass [max length 1 bits]

saturated bool other_compass [max length 1 bits]

void14 [max length 14 bits]

Add new items here to ensure backward compatibility.

The current time estimated by a GNSS receiver. See TAI64 for details, of which this one is a structural subtype.

TAI is short for International Atomic Time: https://en.wikipedia.org/wiki/International_Atomic_Time.
TAI is always a fixed integer number of seconds ahead of GPS time.
Systems that use GPS time as a reference shall convert that to TAI by adding the fixed difference.
GPS time is not supported for reasons of consistency across different positioning systems and applications.

The error variance is expected to increase if the GNSS signal deteriorates.
If the signal is lost, this value is expected to grow steadily, the rate of growth dependent on the quality of
the time keeping hardware available locally (bad hardware yields faster growth).
Once the signal is regained, this value would drop back to nominal.

+ reg.drone.physics.time.TAI64VarTs (v0.1) value [extent 19.0 bytes] [max length 19.0 bytes]

Nested data type used for representing a network-wide synchronized timestamp with microsecond resolution.
This data type is highly recommended for use both in standard and vendor-specific messages alike.

The number of microseconds that have passed since some arbitrary moment in the past.
The moment of origin (i.e., the time base) is defined per-application. The current time base in use
can be requested from the time synchronization master, see the corresponding service definition.

This value is to never overflow. The value is 56-bit wide because:

  - 2^56 microseconds is about 2285 years, which is plenty. A 64-bit microsecond counter would be
    unnecessarily wide and its overflow interval of 585 thousand years induces a mild existential crisis.

  - Classic-CAN (not FD) transports carry up to 7 bytes of payload per frame.
    Time sync messages shall use single-frame transfers, which means that the value can't be wider than 56 bits.

Zero means that the time is not known.

Standard TAI64N time label (https://cr.yp.to/libtai/tai64.html). Quote from the source:

  TAI stands for Temps Atomique International, the current international real-time standard.
  One TAI second is defined as the duration of 9192631770 periods of the radiation corresponding
  to the transition between the two hyperfine levels of the ground state of the cesium atom.
  TAI also specifies a frame of reference. Further discussion of special relativity is outside
  the scope of this document.

  A TAI64 label is an integer between 0 and 2^64 referring to a particular second of real time. Integer s refers to:

      - the TAI second beginning exactly 2^62 - s seconds before the beginning of 1970 TAI,
        if s is between 0 inclusive and 2^62 exclusive; or

      - the TAI second beginning exactly s - 2^62 seconds after the beginning of 1970 TAI,
        if s is between 2^62 inclusive and 2^63 exclusive.

[nanosecond] Nanoseconds elapsed since 1970-01-01T00:00:00Z TAI.

[second^2]
Error variance, in second squared, of the time estimate.
Infinity indicates that the time estimates are not yet available.
A non-positive value indicates that the error variance is unknown.

Supertype.

+ uavcan.time.TAIInfo (v0.1) info [extent 2.0 bytes] [max length 2.0 bytes]

This data types defines constants and runtime values pertaining to the International Atomic Time, also known as TAI.
See https://en.wikipedia.org/wiki/International_Atomic_Time.

The relationship between the three major time systems -- TAI, GPS, and UTC -- is as follows:

  TAI = GPS + 19 seconds
  TAI = UTC + LS + 10 seconds

Where "LS" is the current number of leap seconds: https://en.wikipedia.org/wiki/Leap_second.

UAVCAN applications should only rely on TAI whenever a global time system is needed.
GPS time is strongly discouraged for reasons of consistency across different positioning systems and applications.

The current difference between TAI and UTC, if known. If unknown, set to zero.

This value may change states between known and unknown while the master is running,
depending on its ability to obtain robust values from external sources.

This value may change twice a year, possibly while the system is running; https://en.wikipedia.org/wiki/Leap_second.
Since the rotation of Earth is decelerating, this value may only be positive. Do not use outside Earth.

For reference, here is the full list of recorded TAI-UTC difference values, valid at the time of writing:

    Date     | TAI-UTC difference [second]
   ----------|-----------------------------
    Jan 1972 | 10
    Jul 1972 | 11
    Jan 1973 | 12
    Jan 1974 | 13
    Jan 1975 | 14
    Jan 1976 | 15
    Jan 1977 | 16
    Jan 1978 | 17
    Jan 1979 | 18
    Jan 1980 | 19
    Jul 1981 | 20
    Jul 1982 | 21
    Jul 1983 | 22
    Jul 1985 | 23
    Jan 1988 | 24
    Jan 1990 | 25
    Jan 1991 | 26
    Jul 1992 | 27
    Jul 1993 | 28
    Jul 1994 | 29
    Jan 1996 | 30
    Jul 1997 | 31
    Jan 1999 | 32
    Jan 2006 | 33
    Jan 2009 | 34
    Jul 2012 | 35
    Jul 2015 | 36
    Jan 2017 | 37

As of 2020, the future of the leap second and the relation between UTC and TAI remains uncertain.

[second]
The fixed difference, in seconds, between TAI and GPS time. Does not change ever.
Systems that use GPS time as a reference should convert that to TAI by adding this difference.

Actual information about TAI. This information can be used to convert TAI into UTC.

A generic sensor status information.
This data should be published at a low rate but not lower than the specified limit.

+ uavcan.si.unit.duration.Scalar (v1.0) data_validity_period [extent 4.0 bytes] [max length 4.0 bytes]

Data samples obtained at time Ts are valid at time Tr if: (Tr - Ts) < data_validity_period
Expired data should be discarded.

saturated uint32 error_count [max length 4.0 bytes]

Incremented once per occurrence. Reset to zero when the sensor is ENGAGED.
The exact definition of what constitutes an error is implementation-dependent.

+ uavcan.si.unit.temperature.Scalar (v1.0) sensor_temperature [extent 4.0 bytes] [max length 4.0 bytes]

The temperature of the sensing element.
If there are multiple sensing elements or multiple temperature probes per sensor,
the reduction is implementation-defined.
In a later revision this field may be moved into a separate type.

saturated uint8 MAX_PUBLICATION_PERIOD = 1

[second]