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.
The smart battery service is specified in reg.drone.srv.battery.
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 GitHub - OpenCyphal/nunavut: Generate code from DSDL using PyDSDL and Jinja2.
Hope this helps!