UAVCAN for Hobbiests

No, it is DIY and should be.

The point is that the presented brick can already be used by everybody without any vendor specific messages. The vendor specific message or change of a standard one or the introduction of a new standard one can be made as a second step. The only difference is what device will calculate the current drawn (either AP or brick).

I am kind of lost now - first OlliW tells that he has absolutely no interest to make this a product. Then that it is a so good device and everybody can use it and I see that there is interest from real users. Whatā€™s going on? I feel I am missing something.

OlliW shares all his projects with the DIY community. That is what drives him. He publishes his designs and because of the popularity many have been taken up by manufacturers and produced for the mass market and he receives no compensation.

I am not versed to participate in the technical aspect of this conversation. But again from the cheap seats it does seem that you will never be able to encompass all new devices with the messages that are built into the protocol today, as desirable as that is for practical use. So having vendor specific messages that are easy to implement and isolated seems like a required feature in order for the protocol to adapt to future devices. Devices that may not even exist today.

Well, the PR that has support for the brick is open since 1st of July.
I would ask all interested in getting battery to work over CAN to vote that itā€™s needed to core devs so it will get merged soon.
Another issue is that CircuitStatus message as a battery info got resistance and I had to remove it from battery support, so I am asking OlliW to add the possibility to send current BatteryStatus message only filled with id, current and voltage, so that his brick will be usable right away after the PR gets merged. It is not a big deal and will take only about 10 lines of code.

The vendor specific messages are on the way with another PR from Mark, and as I told many times I am willing that support for that gets in AP. However we need to be very carefull not to overwhelm the code with too many messages that are really not needed.

Another major thing is that Pavel is making versioning of messages in UAVCAN and that will help a lot in tuning the messages we have now without introducing new ones. I would advise to wait for some time before giving birth to many vendor specific messages.

1 Like

Thank you very much EShamaev.

the PR that has support for the brick is open since 1st of July.

yeah ā€¦ I mentioned it repeatedly that your great PRs are hanging loose ā€¦ with little success as it seems :slight_smile:

Another issue is that CircuitStatus message as a battery info got resistance and I had to remove it from battery support,

IMHO not a wrong move (I think you had exactly the same problem at this time, a proper message wasnā€™t there but one had to be picked, so you did the best possible at this time, and it was highly useful as it provided a great template)

I am asking OlliW to add the possibility to send current BatteryStatus message

Iā€™ll replace CircuitStatus by BatteryStatus. Iā€™ll keep GenericBatteryStatus in my BetaCopter (and move it to ā€œmyā€ vendor specific section) for as long as there is no alternative

However we need to be very careful not to overwhelm the code with too many messages that are really not needed.

this was never my intention. In a response to tridge I actually tried to emphasize that I only would like v.s. message support in as much as that one can add messages to one owns local fork without having to break with hell (UAVCAN for Hobbiests - #69 by olliw42). The example with the UserCode,UserVariables files was supposed to indicate this. As much as I see from your comment in a PR you yourself would appreciate support for v.s. messages for the same reasons. That is, I would very much like to be able to overwhelm BetaCopter, but only BetaCopter :wink:

@olliw42 and @EShamaev can you please summarise what was finally agreed here?

@james_pattison I well understand the good intent of this question, but I donā€™t feel able to summarize an agreement. Pavelā€™s and Eugenā€™s positions are not totally clear to me, and some comments I find confusing. So, I only can and want comment on some points which I think have been born out, if everyone agrees on them or not.

  • I think it has become clear that energy, Wh, is not the same as charge, mAh, and that they are not exchangeable easily, if at all, in practical situations, since quite different error sources enter in their estimation and in their ability to reflect the true state of a battery.

  • I think it has become clear that estimating the energy representing the state of a battery is significantly more difficult, while measurements of the charge provides a relatively robust representation of the state of the battery. I purposely distinguished here between ā€œestimationā€ and ā€œmeasurementā€ to indicate that on top of the measurement the energy counting is also highly dependent on proper modeling the battery and calibration of the model, while in the charge counting one directly goes with the measurement result.

My personal conclusion of this would be: In simple terms I would say that energy counting requires smart batteries while charge counting is the method of first choice in all other cases.

  • Since Wh and mAh are not exchangeable in practical situations, the BatteryInfo and GenericBatteryInfo dsdl data types are not exchangeable in practical situations.

My personal conclusions of this would be: This does not imply that the GenericBatteryInfo in its current form is the best call. However, since Wh and mAh are not exchangeable, one would need means to reflect both in dsdls. Two different DSDLs appear natural, but other DSDL designs might do it also.

  • As regards the vendor specific messages I cannot yet see a consistent picture. Pavel has many times expressed his opinion, but it is not clear to me what conclusion he is finally drawing, i.e., in which form he wants or is willing vendor specific messages to be present. Eugene has recently made statements which I read to mean that he would be pro vendor specific messages. I myself have tried to consistently emphasize that for me the topic of how to get along with the vendor specific messages is THE central question, which is more than overdue to be settled. If this reflects an accurate summary only Pavel and Eugene can confirm or disconfirm.

My personal conclusions of this would be:

I want to add my earlier comment to tridge, that I do see here 3 levels of abstraction: The UAVCAN standard, ArduPilot, local programmers/forkers.

In my opinion the ā€œrulesā€ for handling vendor specific messages do not have to be identical on all levels. Obviously, no rules exist on the local programmers/forkers level, no one can stop anyone to privately fool around, but support in the build system should be there. The ā€œrulesā€ for handling vendor specific messages on the UAVCAN standard level have to be ultimately finalized by Pavel (I presume). Where I am quite lost is the position of the ArduPilot project. It had been silent for many months. When I say that the topic of the vendor specific messages is overdue to be settled, I mean that the ArduPilot project is overdue to voice itā€™s position unambiguously.

Iā€™m not sure this helps, I only can hope so. The text certainly became longer than what the content warrants, since I tried formulate carefully and neutrally. Iā€™m not sure I managed, I only can hope so.

1 Like

Not to go back and throw more fuel on the fire, but I think there are a couple of points worth mentioning.

SMBus (which seems to be much of the inspiration of the BatteryInfo message) officially support both Wh and mAh on most fields, in fact itā€™s officially a read/write flag bit that lets you set the preferred mode for your application. Further the spec actually describes that Wh/mAh both have their own applications to which they are better suited.

Iā€™d favor a message that supports transporting the mAh hours remaining as well (or in addition to Wh). As was also pointed out here a power module has the opportunity to do much faster and higher resolution then the autopilot does. The current PR that adds support for the BatteryInformation (which I have slid back into the mental tracking list for reviewing it) does attempt to do current integration to provide the autopilot with a capacity consumed (and remaining) estimate. Speaking purely from the autopilot side we donā€™t have anyway to handle the Wh information that is sent in at the moment and it is wasting bandwidth. (The AP might be able to overload the Ah fields to actually mean Wh when a CAN battery is enabled but it would be new territory for it.)

The proposal from Olli for a extended battery ID is also far superior to the 8 bit ID currently provided. Again the SMBus spec provides a serial number field, which is great for both manufacturers and users to correlate what battery was used (and caused an issue) on a given flight.

Basically I can be summarized as being in strong favor of either an extended message that incorporates these changes or a pair of messages, but I think Olli is absolutely correct in identifying that a battery module is very different from a smart battery, and that the current message set does not map onto the monitor use case well at all.

4 Likes

I have to clarify one important thing.
As WickedShell noted in SMBus there is an option to do reporting in either Wh or mAh. And I do not mind having mAh to be used now as a measure but there is one thing that renders it useless at least from my experience in my tasks.

I think it was my fault that I did not state exactly what concers me clear enough.

When I told that consumed mAh is useless is only because we do not have a ā€œstarting pointā€. And if I do not know exactly how much there was in battery from the start - it is really useless to know how much I consumed, no matter how correct that measurement is.
Right now for me, the main indicator of how much energy is left is the voltage of the battery.

This is a clarification of my statements and should not be read as an any argument for changing/adding messages to UAVCAN or not doing so.

UC4H Esc-Actuator Node

Iā€™ve extended the firmware to allow now for up to 6 PWM output signals. Currently only for motor ESC, and not yet servo. The node also emits the esc.Status message, but it just contains the inputs, not any real live telemetry data (this I will attempt to add when I get the BLHeli_32 ESCs Iā€™ve ordered).

The firmware is only bench tested, not yet flight tested (my copter is currently equipped with a non-ArduPilot controller). I thought I nevertheless provide it, for those who want to fool around :).

The node can be build using the DIY stuff as for the other nodes, or the UC4H GPS-Mag pcb.

The firmware is in the github repository.
Some info is also on my web page: http://www.olliw.eu/2017/uavcan-for-hobbyists/#chapterescactuator

2 Likes

Hello!I really admire you for making so many UAVCAN devices. Do you have any intention to do CAN servo?

I did not find the UC4H Power Brick PCB file. My E-MAIL: lankafei0933@hotmail.com Thank you

The main location for information on UC4H is locate at RCGroups:

RCGROUPS UC4H

A follow up note:
UC4H UAVCAN nodes for ESC, GPS, Barometer, Serial bridge etc are being produced by JDrones and can be purchased on Janiā€™s webstore. This is a major step forward in making UAVCAN a DIY standard.

http://store.jdrones.com/uavcan_electronics_jdrones_s/314.htm

two question. one ! do I need a Specific parameter on beatcopter when using UC4H Power? two! how do I show you specific data type decode on UAVCAN GUI Bus monitor ? cause in my UAVCAN GUI you data type is unkown but type ID . thank you !!

from OlliW

  • There are two UAVCAN messages which can be used, the CircuitStatus message, which is member of the standard messages, and the GenericBatteryInfo message, which is my home-brewed message. In both cases you currently need BetaCopter to use either.

  • The power brick can be configured to emit either of them (or both LOL), the node has respective parameters.

  • You may notice that these messages have an ā€œidā€ field, for CircuitStatus it is called circuit_id, and for GenericBatteryInfo I have forgotten, maybe battery_id. You need to know this value for your power brick. So, pl, inspect the power brickā€™s parameters and read off this value (itā€™s maybe 1, I have forgotten however)

  • ArduPilot: The above messages are digested by AP_BattMonitor, and and it has its parameters in the Batt section, if Iā€™m not mistaken.

  • In the Batt section you should find a parameter Batt_SERIAL_NUM with which you can set the ā€œidā€ to which the battery monitor should listen.

  • there is an additional parameter in the Batt section which needs to be set to activate using the UAVCAN, Batt_MONITOR: Set it to 8 for using the CircuitStatus message, and to 10 for using the GenericBatteryInfo message

  • to be sure set Batt_VOLT_PIN = -1, and Batt_ CURR_PIN = -1

sorry !! no use BATT_MONITOR =8 Batt_SERIAL_NUM =1 Batt_VOLT_PIN = -1, and Batt_ CURR_PIN = -1 also I didnā€™t find ā€œcircuit_idā€ . uch4-powerbrick version is v006. on more thing that I can get you own data type masage. it alwayw ā€œunknow massageā€ thank you help~~~ thank you


In uc4h powerbrick I find some vaule is ā€œnanā€ so what is nan ? thank you!!!

See this post which has a file that modifies UAVCAN GUI with messages for OlliWā€™s devices.
https://www.rcgroups.com/forums/showpost.php?p=38470694&postcount=91

how do i set up IndicatorLED parameters at ardupilot? I canā€™t get any massage about IndicatorLED on UAVCAN GUI help~ thank you !!!