search

dronecan / DSDL

DSDL Protocol Description files for DroneCAN
MIT License
22 stars 60 forks source link

Better Battery Messages #7

Closed dakejahl closed 1 year ago

dakejahl commented 2 years ago

An attempt to establish comprehensive messages for smart battery data. Your input is highly valued!

PetervdPerk-NXP commented 2 years ago

Any progress on this message set, or is considered to be stale?

We're looking to implement DroneCAN on our Smart BMS https://github.com/NXPHoverGames/RDDRONE-BMS772 But we're kind of lost on which message set to use.

dakejahl commented 2 years ago

I've been on an extended break from working on battery stuff, I will revisit soon :smile_cat:

I re-read thru the comments and I am going to make some further changes

hendjoshsr71 commented 2 years ago

I would suggest you might need to use both the old ones and new ones even if these were in as well?

I don't think these will get into a stable release of either ArduPilot or PX4 for a while?

I do not think there is a defined method for determining capabilities in DroneCAN?

The two old messages are: The original BatteryInfo

AP specific adds a few items that were not it the original:BatteryInfoAux

hamishwillee commented 2 years ago

@dakejahl Any timeline here? I'm interested in finalizing https://github.com/mavlink/rfcs/pull/19

dakejahl commented 2 years ago

What are lifetimes? Battery lifetimes? How measured? Sounds like something for the low rate message.

Lifetimes are a feature of the TI BMS ASICs, they act kind of like a black box recorder for certain pieces of data. Copy paste from the datasheet of the BQ34Z100. I think this can be introduced later, if at all. I'm not sure CAN is the appropriate interface to access this data... I don't think a user would look at this. The manufacturer ideally can open up their battery and get shell access or ASIC access and get this data directly.

Lifetime Max Temp
Lifetime Min Temp 
Lifetime Max Chg Current
Lifetime Max Dsg Current
Lifetime Max Pack Voltage
Lifetime Min Pack Voltage

Comments on Slot ID

I think it makes sense, but some batteries may choose to report this or not (since the specification puts the onus on the battery to detect the Slot location (see spec), and some batteries coughminecough don't follow the spec). What an autopilot does with the SlotID information should be implementation dependent, I'm not sure it even makes sense to have generic support for it in PX4 though (it's no secret all us manufacturers have custom forks of PX4 anyway). If PX4 were to try and support SlotID, we'd need parameters to enable/disable requiring Slot N, and if SlotID is a uint8_t, this gets really messy really quick.

I think you would argue that if you are using slots, then the battery id is irrelevant.

"Battery ID" was the original name for "Slot ID." There are only two "IDs" of importance

  1. The Slot ID: where the battery is physically connected on the aircraft (1, 2, 3, 4, 5, ... N number of slots)
  2. The Node ID: DroneCAN Node ID
dakejahl commented 2 years ago

I don't think these will get into a stable release of either ArduPilot or PX4 for a while?

Depends on how quickly we can agree on new definitions :joy: We intend to ship our smart battery and aircraft with these messages included in the firmware (we already fly with them).

dakejahl commented 2 years ago

@schwacff can you please make a PR into my branch with any updates/additions you see fit? ie status flags you mentioned above. Also, I added state_of_charge and slot_id to the continuous message.

hamishwillee commented 2 years ago

@dakejahl Re https://github.com/dronecan/DSDL/pull/7#issuecomment-1226513939

Lifetime battery information might or might not be of interest to MAVLink users, but since we would most likely get this via CAN we will be lead by you. If you add this, it would probably go on our low rate message: https://mavlink.io/en/messages/common.html#SMART_BATTERY_INFO

State of charge maps direct to MAVLink percent_remaining which we provide as the most important "user centric" value.

"Battery ID" was the original name for "Slot ID."

Hmmm so you're saying that we're always reporting a slot when we report battery information? The implications being that if you swap over battery for a particular purpose the high rate message should report the same slot number for the new battery and the low rate message would report the details on the new battery?

And if you're not really interested in thinking about slots you just use a random slot number and the GCS decides the new type is for "avionics" say based on the low rate message?

I still think we should start thinking about our expectations we would "like" here.

hamishwillee commented 2 years ago

A little off-track, but do we need to think about reporting or handling the "system" battery level?

To explain what I mean, a system with multiple batteries might wire them in parallel, or it might have some switch over mechanism (say). IF you get messages from both batteries how does a GCS decide whether the system is at low battery or not? It could just be emptying the first one before switch over.

There is no solution to this in MAVLink. I think PX4 simply takes the lowest percentage battery as the "canary in the mine" (not even the battery with lowest capacity). I don't think there is a battery level solution - because the battery doesn't know what it is used for. If it did, perhaps you might tell a battery it is the "primary", which would tell the GCS that the batteries discharge in sequence.

I guess the GCS or Autopilot can infer the architecture from how the batteries discharge. If you have a full battery not discharging, you might assume there is a fallover. Otherwise they are draining at the same time and the capacity can be summed.

dakejahl commented 2 years ago

I defined 0 as field not provided for slot_id. The only way we can know a battery function (avionics, power, backup, etc) is by inferring the function from the slot_id. As far as battery architecture goes, I don't know how we can determine how the batteries are connected other than inferring. The most common use case is parallel, but someone could wire them in series and someone could implement switching logic to swap in a secondary battery (only use case I can think of is for a VTOL with a higher discharge battery for hover). I'm not sure how we differentiate these tho...

In the context of CAN nodes... the battery can have parameters. We could add a battery_function field to the low rate message which could be populated by a parameter on the battery. This would require manual configuration... but it would at least give the user the ability to mark a battery as "secondary" or "backup" and then report this in the message.

edit: is there any value in knowing if it's avionics/power/backup/other? Or is it better to just know that a battery is secondary/primary? Primary meaning it's used for propulsion and should be associated with low battery warnings/failsafes.

hendjoshsr71 commented 2 years ago

I'm quite keen on getting slot IDs in though I think it might be worth for DroneCAN purposes to discuss how folks could automatically setup slot IDs per battery without setting CAN IDs.

Sometime maybe we should discuss a method for that. I've seen your 8 slot solution by reading an analog voltage which is cool for 8 slots. But thinking for things at a bigger scale...... and what a slot manager would look like on the hardware side. Such as using I2C or 1-wire 32-bit unique id chips that a battery could read.

It might be talking what the hardware side might look like sometime?

The autopilot would then know to correlate that unique slot_ID with the physical slot via a parameter setup in the SLOT_MANAGER.

hendjoshsr71 commented 2 years ago

@dakejahl if you want to add lifetime fields to the battery_info message I'm okay with that as it is low rate. And it could make it easier for manufacturers to check on systems that are being abused beyond warranties :) And we shouldn't force SSHing into an individual battery.

I would NOT add them to MAVLink.

@hamishwillee Slots must be fixed. The way I've been thinking about implementing this on hardware each slot would have a unique 32-bit ID that a battery could read. The flight control then implements the map from slot ID to physical location.

In regards to all the arming stuff at this point that would be better left up to the user, vehicle, and autopilot?

A slot being empty is very reasonable in some systems.

Numbering of slots would be nice to a have a standard. Say left to right and then top to bottom when viewing the aircraft from the front view. AKA +x-axis into the page. +Y-axis to the left and +Z-axis down?

hendjoshsr71 commented 2 years ago

"edit: is there any value in knowing if it's avionics/power/backup/other? Or is it better to just know that a battery is secondary/primary? Primary meaning it's used for propulsion and should be associated with low battery warnings/failsafes."

I think there is value is marking these especially for VTOL aircraft. There are many systems with separate batteries for VTOL vs forward flight vs. avionics/flight surfaces.

Or for a copter manufacturer I helped them setup all their vehicles models such that Battery Index 1: Main power volts / current monitoring Battery 2: Generator fuel flow monitoring (sent via battery_status because of course.... mL == mAh) battery 3 : Backup main flight battery and generator monitoring

Of course a GCS would need to do something smart with these fields.....

dakejahl commented 2 years ago

The way I've been thinking about implementing this on hardware each slot would have a unique 32-bit ID that a battery could read. The flight control then implements the map from slot ID to physical location.

Although I agree with this design approach it means redefining the "hardware interface standard" by needing to now also route one wire or i2c (instead of boot/slot_id). It also increases cost and complexity because now you have hardware you have to talk to (onewire or i2c eeprom for example).

Personally I don't care about the slot ID concept right now, but I definitely see how it is useful for other applications. I also feel like the current specification has too many details relating to the smart battery design implementation (boot pin and ID being analog voltage level defined, outlining the different battery "states" -- hotswap, flightmode, slot_id_sense etc) but I won't get into that.

Perhaps in the future a new specification can be designed which includes an eeprom over I2C to allow more than 8 slot IDs as well as allow for storing of other information that a battery might want to know about a slot. If you have an eeprom, you could just directly report that you are Battery slot number N, Node ID N, connected in Seriallel and your function is SystemBlah. No need for mapping slot number to anything on the autopilot side. But you'd need to power this eeprom... 2 more signals added. This all just adds complexity... but it might be a more robust implementation.

And we shouldn't force SSHing into an individual battery

linux on a battery?

:raised_eyebrow:

dakejahl commented 2 years ago

Ignoring the overhead of dronecan this message is 240 bits which means at 10hz it's ~2.5kbit/s, just FYI. Not bad!

hamishwillee commented 2 years ago
  1. There was a comment in there somewhere about debug information. I am against debug info in "core" messages. We could stuff this into the cell voltages message - in MAVLink at least BATTERY_CELL_VOLTAGES could be renamed BATTERY_DEBUG.

@hendjoshsr71 I am happy enough with the concept of slots. To me a slot is something that holds a battery and is used to provide persistent information about the function and warning levels.

Right now we have arbitrarily number batteries and as they get added and removed they can move about. That makes it hard to manage them in a GCS in a sensible way.

I think it is good to know if a slots is primary because it tells me that batteries are used one after each other rather than in parallel. Essentially it's a way to say whether the warnings matter if you have multiple batteries that serve the same function and one of them is low.

I am not sure about what information we need.

Sorry if I'm rambling. End of day. Beginning of public holiday.

PetervdPerk-NXP commented 1 year ago

@tridge Any thoughts on this updated DroneCAN BMS message set PR? It's open for quite a while now and I kinda hoped DroneCAN would've picked up where UAVCAN stopped. But if the strategy of DroneCAN is just going to be UAVCAN with CAN FD support with the same limited message set that would be nice to know.

tridge commented 1 year ago

@PetervdPerk-NXP I've been leaving @hendjoshsr71 to handle this as he has been looking at it much more closely. I'm happy to merge this when @hendjoshsr71 is happy with the new messages

dk7xe commented 1 year ago

@dakejahl can we move the full_charge_capacity to the periodic message?

@hendjoshsr71 since the request was processed. When can we expect this being merged?

bperseghetti commented 1 year ago

@tridge since @dakejahl made @hendjoshsr71 requested changes in a6de4814f1c552d4ab999eaf3ec294cebdec5a1c is this all good to be squashed and merged?

hendjoshsr71 commented 1 year ago

I can't squash the commits on this repo. If you could do that I can approve it.

dakejahl commented 1 year ago

Why don't we just merge-squash? Then it would preserve the history of the branch, maybe there's some value to that? :shrug:

dakejahl commented 1 year ago

Ehh branch will be deleted anyway. Okay I'll squash and push :laughing:

hendjoshsr71 commented 1 year ago

I have no idea of the convention in DroneCAN DSDL ? I'm just used to the commits being clean when it goes into a main branch.

If someone wants the history see GITHub for actual discussion?

dakejahl commented 1 year ago

The admin who has merge authority has a "squash and merge" option when they hit the merge button. Idk sometimes I don't trust myself to manually squash, if you make a mistake and force push you can really screw yourself. Anyway I did it and it looks like I didn't screw it up this time. Almost one year later! Congrats everybody! :laughing: :rocket:

tridge commented 1 year ago

@dakejahl thanks for all your work on this, and your patience!

dk7xe commented 1 year ago

Thank you guys for your support getting this message implemented. Ihave just done the first test of the droneCAN implementation on our BMS772 battery management system together with an S32K3 running PX4 grafik