SET_POSITION_HOME: Add frame for local coordinates

[hamishwillee]

This is an attempt to clarify how SET_POSITION_HOME should work, as discussed in
#898 (comment)

The (first) specific fix is to add field to specify frame for local coordinate values - since this could be any frame. [Note, the intention could be that a system has the concept of a default frame - effectively I opened this to find out what the thinking is]

Question: what should user do if they don't want to specify a local frame or global frame. Is it that if you're working in global system (ie outside) the global home will be used, and if you're working in a local system (e.g. from a VIO system) that the local system will be used - so you can and should specify both, and the irrelevant one will be ignored?

[hamishwillee]

Reposted from @julianoes

Probably only one global and one local frame will be supported at first. If this was a command you could just nack the request with UNSUPPORTED. By having this as a separate message, I'm not sure how it will work.

The global frame isn't a problem because the docs hardcode that (e.g. to WGS84).

Good point re the local frame. It almost guarantees that the assumption is that a system has only one local frame that is a "default" or they are assuming only one.

[hamishwillee]

@TSC21 @auturgy Do either of you know anything about SET_POSITION_HOME.

It doesn't appear to be supported on PX4 or ArduPilot and I can't see how it would work - in particular with respect to the local frame - what local frame is expected to mean.

[TSC21]

@hamishwillee I think that the use should just send the LLA or the XYZ. Sending the LLA is quite trivial to handle on the autopilot side. XYZ though need a reprojection depending on the current local position. So if the the home position was set at a certain LLA, if you send XYZ, then it means it needs to reproject the new home position depending the the vehicle current position.

I don't think we need a field to set up the frame, but rather make sure that if we send LLA, we use it, if we send XYZ we also use it, though requiring a reprojection. Sending both LLA and XYZ would represent an issue IMHO because the LLA we are setting may not match the XYZ we are setting since the origin is not known at hand (only the autopilot know it). I would rather make the choice between LLA and XYZ exclusive: if we set one, we can't set the other.

[hamishwillee]

@TSC21 Thanks for taking the time to reply. I'm not very familiar with frames/frame conversions, so please excuse probably stupid clarifications.

So in summary you would either specify the global or XYZ, but not both. So what needs to change is a note to that effect in the description, and also a note in each of the fields to indicate how they are marked as "invalid" - e.g. for floats NaN and for Int32 a max value. Correct?

You're also indicating we do not add a frame for XYZ.
I still don't really get "why"? Can you explain how this might be used? Generally I imagine a scenario where I'm flying around inside, with no GPS, and an existing local frame (with 0,0,0 known by the autopilot) and possibly an existing home position.
I then decide to set a new home position where I am currently. But how do I do that - I can't use LOCAL_POSITION_NED because that might have a frame that differs from what the autopilot is using. Perhaps this is not the way things work?

As an aside, where is "home" normally set for indoor flight/local? Ie normally it is set when arming/at the point that there is a good position lock - is it the same for local?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.