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.
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:
What should be the sign of the value for current in each product?
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
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 — 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.
Negative when discharging, positive when charging. This is specified in reg.drone.phy.electricity.Power/Source.
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.
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 https://github.com/UAVCAN/nunavut.
Sorry, I meant to write watt hour. Anyway, I would like to stick to the standards established.
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.
I think the type in lines 5 & 6 should be edited to remove “sesnor.”
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?
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.
Thank you, fixed.
This has been finished yesterday, although it is not yet merged (currently under review, 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.