Recently I’ve been going through the Ardupilot codebase and I thought of expanding the AP_BattMonitor class to include a sort of runtime estimator, taking into account the overall energy consumption of all active elements (eventually adding external current sensors for finer inputs) and predicting the battery duration at the current speed.
It can be useful especially for rovers and boats on long-run missions to determine motor speed and adjust velocity according to the remaining runtime. Ideally implemented with state machine containing various power-level statuses to adopt in order to extend mission time to the battery limits.
Do you think it can practically work on the limited PixHawk hardware? Or is it more suited for a companion computer?
This is defiantly possible on board. There is a existing watt and current limit in the codes, i think your suggesting to change the watt/current limit depending on the state of the battery. A range remaining value based on a average power draw would be a useful feature. Could trigger a warning when the remaining range becomes less than the RTL distance. Makes sense for rover some thought will have to be put into into how to do it for plane and copter, you may well want to over discharge the battery in order to prevent a crash.
…change the watt/current limit depending on the state of the battery…
Yes ideally change both current limits and motor speed, at least for rovers and boats.
Now looking at the AP_BattMonitor_Backend method uint8_t capacity_remaining_pct() it seems for predicting the runtime a linear model is used, which noticeably yields inaccurate results for Li-ion technology.
A nice implementation of a sensing algorithm can be found in this repository which employs a symmetric or asymmetric sigmoidal function to determine battery percentage.
I would say to change the aforementioned method to allow using more accurate fitting functions, eventually leaving the user control over sigmoid coefficients via parameters.
It seems a nice idea yet first I would update the battery discharge model to employ a more realistic model for LiPo.
Why didn’t you use the capacity_remaining_pct() function to get the remaining battery charge?
Because this function is based on mah consumption that is not very good because a result is non-linear.
Calculating by using Watts and Watt-hours is linear instead.
But, need to say that in practice the difference between both methods is not so large.
Flying with constant speed in Loiter in a windy condition results in a floating power consumption. So the estimated remaining distance also floating like 15km-10km-8km-13km… I have an idea to mix the instant power consumption with a predefined (or calculated) “normal” power consumption to get some smoothed consumption and avoid large floating of estimation.