-
-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DSDL Suggestion: GenericBatteryInfo #33
Comments
If I understand the intention correctly, the model_instance_id (together with model name) is a sort of GUID, While battery_id is some sort of UUID.
Would you mind to elaborate a bit on this? Are you using one or several batteries at the same time? If you're using several batteries are you not required to identify them in the system? If you're using a single battery wouldn't it be practical to set battery_id to the same constant (e.g. 0) for all of them? You should then be able to swap them without having to reconfigure anything. You could still identify them by using model_instance_id. |
|
I was thinking that my writing was sufficiently clear, but obviously not LOL. @ kjetilkjeka: however: I also think that a "hardwired" id is not very convenient setup-wise. For instance, the current ArduCopter code (or a PR to that) requires the user to set the id explicitly. That is, a user has to set the id in the UAVCAN node correctly as well as in the flight controller firmware. I don't see any real need for that, it could autodetect the ids. And if we are at that point, to accept an autodetect, then there is really no reason for not relaxing the definition to "It should be unique within each system, of course, but otherwise the user may assign it as she/he wants.", and to be friendly to her/him and give her/him a sufficiently large range of values. I just think it should work similar as for smart batteries. @ pavel: btw: a similar line of reasoning does, IMHO, apply also to CircuitStatus. Interestingly, it's id is uint16. I would be surprised to hear that this is so because one realistically expects to have more than 256 such circuits in the system. btwII: Maybe one should extend GenericBatteryInfo by a variable field at the end holding the individual cell voltages. Also, the status field needs discussion. E.g. UNDERVOLTAGE, is this supposed to indicate a malfunction, or that a voltage fell below a certain level in the sense of a lipo-saver function? Should one have two flags for each situation? |
Ok, i undestand now. You're talking about the situation where you use several batteries but there is no need to identify them within the system. Thanks for clarifying.
This seems reasonable. I can't see any reason to disallow components in a system to not care about the battery ID. Would this remove the need for the new message type?
I guess this is needed in a setup where you're using multiple batteries with a need to identify them in the system. |
The problem is in the specification (sigh). I'm going to add this to the list of things to explain clearer.
I.e. in a single-battery scenario, the ID must be zero always. Taking an aircraft for example equipped with a battery on either side (just for the sake of an example, you understand), the left battery would be designated 0, the right one would be 1. It doesn't matter which particular battery is installed in the right and left slots. Normally, batteries are not equipped with CAN bus interface due to unreasonable costs involved. CAN is expensive and poorly suited for expendable entities such as batteries. There is already an existing standard in place for smart battery interfaces based on I2C, it works well, and I see no reason to replace it with anything else so far. However, if somebody chose to equip their batteries with CAN, "fumbling around with the ID's" would be unavoidable. |
Regarding the cell voltages, I'm not sure why that would be useful, as well as I don't see any value in reporting the amount of used energy only. The autopilot or any other external entity would mostly care about higher-level concepts related to the battery: its state of charge, its state of health, time-to-discharge, et cetera. Normally, in an idealistic scenario, no other node in the system should care about low-level parameters such as mAh or cell voltages, because they cannot be sensibly interpreted without a sizeable amount of context (such as the type of the battery, its capacity, and so on). The proposition to just throw in another message for voltages and mAh sounds like an attempt to design a better I2C rather than a proper data bus. |
I'm sorry, I really give up now with suggestions on DSDL :) |
There is auto id numbering being requested. In such case it will not work at all.
Wh is actually much more usefull. The motors really do consume current but for propulsion the power is much more meaningfull parameter. So the remaining power is what to be considered and not only mAh. That is really practical side. |
I suggest adding this message to the standard
uavcan.equipment.power.GenericBatteryInfo
id = 1093
Here, battery_id should not match battery_id of the BatteryInfo message. That is, every battery should have it's own, unique battery_id, but every battery is free to decide which message, GenericBatteryInfo or BatteryInfo, it wants to emit (or both).
Reasons for that additional message: 13th post here ArduPilot/ardupilot#6527
In principle, I would think that the existing BatteryInfo message could need a revision. First, I think it would be better named SmartBatteryInfo. Also, I think the suggested use of battery_id isn't suitable. It should be unique within each system, of course, but otherwise the user may assign it as she/he wants. That is, she/he may number ALL her/his batteries once and for all, more along the lines of a GUID. Anything else would not be very practical. E.g., if the primary battery would have to have battery_id = 0, as currently suggested, every change of a battery would need fumbling around with the id's. How nasty. In that light, a range of unit8 for battery_id might be quite narrow.
The text was updated successfully, but these errors were encountered: