Backtracking as an option for stage 2 of Failsafe

[pegurov]

Is your feature request related to a problem? Please describe

GPS Rescue is awesome, but in these scenarios it is not going to return the quad home:

1. Flying behind a tall structure, like a skyscraper. After signal loss the quad is going to gain some altitude, rotate and then try to get back to home. And crash into the structure, as it is taller than the gained altitude.
2. Flying under something, like a bridge. When trying to gain altitude, it is going to crash into the bridge.

Describe the solution you'd like

I would like to see a 'Backtracking' feature as an alternative to GPS Rescue in stage 2 of Failsafe.

I suppose it should be possible to track 'breadcrumbs' during the flight, every N milliseconds, like a combo of altitude + GPS coords. And in case of a Failsafe event try to fly backward on a path, very close to the path in 3D space, that was taken to get to the point, where Failsafe happened.

This feature would probably result in safer return path, and quick signal recovery, as the quad is going to go back to the point where we still had signal, which should be pretty close to the point, where failsafe happened.

Describe alternatives you've considered

None

Other information

I have extensive iOS development experience (10 years), I could probably try to implement this feature myself)

[ZzyzxTek]

Logging the breadcrumbs might be possible. Betaflight already does blackbox logging of GPS data, maybe that could be leveraged for this. But many FCs have limited flash (or no flash) to use for logging.

The challenge is that Betaflight does not do autonomous flight. GPS rescue is a very specialized type of autonomous flight that heads back to a single home point. This would require a more generalized waypoint flight to follow the breadcrumbs.

If waypoint flight ever does get implemented, it's a ways off in the future, there are lots of other support features needed first on the way to that. At this point, we're just getting the GPS driver more solid, and working on better compass integration.

[pegurov]

Thoughts on limited flash memory:

1. Maybe it is possible to allow this feature only when it is known that there is enough memory to do that? Is there a way to figure it out of the code, running on FC? Or just add a warning in Betaflight configurator, that this feature is only available when the FC has enough flash storage.
2. Maybe we could implement a combo of bactracking and GPS Rescue, where the craft follows breadcrumbs back for some N meters, and then goes into GPS Rescue mode. That way we would only need to store a limited amount of breadcrumbs for the last N meters. Maybe that could just be an option for GPS rescue, like a switch that enables backtracking + an input, that allows you to specify the N.

Thoughts on waypoint flight:

1. Could you please be a little more specific, as to what exactly is needed for waypoint flying? I'm guessing there needs to be some logic, that is able to get from A to B in 3D space, first in ideal conditions (no wind), and then being able to correct itself against wind. Sounds like a challenge, but totally doable.
2. I do not really see, how getting GPS drivers more solid conflicts with waypoint flying, looks like more solid GPS performance only enhances the overall quality of GPS rescue and backtracking.

As I said above, I would be willing to try and implement this myself, just need some kind of approval from the repo maintainers) I have tried to figure out the process of adding new features in the repo docs, but it is rather focused on code style and testing.

[haslinghuis]

Right now we are in feature freeze. Some requirements:

• Integration of barometer with GPS: Altitude sensor fusion (GPS+Barometer) #11958
• Improvements for compass: Improved Magnetometer / Compass Bias Estimator #12998
• Position hold: Altitude hold mode #11342
• Wind estimation. See also IMU - increase gain on large Course over ground error #12792
• Way points. Remove unused nav_mode and related from GPS code #8413
• Backtracking.

[ledvinap]

IMO only reasonable way to handle this is to port it from iNav. Either iNav already supports it, or implement it in iNav first.

[haslinghuis]

s00521-020-05097-x.pdf

[sudoTheBotFather]

Just use Inav, it handles this beautifully right now and it based for autonomous flight / advanced rescue modes.

[ctzsnooze]

Closing, we don't do this at the moment. Use iNav for this.