# BatteryInfo message **URL:** \ **Category:** Applications & Usage\ **Created:** [November 2, 2020, 8:00am UTC](https://forum.opencyphal.org/t/batteryinfo-message/977 "2020-11-02T08:00:55Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![kishore](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/kishore/32/727_2.png) [@kishore](https://forum.opencyphal.org/u/kishore)\ **Post date:** [November 2, 2020, 8:00am UTC](https://forum.opencyphal.org/t/batteryinfo-message/977/1 "2020-11-02T08:00:55Z")
Hi Everyone, I’m completely new to UAVCAN and just managed to get it working on a stm32f042 processor. I am able to send heartbeat messages every second from my node. Next i want to send some battery information such as realtime current, realtime voltage and total charge consumed. etc. Searching the internet it seemed like there was standard format ([https://uavcan.org/Specification/7.\_List\_of\_standard\_data\_types/#batteryinfo](https://uavcan.org/Specification/7._List_of_standard_data_types/#batteryinfo)) but it could have changed after v1.0 release. Any advise on how to do this of the places i need to look for direction would be helpful. ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [November 2, 2020, 3:39pm UTC](https://forum.opencyphal.org/t/batteryinfo-message/977/2 "2020-11-02T15:39:13Z")
Even if your application has nothing to do with drones, you may benefit from adopting the DS-015 data distribution standard. Entry points for you: - [README](https://github.com/UAVCAN/public_regulated_data_types/blob/master/reg/drone/README.md) for the `reg.drone` namespace. - electricity-related data types [`reg.drone.phy.electricity`](https://github.com/UAVCAN/public_regulated_data_types/tree/master/reg/drone/phy/electricity) - smart battery network services [`reg.drone.srv.battery`](https://github.com/UAVCAN/public_regulated_data_types/blob/master/reg/drone/srv/battery/_.0.1.uavcan) - document [DS-015 UAVCAN Drone Standard](https://docs.google.com/document/d/1wiPP7eI99Q7jB9RMKTncdzoOTahmwGot6I7Jps0DAsc/edit) We are currently working on a set of comprehensive examples and tutorials to lower the entry barriers. ---
**Author:** ![kishore](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/kishore/32/727_2.png) [@kishore](https://forum.opencyphal.org/u/kishore)\ **Post date:** [November 3, 2020, 5:43am UTC](https://forum.opencyphal.org/t/batteryinfo-message/977/3 "2020-11-03T05:43:15Z")
Thanks for your response. The device certainly has application in drones too. I shall refer to your links and revert back in case of doubt. ---
**Author:** ![kishore](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/kishore/32/727_2.png) [@kishore](https://forum.opencyphal.org/u/kishore)\ **Post date:** [November 3, 2020, 4:24pm UTC](https://forum.opencyphal.org/t/batteryinfo-message/977/4 "2020-11-03T16:24:17Z")
I went through the linked documents and i have a couple of doubts since i’m new to the specification. I am in the process of creating two related products, First, is the equivalent of a power brick and hence should provide a minimum of current voltage and current. Charge (mah or watt) can be a optional additional parameter. Second, is a BMS which should provide the additional information of battery % (or absolute values) My questions are as follows: 1. What should be the sign of the value for current in each product? 2. What should be the subject id? I suspect, it should be negotiated. I dont yet fully understand how the negotiation works. A timing / sequence diagram with the messages involved would be helpful. Since, I’m new to the DSDL and the .uavcan file format would this be the format for [Power.0.1.uavcan](https://github.com/UAVCAN/public_regulated_data_types/blob/master/reg/drone/phy/electricity/Power.0.1.uavcan) struct UAVCANPowerInfo { float32 current; float32 voltage; } ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [November 3, 2020, 9:06pm UTC](https://forum.opencyphal.org/t/batteryinfo-message/977/5 "2020-11-03T21:06:13Z")
> [@kishore](#): > > First, is the equivalent of a power brick and hence should provide a minimum of current voltage and current. Charge (mah or watt) can be a optional additional parameter. Charge is an integral of current over time; common units are coulomb or ampere-hour (not watt, that is a unit of power). I don’t know what your business requirements are, but in case it is related to endurance estimation, you should be aware that contrary to a common misconception, electric charge alone may not be an accurate representation of the amount of energy (integral of power over time) that can be reclaimed from the battery. Perhaps what you are looking for is [`reg.drone.phy.electricity.Source`](https://github.com/UAVCAN/public_regulated_data_types/blob/master/reg/drone/phy/electricity/Source.0.1.uavcan) — this type is the correct choice as far as the physics is concerned. If my guess about your application was incorrect, then please ignore this remark. > [@kishore](#): > > Second, is a BMS which should provide the additional information of battery % (or absolute values) The smart battery service is specified in [`reg.drone.srv.battery`](https://github.com/UAVCAN/public_regulated_data_types/blob/acc9ef0f9e54f220712f21f0cea8123986b94def/reg/drone/srv/battery/_.0.1.uavcan). > [@kishore](#): > > What should be the sign of the value for current in each product? Negative when discharging, positive when charging. This is specified in reg.drone.phy.electricity.Power/Source. > [@kishore](#): > > What should be the subject id? I suspect, it should be negotiated. I dont yet fully understand how the negotiation works. A timing / sequence diagram with the messages involved would be helpful. It can be arbitrary, chosen at the time of integration when the device is connected to the vehicle. The device is supposed to have configuration parameters that are assigned by the integrator or the end user once and then stored in the non-volatile memory. The UAVCAN Guide might also be helpful here; additionally, you may have a look at [Choosing Message and Service IDs](https://forum.opencyphal.org/t/choosing-message-and-service-ids/889). > [@kishore](#): > > Since, I’m new to the DSDL and the .uavcan file format would this be the format for [Power.0.1.uavcan](https://github.com/UAVCAN/public_regulated_data_types/blob/master/reg/drone/phy/electricity/Power.0.1.uavcan) Yes and no. Yes because serialization-wise you will get the correct representation on the wire. No because your example omits valuable type information from the nested types; you can see that they are not primitives: > If you look up their definitions, you will see that they specify the unit of measurement, eliminating the risk of accidental misuse: > > We are currently working on an automatic code generation tool for this, by the way. ETA next week, you can follow the progress by subscribing to [GitHub - OpenCyphal/nunavut: Generate code from DSDL using PyDSDL and Jinja2](https://github.com/UAVCAN/nunavut). Hope this helps! ---
**Author:** ![kishore](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/kishore/32/727_2.png) [@kishore](https://forum.opencyphal.org/u/kishore)\ **Post date:** [November 7, 2020, 11:15am UTC](https://forum.opencyphal.org/t/batteryinfo-message/977/6 "2020-11-07T11:15:09Z")
> [@pavel.kirienko](#): > > Charge is an integral of current over time; common units are coulomb or ampere-hour Sorry, I meant to write watt hour. Anyway, I would like to stick to the standards established. > [@pavel.kirienko](#): > > Perhaps what you are looking for is [`reg.drone.phy.electricity.Source`](https://github.com/UAVCAN/public_regulated_data_types/blob/master/reg/drone/phy/electricity/Source.0.1.uavcan) — this type is the correct choice as far as the physics is concerned. If my guess about your application was incorrect, then please ignore this remark. I still don’t think I understand this right. Of the two products, the first is a battery to 5V step down power supply that also measures the battery voltage and load current that passes through it. The second device is effectively an integral part of the battery (Source). It is entirely possible that these both nodes co exist on on system. First, for providing a 5V supply rail and second for managing the charge / discharge of the battery itself. These two devices would then have an overlap of functionality of measuring Current and Voltage. > [@pavel.kirienko](#): > > The smart battery service is specified in [`reg.drone.srv.battery`](https://github.com/UAVCAN/public_regulated_data_types/blob/acc9ef0f9e54f220712f21f0cea8123986b94def/reg/drone/srv/battery/_.0.1.uavcan). I think the type in lines 5 & 6 should be edited to remove “sesnor.” > [@pavel.kirienko](#): > > We are currently working on an automatic code generation tool for this, by the way. ETA next week, you can follow the progress by subscribing to [GitHub - OpenCyphal/nunavut: Generate code from DSDL using PyDSDL and Jinja2](https://github.com/UAVCAN/nunavut). I’m looking forward to this. It would help me understand better. Any existing file pair of .uavcan ↔ .h[pp] that i can refer to? On the device implementation, I think I understand how to publish subject messages as public Heartbeat messages (using an own implementation of the payload message structure) but still need to understand services. Any small examples? ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [November 11, 2020, 5:12pm UTC](https://forum.opencyphal.org/t/batteryinfo-message/977/7 "2020-11-11T17:12:05Z")
> [@kishore](#): > > Of the two products, the first is a battery to 5V step down power supply that also measures the battery voltage and load current that passes through it. The second device is effectively an integral part of the battery (Source). It is entirely possible that these both nodes co exist on on system. First, for providing a 5V supply rail and second for managing the charge / discharge of the battery itself. These two devices would then have an overlap of functionality of measuring Current and Voltage. Of course. If you have, say, a braking resistor on a robot, it would probably also measure the current, voltage, and the amount of dissipated energy, hence a yet another Source. There may be a separate battery for the payload – also a Souce, etc. It is only natural that similar physical processes are modeled using the same type; that’s what types are for, in the end. > [@kishore](#): > > I think the type in lines 5 & 6 should be edited to remove “sesnor.” Thank you, fixed. > [@kishore](#): > > I’m looking forward to this. It would help me understand better. Any existing file pair of .uavcan ↔ .h[pp] that i can refer to? This has been finished yesterday, although it is not yet merged ([currently under review](https://github.com/UAVCAN/nunavut/pull/161/), ETA next week). But you can already use it; here’s a relevant quote from the pull request: > ``` > git clone https://github.com/UAVCAN/nunavut --branch c-serialization-corrections > cd nunavut > pip install . > cd - > git clone https://github.com/UAVCAN/public_regulated_data_types/ > nnvg --target-language c --pp-max-emptylines=1 --pp-trim-trailing-whitespace --target-endianness=little --enable-serialization-asserts public_regulated_data_types/uavcan > > ``` > > Options `--pp-max-emptylines=1 --pp-trim-trailing-whitespace` will become unnecessary after #159 is fixed. > > Option `--target-endianness=little` may be omitted, which will result in endianness-agnostic code that is portable but slower and possibly larger. > > Option `--enable-serialization-asserts` injects cross-checks in the generated serialization routines which slows them down and increases the ROM footprint but protects against possible memory corruption and detects some of the possible issues in the generated code. It is recommended to always enable it. > [@kishore](#): > > On the device implementation, I think I understand how to publish subject messages as public Heartbeat messages (using an own implementation of the payload message structure) but still need to understand services. Any small examples? These examples might help, I think: [Libcanard: Examples, Starters, Tutorials - #4 by hugo](https://forum.opencyphal.org/t/libcanard-examples-starters-tutorials/935/4). If you have any specific questions, do ask.