[WIP] common.xml: add new frame MAV_FRAME_GLOBAL_VEHICLERELATIVE_ALT

[peterbarker]

this is expected to be used to tell a vehicle to take off to 20m above current altitude.

ArduPlane already actually does this for some commands, but uses an inappropriate altitude frame.

Should also be useful for "go up 20m".

ArduPilot's PR is here: ArduPilot#358

For discussion at this point only, please. Need to make sure this is fit-for-purpose in the ArduPilot codebase :-)

[hamishwillee]

@peterbarker I think it's a great idea. @julianoes @auturgy ANy thoughts?

FYI, have converted to draft and added WIP to title to stop me trying to merge it. Move to ready for review when it is ready to merge.

[peterbarker]

This one got yelled down at ArduPilot DevCall - Randy doesn't like it.

Within the ArduPilot code Plane is using MAV_FRAME_LOCAL_OFFSET_NED (it only needs the altitude); that's a frame which moves with the vehicle, so "D" should be relative to vehicle current location. Perhaps that will have to do for now....

[hamishwillee]

What @rmackay9 is saying will of course "work" but I don't like it very much. Mostly because if you're working in global frames it isn't likely to be obvious that you need to switch to this local frame to get the desired behaviour. Also you may have to do lots of messing around to work out correct lat/lon mapping from your local frame. Doable, but harder than it needs to be.

But MAVLink doesn't invent things without an interested party who wants to implement them. So if you're not going to do this, let me know and we can close this.

[julianoes]

I'd like this one.

[rmackay9]

Yeah, sorry, I'm really not a fan of this one. I'm happy with the general idea of adding support for altitudes and Locations specified as an offset from the vehicle but we should not underestimate the amount of effort required to do that. The safety feature in AP that led to this PR doesn't really need the new altitude frame.

[hamishwillee]

Yeah, sorry, I'm really not a fan of this one. I'm happy with the general idea of adding support for altitudes and Locations specified as an offset from the vehicle but we should not underestimate the amount of effort required to do that. The safety feature in AP that led to this PR doesn't really need the new altitude frame.

Thanks @rmackay9

From my perspective this is a clear improvement on the "API definition". If we added this there would be no requirement for you to implement it - the other frame is valid, it's just nothing that anyone would ever think of when commanding a vehicle or setting a mission item.

But, we normally wouldn't do so unless there is interest from at least one flight stack to implement. Otherwise it is clutter, because there is no easy way (at least in missions) for users to know what frames are supported by a flight stack.

@peterbarker @julianoes Unless you have some intent to implement or know someone who might, we can close this?

[auturgy]

The concept is generally supported, however with no commitment to implement it should be closed.
Please re-open if I have mis-read the state of this.