Skip to content
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

Ardupilot-MAVlink battery monitor #27354

Closed

Conversation

FAIZALR
Copy link

@FAIZALR FAIZALR commented Jun 21, 2024

This commit introduces functionality to support battery monitors using the MAVLink protocol. The following changes are included:

  • Added conditional compilation for MAVLink support (#if AP_BATTERY_MAVLINK_ENABLED).
  • Defined AP_BATTERY_MAVLINK_ENABLED to default to AP_BATTERY_BACKEND_DEFAULT_ENABLED if not explicitly set.
  • Implemented handle_msg(const mavlink_message_t &msg) in AP_BattMonitor to iterate through configured instances and pass MAVLink messages to appropriate drivers.
  • Updated driver instantiation to include MAVLink type (Type::MAVLink) when configured (BATTx_MONITOR=30).

These changes enables the battery monitor to interface with MAVLink-enabled battery devices, enabling the flight controller to receive and process battery status updates via MAVLink messages. The implementation ensures compatibility and functionality when MAVLink battery monitor driver is enabled through configuration (BATTx_MONITOR=30) and tested in SITL.

mavproxy
mission_planner

FAIZALR added 2 commits June 21, 2024 23:02
- Implement handling of MAVLink message ID
MAVLINK_MSG_ID_BATTERY_STATUS.
- Allows users to connect a battery that sends its data via MAVLink to
the flight controller.
- To use the MAVLink battery monitor, set `BATTx_MONITOR=30`.
Copy link
Contributor

@khancyr khancyr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nicely done ! Thanks that looks good

void AP_BattMonitor::handle_msg(const mavlink_message_t &msg)
{

uint8_t i;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can put this in the loop, that is cpp


#ifndef AP_BATTERY_MAVLINK_ENABLED
#define AP_BATTERY_MAVLINK_ENABLED AP_BATTERY_BACKEND_DEFAULT_ENABLED
#endif
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

miss empty line at end

Copy link
Collaborator

@Hwurzburg Hwurzburg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Needs new monitor type included in parameter metadata
  • Needs this option defaulted to not be included (this is an esoteric monitor and most firmware should not pay the flash cost) and the option added to build_options.py and extract_features.py

@Hwurzburg Hwurzburg added the WikiNeeded needs wiki update label Jun 22, 2024
Copy link
Contributor

@tridge tridge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this PR has some major fundamental issues. We could be getting BATTERY_STATUS messages from another vehicle, or even from ourselves via a loopback. There is no protection against this. Using a sensor reporting msg as sensor input is inherently difficult, it also doesn't support multiple batteries.
Why do you want to do this? Can you explain the setup?
Note that you could implement exactly this functionality using lua, which can parse mavlink messages and create a battery backend

@tridge tridge removed the DevCallEU label Jun 26, 2024
@peterbarker
Copy link
Contributor

Filter based on src system to make sure it's coming from the same vehicle.

@khancyr
Copy link
Contributor

khancyr commented Jun 26, 2024

From discussion, this will need at least usage of the Battery id to filter the one we want. Use of sysid/compid to filter correctly the messages

@peterbarker
Copy link
Contributor

Ping @FAIZALR - you won't be able to reuse that mavlink message, at least.

Did you still wish to pursue this PR?

@peterbarker
Copy link
Contributor

Closing this one now. It's not a terrible concept, just can't use that message!

@peterbarker peterbarker closed this Nov 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants