Hi,
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?
Thank you
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.
Here is my simple version of estimator that I’m using for Copter.
All it does is continuously calculate and report thee things:
How long I can fly (in minutes) with current power consumption till my battery fully dry out
How long I can fly with the current heading and current power consumption till I reach the point-of-no-return, so my remaining energy in only for RTH.
How far I can fly forward (in meters) with current heading and current power consumption till I reach the point-of-no-return, so my remaining energy in only for RTH.
So far I’ve tested that in SITL and in few real flights, and it makes accurate estimation.
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.
No, first I want to do more long-range real test flights to see how it is usable as is.
So far I did just 2 or 3 flights so still not sure if I need to change something or it is already good.
