Is there a way to see on mission planner or any other GCS that states “flight time remaining” with this load that is being drawn on the pack? I know DJI does this and it constantly updates depending on how much load is on the system…
Any ideas on how to implement this would be great if it doesn’t already exist.
Ryan
You have the persantage
But you could have from the mah of the battery calced the flight time. Dji has the luxury of telemetry from battery(measures how much mah got in the battery and how much got out thus knowing the actual capacity) . I really doubt that the time will be accurate with and old battery
Thanks for the response. I mean you don’t really need the telemetry from the battery, you can use the amp draw/total useful aH = how many hours flight time remaining
I think this feature could be added be very easily…
Ryan
Yes. That is what I’m telling you. But with aging batteries…could get really not precise
And according to the Smart Battery (SBS) System Protocol this is handled by the battery (RunTimeToEmpty). So you would need a battery that can send that value. Although currently even if the battery would be capable of that feature it isn’t implemented into Ardupilot (yet).
I agree with both of you. I think the aged battery issue is not my big concern at the moment, I think the bigger issue is getting the basic core functionality working first…
Which Smart Battery System Protocol and module provides that data? Is there a certain module out there that is best for telem data?
Ryan
Currently there are two Smart Batteries supported, one from Maxell and the one from the solo. But I don’t know if those batteries support the RunTimeToEmpty, and even if they would, it must be implemented into Ardupilot.
They do not report that.
The only way this works today is averaging out the mAh consumption rate compared to remaining mAh. So as with anything else related to the battery, it will only be as accurate as the mAh data to begin with. If the capacity is wrong, the time is wrong. And the mAh consumed is historically not super accurate either, so that will also throw it off.
I often struggle with this kind of point. What is worse, not having the time estimate, or having an inaccurate time estimate.
I’m using the estimator implementation I’ve described there and it does provide pretty accurate calculations for both time and distance.
But there are following restrictions: I’m always use an equal batteries, always fully charged, my fly style is always +/- the same.