Rotorcraft guided mode

[flixr]

Meant for controlling the rotorcraft via external input (e.g. POSITION_TARGET_LOCAL_NED datalink message)

• currently position mode only
• could be extended with velocity, relative position, etc.

Could also be used for mavlink:
http://mavlink.org/messages/common#SET_POSITION_TARGET_LOCAL_NED

[flixr]

So currently you can "goto" a position and specify a frame in flags (first 4 bits):

• 0x0: LOCAL_NED, position in local NED frame
• 0x1: LOCAL_OFFSET_NED, position relative to where the vehicle currently is in NED
• 0x2: BODY_NED, same as LOCAL_NED for position
• 0x3: BODY_OFFSET_NED, position relative to vehicle pos AND heading (so X=forward, Y=right, Z=down)

Should we add velocity to this message as well? Either specify in the flags that some/all fields now are interpreted as velocity or add additional velocity fields?
Or make a separate velocity message?
We don't have a dedicated velocity guidance mode yet, but it would be good to already consider how the message/s will look like.

Feedback on naming, what fields we want to have in the message, etc. welcome.

[flixr]

Also do we want an RC_THRUST_LIMIT in GUIDED mode?
Currently that would be the case, but probably in most case you don't want that?

[rmeertens]

As for my wish for a velocity mode:
We can copy paste the guidance optic flow PI controller, and rewrite this function:
static void stabilization_opticflow_vel_cb(uint8_t sender_id attribute((unused)),
uint32_t stamp, float vel_x, float vel_y, float vel_z, float noise)

[flixr]

@gautierhattenberger @dewagter what do you think of this?

Are the autopilot_guided_goto_x functions a good API?
Those are right now called upon receiving a POSITION_TARGET_LOCAL_NED message and check if you are already in GUIDED mode.
They could also be called from a module...

[flixr]

I don't think I'll have time to implement the velocity mode before v5.8, but the messages is meant to allow for that as well...

[gautierhattenberger]

This is indeed really useful. As long as we can add more input types later I guess it is fine. I don't have a strong opinion on the API right now, hard to tell without actually using it. The only thing I can see is that choosing a name really close the the mavlink name might be confusing if we start using both message system. But it is probably not a big deal...

[hooperfly]

I am working on an outdoor multi-MAV light display for an event in February. This might be a very useful feature/capability for that application. I will try and give it a go in the next few weeks.

[flixr]

@gautierhattenberger any ideas on a good message name then?
Maybe something like GUIDED_SETPOINT_NED?

[gautierhattenberger]

maybe GUIDED_SETPOINT_NED is a bit better since we can at least reuse the message for velocity with a flag byte

[flixr]

Jep.
Also is the prefixing of the message name with DL_ for the ground message ok?
That is how it's done for e.g. SETTINGS, but it might be a bit confusing, since the define created for the datalink message id is also DL_<message_name>...

[gautierhattenberger]

An option to avoid duplicating messages is to use the RAW_DATALINK ground message to embed a datalink message

[flixr]

So should we do this via a dedicated ground message, RAW_DATALINK or even directly send the datalink message on the ivy bus?
The only reason not to send the datalink message directly is that it won't be logged by the server then, right?

[flixr]

Ok, renamed message to GUIDED_SETPOINT_NED and use RAW_DATALINK to send the message from the python script so server will log it....
Anything else to do here before we can merge it?

[gautierhattenberger]

I'm fine with this