-
Notifications
You must be signed in to change notification settings - Fork 14.6k
Introduce battery_info uORB message for static data like the serial number #24960
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
Conversation
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: 712 byte (0.04 %)]
px4_fmu-v6x [Total VM Diff: 512 byte (0.03 %)]
Updated: 2025-06-16T17:33:18 |
This is something great to track down in Flight Review as well! |
a8622e2
to
b9dd85e
Compare
b9dd85e
to
61c4478
Compare
7d8e228
to
b20fe12
Compare
b20fe12
to
12f0de0
Compare
msg/BatteryInfo.msg
Outdated
uint64 timestamp # time since system start [us] | ||
|
||
uint8 id # Must match the id in the battery_status message for the same battery | ||
char[32] serial_number # Serial number of the battery pack in ASCII characters, 0 terminated [@invalid All bytes 0] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Metadata moved to appearing first as per your original suggestion. It makes parsing easier.
- Let's add a description
uint64 timestamp # time since system start [us] | |
uint8 id # Must match the id in the battery_status message for the same battery | |
char[32] serial_number # Serial number of the battery pack in ASCII characters, 0 terminated [@invalid All bytes 0] | |
# Battery information. | |
# | |
# Static or near-invariant battery information. | |
# Should be sent on request or streamed at low rate. | |
uint64 timestamp # [us] Time since system start. | |
uint8 id # Must match the id in the battery_status message for the same battery. | |
char[32] serial_number # [@invalid 0 All bytes] Serial number of the battery pack in ASCII characters, 0 terminated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Totally! Thanks for the exemplary input, I'll adjust👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome. Made minor change above - the format is [@invalid <value> <optional description>]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took over a version of your proposal in 9fc28fb481226b22b2a03733484d6934cef33f6b
- I left away the on request part since I'm not currently aware of any mechanism to do that.
- I left away the . after all the short descriptions(.)
12f0de0
to
e584afa
Compare
e584afa
to
d6cf5a4
Compare
It's rebased on latest |
msg/versioned/BatteryStatus.msg
Outdated
@@ -1,4 +1,4 @@ | |||
uint32 MESSAGE_VERSION = 0 | |||
uint32 MESSAGE_VERSION = 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This bump requires a translation. If you anyway want to move other fields over to the info message I would consider doing it here all in one PR to not have to do the translation multiple times.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm learning 💡 Let me check.
If you anyway want to move other fields over to the info message I would consider doing it here all in one PR
From a public interface standpoint this would make sense but I'd still like to avoid it since if I start to sort out the entire message in this pr it will:
a) take a while to finish (this one already did)
b) explode in size and be hard to review and test
I'd like to work through in iterations. I can make the next one bigger if desired.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was a big handful of boilerplate. Luckily Gemini helped me fill in the repetitive stuff... 😓
The important portion in the docs is the step by step guide here:
https://docs.px4.io/main/en/ros2/px4_ros2_msg_translation_node.html#updating-a-versioned-message
All changes are in the last two commits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MaEtUgR FMI did you find those docs understandable? It was hard to make logical and I didn't actually have to test this in anger so hoping we didn't miss anything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
docs understandable?
@hamishwillee To be honest I was in a hurry and skimmed twice to find just how I can do the translation. I couldn't follow 1:1 because the message did not have a translation before. I checked high-level what I need and took the useful example https://github.com/PX4/PX4-Autopilot/blob/main/msg/translation_node/translations/example_translation_direct_v1.h and compared it against the relatively simple https://github.com/PX4/PX4-Autopilot/blob/6b2b20bd6ecb18eb6d3380449dce1fc75f61ce2d/msg/translation_node/translations/translation_event_v1.h. The quickest for me would have been an example commit to an exclusive such change but the events one is mixed with other changes and I'm not even sure why it was done since the message looks exactly the same to me 🤔 TL;DR really good docs but on the verbous side for my particular case 😇
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TL;DR really good docs but on the verbous side for my particular case 😇
Yeah, I've noticed that I'm leaning towards comprehensive but too long docs recently. Sorry!
If you find a good commit that works as a reference in future, let me know!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And thanks for the merge of the docs!
b42e6a7
to
3c3889c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving for my part. Though I hope my docs stuff goes in first in the other PR :-)
3c3889c
to
32d5e4c
Compare
@hamishwillee Of course we merge your docs pr (#24789) first, I rebased 👍 |
32d5e4c
to
0398d13
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MESSAGE_VERSION
in the battery_status needs to be be bumped to 1.
…AVLink and drivers I'm starting the separate battery info message because no char[32] should be published and logged at high rate and we need a separate battery info message for static information as discussed.
0398d13
to
046eb10
Compare
@sfuhrer Good catch! That change was mistakenly dropped during the rebase on #24789 |
Solved Problem
When tracking battery use across multiple flights and vehicles using the serial number from flight logs I found that:
uin16_t
which is too limiting for my use case and likely also others. I found that this periodic battery DroneCAN messageand the BATTERY_INFO MAVLink message have settled on a
char[32]
.I asked in a thread about this here: Common: rename SMART_BATTERY_INFO to BATTERY_INFO and add SOH mavlink/mavlink#2070 (comment)
char[32]
type because of the wasted space. We need a low rate battery info message for all such static information.Solution
id
field match the value ofbattery_status.id
to correctly keep track across topic instances.char[32]
battery_info.serial_number
field for the unique battery identifier and adjust the upstream drivers to use it.Other static fields I plan to sort out and move to the
battery_info
message separately from this pull request.Changelog Entry
Test coverage
EDIT: I just successfully tested this latest version with a UAVCAN Tattu battery (I'll make a separate pr for the message parsing of that one):
