Distinguish between origin and home

[jlecoeur]

The origin of the NED frame is now the same as home ie. home is always at location (0,0,0). The issue is that whenever we change the location of the home waypoint, we also move the origin of the NED frame, and any position given in NED frame may not be relevant anymore.

We should clearly separate origin from home.

• the origin should be fixed. It can come from a config, and/or initialized at first GPS fix. However if it is initialized at first GPS fix, we should take care of all the locations already stored in NED frame.
• the home location may be changed via mavlink commands. See Mavlink_waypoint_handler::set_home

[GregoireH]

I know that origin should be common to all MAVs in case of swarming application.
It ease a lot the log analysis.

To answer your 1st remark:
We store waypoints in their own frame,
Then, while taking off we init the navigation plan which do convert them on the fly, only when the current waypoint become that waypoint. So it should not be a pb !
@jlecoeur do you agree ?

For the second remark, I don't really see what the home would be used for, except for going back home in case of failure.
is that what you thought it should be used for ?

[jlecoeur]

1st remark: I take as example the change you proposed in #279. With this, the landing position will be set to the current NED location when we start the auto-landing (ex [10, 10, 0]). Then imagine that the origin is changed during landing... The estimated position will change very quickly, and the drone which was flying around [10, 10, -5] is now thinking it is flying at [58, 32, -5]. The landing waypoint is not updated (still [10, 10, 0]) so the drone will go and land somewhere else (48 meters south, 22 meters west) !

2nd remark: yes it can be used to go back home. And it is useful to change the home location via a mavlink command.

[basil-huber]

Home and origin are separated in Mission_handler PR #331 . The question is now how and when to set the origin as well as the Home position.

Since I have a semester student working on it, I would like to decide asap how we handle origin and home.

I would say the main question is how do we interpret local coordinates?
a) As relative coordinates: Points with respect to the drone's initial position
(e.g. fly a rectangle around the take off position)
b) As a custom coordinate frame, such as the drone dome coordinate frame
(e.g. fly a rectangle in the drone dome)

Current implementation

Currently, in the master branch, we set the origin upon first receiving GPS fix and on arming. This has two major drawbacks:

• The position estimation has spikes just before takeoff due to change of origin
• Relative waypoint mission move if the quad is disarmed during the mission

In Mission_handler PR #331, the origin does not move on arming anymore. (only on first GPS fix). This means:

• Relative waypoints will not move when disarming, but when restarting the autopilot (e.g. changing batteries). This might be a problem in the drone dome when missions are defined in local frame and the quad is booting at different locations.

A solution

On startup, set origin as specified in config
On first GPS fix

if origin and current location are close enough  to avoid overflow of local position
    keep current origin
else if not armed:
    set current location as origin
else:
    set gps.healthy(GLOBAL) to false to avoid autonomous modes

The main disadvantage in my eyes is the altitude:
Local_position altitude equals not necessarily the altitude above ground, since the origin is not set at arming.

Since Kalman position estimation PR #332 will introduce estimation of the ground altitude (afaik), we could interpret local z - coordinates as above ground. Or interpret it as height above origin, but interpret GLOBAL_REL_ALT as above ground.

What do you think?