ArduPilot / ArduPilot/ardupilot
Battery failsafe as percentage (rather than mAh)
- Dominant language
- C++
- Stars
- 15.9k
- Forks
- 21.4k
- Avg merge
- 4d 10h
- Merged PRs (30d)
- 127
Description
# Feature request
After discussion in the Dev call (May 13th, 2019) I'd like to propose adding two additional parameters to allow a percentage setting for battery failsafe/uncertainty.
@tridge proposed setting this up as an "battery uncertainty" parameter (which better represents the real-world issue) as explained below;
## Issue
Battery failsafe is usually setup as a function of three components;
1) The amount of battery required to perform the failsafe action (ie. RTL)
2) The uncertainty in current measurement (ie. how much battery capacity remains), and
3) The uncertainty in the "real" (or actual) battery capacity (ie. how much capacity does the battery actually have to begin with)
Currently the battery failsafe parameters allow the input of a mAh value which really only covers point 1 above (unless you specifically factor in additional mAh for points 2 and 3).
Percentage is also a much more widely used way of dealing with battery failsafes. Most people I'm aware of operating today use a percentage buffer rather than a capacity buffer.
## Proposed solution
I propose the addition of two global battery parameters;
BATT_UNC_LOW_PCT - The low battery uncertainty percentage
BATT_UNC_CRT_PCT - The critical battery uncertainty percentage
The two parameters would work by being an addition to the existing battery failsafe parameters. For example;
If
BATT_CAPACITY = 5000
BATT_LOW_MAH = 1000
BATT_UNC_LOW_PCT = 20 (ie. 20% of BATT_CAPACITY)
then
BATT_FS_LOW_ACT would occur when the battery has 2000mAh left, which is BATT_LOW_MAH + (20% of BATT_CAPACITY).
### Defaults
Both parameters would default to "0" which would ensure no change occurs for any existing users.
## Future Enhancements
@rmackay9 spoke about a future enhancement that would see the system calculate the estimated battery capacity required to RTL (https://github.com/ArduPilot/ardupilot/pull/9117). This would (in our use case for copters) make manual input to the BATT_LOW_MAH and BATT_CRT_MAH redundant by automatically changing them as the system flies. It would also work really well with the above proposed solution to ensure the aircraft lands with a minimum percentage capacity remaining (in the same way manned aircraft have a minimum fuel remaining).
There is also potential for these parameters to allow a "minimum time remaining" in the future (with the above enhancement) but I don't feel this is as accurate or appropriate as percentage remaining.
## Other Options
Another solution to this issue is to enhance the GCS UI to deal with changes to the failsafe parameters when BATT_CAPACITY is changed.
Although this does make sense, the reality is that it's difficult ensure a clean and simple UI is presented across the many different GCS options available, and it's equally as difficult to ensure customers follow (or remember) to change all relevant parameters whenever they switch between different battery sizes. The ultimate solution is obviously smart batteries but as these are not in use by the vast majority of ArduPilot users, I think the above proposed solution presents the best opportunity to ensure safety.
## Platforms
This change would be most relevant for all platforms (ie. Plane, Copter, Rover, etc.)
Contributor guide
Research direction
No source files or tests are named. Start by locating the existing BATT_LOW_MAH and BATT_CRT_MAH failsafe parameter handling across the supported vehicle platforms, then trace how defaults and thresholds are tested; done means the two percentage parameters default to zero and adjust the failsafe thresholds as described.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- embedded-iot, robotics
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100