Dear Community,
That is major feature that deserves attention. If we also incorporate wattage consumption and wind considerations, it could make the system nearly foolproof, allowing us to utilize the full potential of the battery without any worries. During the Copter-3.5 discussions, there was mention of this feature. Although I couldn’t find any subsequent updates, I noticed that Pedals2Paddles put in substantial effort on GitHub. I’m curious to know whether this feature has been fully implemented or if there are plans for further development in the future. Looking forward to your insights!
@Pedals2Paddles @andyp1per @rmackay9
Previous discussions:
I started working on a distance based intelligent battery failsafe for copter over the weekend. Rather than triggering the failsafe at a specific MAH remaining, the failsafe is triggered dynamically based on altitude and distance from home so it is landing at a specific % remaining. This will give you more flight time when you’re in close to home, make flying further from home safer, and probably help reduce LiPo abuse.
3DR did something like this for their commercial site scan solos. This wil…
Github efforts:
ArduPilot:master ← Pedals2Paddles:batt-fs
opened 04:57PM - 08 Oct 17 UTC
This is still a work in progress since I'm sure there will be suggested changes … here for me to make. So I don't intend for this to be merged yet. I am wide open to suggestions as always.
The idea here is to calculate on an ongoing basis in flight how much energy is required to make it back home to a safe landing with a specified % battery remaining. Then use that information rather than the arbitrary `FS_BATT_MAH` value in the triggering the battery failsafe and alarms. This accomplishes a few things:
* Prevent flying too far away where you don't have battery capacity to make it home.
* Prevent battery alarms and failsafes from engaging unnecessarily soon when flying close in.
* Protect batteries from abuse by calculating a landing at a given safe % remaining
The changes in this PR are as follows (_updated per discussion about multiplier parameters_):
- **Added parameters:**
- `FS_BATT_RESERVE` specifies the % battery remaining that the operator wants the copter to be on the ground. So the operator has entered 10, the calculations will run with the goal of having the copter landed on the ground with 10% battery remaining. Valid values are 0-100, with 0 being disabled.
- `HOVER_WATT` specifies the watts required to hover. The energy required to return home is calculated in watts rather than MAH since it is consistent regardless of battery voltage and sag.
- `HOVER_WATT_LEARN` works just like the existing hover throttle parameter. When disabled, it will only use the hand entered value. When set for LEARN, it will learn the watts in flight. And when set for learn and save, it will save the learned value on disarm.
- `FS_BATT_MULT_CLM` is the multiplier for how much power is used in a climb from hover power. Default is 1.2 (20% more power than hover).
- `FS_BATT_MULT_DSC` is the multiplier for how much power is used in a descent from hover power. Default is 0.9 (10% less power than hover).
- `FS_BATT_MULT_CRS` is the multiplier for how much power is used in cruise from hover power. Default is 1.1 (10% more power than hover).
- **Learning hover watts in flight** Added to copter `attitude.cpp`. This happens under the same circumstances that the hover throttle value is learned. The wattage is calculated using amps multiplied by the _estimated resting voltage_ during level hover flight when the `HOVER_WATT_LEARN` is enabled
- **Calculating watts to return home** in `sensors.cpp`. This requires the `FS_BATT_RESERVE` and `HOVER_WATT` parameters are non-zero, and the battery monitor to be reporting valid current and voltage values. If these conditions are _not_ met, the existing behavior using `FS_BATT_MAH` takes place as usual.
- **Climb energy** is calculated at hover watts * `FS_BATT_MULT_CLM`. It looks at how high it needs to climb by comparing copter altitude and RTL altitude. This is skipped if the failsafe is not RTL.
- **Cruise energy** is calculated at hover watts * `FS_BATT_MULT_CRS`. It looks at the distance to home. This is skipped if the failsafe is not RTL.
- **Loiter energy** is calculated at hover watts. It looks at the `RTL_LOIT_TIME` parameter for the time the copter loiters before beginning it's descent.
- **Descent energy** is calculated at hover watts * `FS_BATT_MULT_DSC`. It looks at altitude to descend down to the final landing phase (10 meters)
- **Final descent energy** is calculated at hover watts, and is the final 10 meter slow descent
- **Total watts to RTL** is the sum of all of the above
- **Reserve watts** is calculated as the `FS_BATT_RESERVE` percentage of `BATT_CAPCACITY` to get reserve MAH, multiplied by _estimated resting voltage_ to get watts.
- **MAH to trigger failsafe/alarms** is the sum of RTL watts + reserve watts, then converted back to MAH by dividing by the estimated resting voltage. This MAH value is then used instead of `FS_BATT_MAH`.
2 Likes
rmackay9
April 12, 2024, 8:14am
2
Yes, we should really implement this feature. There is a lua script which does something like this that I know some Partner companies are using but we should add it as a built-in feature.
Thanks.
Thanks @rmackay9 ,
Please inform me when it’s prepared. I’d be delighted to assist you with testing and providing valuable feedback. I’ve been dedicated to this topic for quite some time and have a good understanding of how it could be developed into an excellent feature.
1 Like