Design considerations in Betaflight’s GPS Rescue Mode

One of the hardest things in software development is communication. It does not matter how smart you are if nobody understands why you wrote some code, what it does or why. Open source projects are usually not the best in this respect, hence this post.

When Mike Campbell and I designed GPS Rescue mode, we quickly realized that the hardest aspect about flight controller software (as opposed to, say, web development) is the testing. These days, the most popular forms of application development have automated regression tests. If you misplace a comma and break something, this becomes obvious. Not so with flight controllers. You have to flash the software onto a flying thing, charge a battery, take off and test the feature you just changed. Even if your feature works, that doesn’t mean you haven’t broken anything else (more about this later). Because of this, we set out to make GPS Rescue to do exactly one thing as simply as possibly: bring your quad back to LOS range, ideally close enough that you can land it LOS. If not, at least it would come down close to you and you wouldn’t lose it. We did not intend this feature to be a reliable DJI-style Return to Launch, because our quads are not DJI-level hardware.

Some principles:

  • when in rescue mode, the quad always points towards home.
  • if the quad moves, it moves towards home.
  • if a sensor does not increase our chances of saving a quad, we do not use it.
  • the default tuning must work well enough for typical 5″ to 7″ quads (reasonable prop/kv/motor matches).

The idea of Rescue Mode is very simple: when activated, point toward home and try to reach a certain altitude while moving slowly forwards. Once the altitude is reached, speed up and get closer to home. When close enough, descend. Easy, right? What could go wrong?

A lot of things can and did go wrong during the hundreds (thousands?) of Rescue Mode activations I did. Activating an untested change to autonomous navigation takes some faith, as well as quick reflexes. Here are some highlights:

The above happened while trying to test failsafe. Needless to say, it was not working properly yet.

Once Rescue was working fine, it made it into the release candidates for Betaflight 3.4. In late June I received multiple reports of weird behavior: GPS Rescue would send quads into infinite spins. I traced the problem to a completely unrelated change. When working on command smoothing, another developer inadvertently changed Rescue yaw to be a positive only value, so when the quad was trying to turn in the negative direction it would overflow. The result would be an infinite spin in the positive direction. The fix was just removing one character to make an unsigned value signed again.

Another aspect that caused us a fair amount of grief was altitude estimation. Most people who have used GPS know that it was not designed for accurate altitude readings. It is a geometrical issue based on how the satellites are positioned in the sky. Generally the more satellites a GPS unit sees, the better the altitude estimation; however, satellites come in and out of view, and altitude estimation suffers discontinuities. This is why it is a good idea to use other sensors to have a better view of what is happening. The obvious sensors to use on a miniquad are the barometer and accelerometer. Barometers have their own sets of issues, but when used properly (i.e. foam, correct positioning) they usually help. The accelerometer is a different story. Accelerometers using on miniquads have so much variation that we preferred to leave them out of the equation. This led to an insight about position estimation:

When using unreliable sensors, you need to know how much you can trust a given sensor. If a sensor goes bad and you trust it too much, your position estimation can go into dangerous territory.

GPS has an inherent measure of trust called Dilution of Precision. Accelerometers do not. People have suggested using all sorts of sensors or mechanisms to improve our altitude estimation (e.g. “radio pings”). These people usually have not considered that :

  • The more code you rely on (particularly written and updated by different people), the higher the changes of breaking things.
  • Every time you add a potential input to an estimate, you increase the test cases exponentially. For example, say you start using sonar and there are three types of sonar available. Now all your test cases have been multiplied by three. If the driver for Sonar 1 breaks and GPS Rescue stops breaking, it could take multiple hours of field testing to find the source of the problem.

To sum up this post in one paragraph: do not overcomplicate software. Do the simplest thing that works first. If you think you know better than the developers of an open source product, try making your own changes and testing them!



Leave a Reply

Your email address will not be published. Required fields are marked *