Relative Mission (translation, rotation, altitude-adaption)

Because I’m a fixed-wing rc-pilot with an addiction to sailplanes and soaring, I’m very interrested in the ArduSoar feature recently updated by Sam Tabor. In the tests therefor I missed the possibillity to place a typical soaring pattern like a lying eight or a meander against the wind - wherever I want to.
So, after looking and searching in the forum with no success, I decided to try the implementation by myself.
The result is a feature for translation, rotation and altitude-adaption of a mission for all vehicles. It’s working in my favourite minimalistic layout (for fixedwings just FC, GPS and receiver - no speed-sensor, no compass, no GCS, no SD-card necessary)

Here are some examples of cases to use:

A meander for pulling up sailplanes or rc-skydivers against the wind:

My first aim, a laying eight - looking for thermals:

Maybe the free positioning of a grit could be interresting for copters:

For my scope of rc-modelling that feature is very helpful, but because I never had an outdoor copter or a rover, I have not really an idea if and where that feature could be useful for other vehicles.

In the meantime I have further ideas that would be easy to realize, like rotation by heading or rotation by rc-channel(poti).

If you are interrested in that feature to be merged to ArduPilot - just leave a comment on GitHub here:


Thanks @Quaxwilly . That is a great feature, that was discussed sometime ago (relative missions) that has been postponed because it would make sense to leave this to scripting with Lua, although I’ve seen that on some boards that might not be a option.
I’ve tagged that feature to be discussed on the next devcall and if you can (I know the time is awful for us Europeans) be present would be great.

Thank you @LuisVale ,
Yes, there is a discrepancy between the two posibilities of direct-coding and lua-scripting.
Lua-scripting is on an upper level, where the handling of such things like mission-commands should be in the right place. No PR or Merging is necessary and everybody could change the skript according to his usecases. But unfortunately scripting is not possible in many existing FCs because they have just 1MB of flash.
On the other hand the hardcoding needs flash by itself - regardless if that feature is used or not. But it is running also on small FCs with just 1MB flash.
I really don’t know the best solution 'cause I’m not experienced in ArduPilot-coding.
Maybe a general possibility of “tailoring” of the firmware could bring a solution (like for OpenTX). But I’m afraid that would bring much work to do.
I’ll try to participate at the DevCall next week - if I’m able to hold my eyes open.

welcome to the club :slight_smile:

1 Like