Copter: support SET_ATTITUDE_TARGET in guided mode

[rmackay9]

This adds support for the SET_ATTITUDE_TARGET mavlink message while in guided mode.
http://mavlink.org/messages/common#SET_ATTITUDE_TARGET

The caller must provide a quaternion (4 floats) to specify the attitude and a thrust value which is between 0 ~ 1.0.

Some small items to note:

• I've interpreted the thrust value so that 0.0 will make the vehicle descend at the WPNAV_SPEED_DN speed, 0.5 will cause the vehicle to maintain it's current altitude, 1.0 will cause it to climb at it's WPNAV_SPEED_UP value.
• I haven't implemented processing of the type_mask field. Technically we should check that the last two bits are set before processing the quaternion and thrust vector. I probably should.

I've tested this using this MAVProxy change: ArduPilot/MAVProxy#208

[vooon]

You should implement type_mask handling. Else you violate message spec.

// mavros e.g. uses two messages: one for attitude and other for thrust.

[rmackay9]

@vooon, yeah ok. I've implemented a check so we don't process the message unless both the thrust and attitude are set. I know ideally we should allowing setting just one or the other but I think I'll wait until someone actually tries to use the message. Sometimes we implement things and nobody uses them.

Merged (with changes)

[m4gr3d]

@rmackay9 it might be more intuitive if the thrust value is in the [-1.0, 1.0] range, with 0 meaning to maintain altitude.

[m4gr3d]

@rmackay9 the pos vel timeout seems high at 3 seconds. Any reason for this value?

[squilter]

@rmackay9 There's a capability bit to switch now called MAV_PROTOCOL_CAPABILITY_SET_ATTITUDE_TARGET

@ne0fhyk The range is like that because it's defined in the mavlink spec. -1 is meant for vehicles that can reverse thrust.

Also, the 3 second timeout is like that to be consistent (because the velocity controller times out at 3 seconds). But I think you're right that 3 seconds is too much. For velocity, 3 seconds is okay, but with attitude I think it should be like 0.5 seconds.

[rmackay9]

@ne0fhyk, @squilter, sure, np. I'll reduce the time-out for the attitude controller and set the capabilities bit! thanks for the checks and input!

[rmackay9]

@ne0fhyk, @squilter, @vooon, Ok, I think the fixes are in master. Hopefully I got it right this time, Txs again.

[chataign]

Hi, I tried to use this functionality to control both vehicle position and attitude (yaw). I was publishing both position and attitude setpoints from mavros, but I was getting very erroneous control. I can provide details/snapshots if needed.

To get things working I tried using set_auto_yaw_look_at_heading() from ArduCopter instead, and it works perfectly. I made a small change to read the yaw field from the position setpoints, and I call copter.set_auto_yaw_look_at_heading(yaw...).

I'm very new to ArduCopter so I might be doing something stupid, but I'm not sure why this mode works and angle controller described above didn't?

Thanks!
Francois

I basically just added this to case MAVLINK_MSG_ID_SET_POSITION_TARGET_LOCAL_NED in GCS_MAVLINK::handleMessage()

if (!yaw_ignore)
{
    // param1 : target angle [0-360]
    // param2 : speed during change [deg per second]
    // param3 : direction (-1:ccw, +1:cw)
    // param4 : relative offset (1) or absolute angle (0)
    uint8_t direction_clockwise = 1, angle_absolute = 0;
    copter.set_auto_yaw_look_at_heading( wrap_360( degrees(packet.yaw) ), packet.yaw_rate, 
        direction_clockwise, angle_absolute );
}

I forgot to say: to test this I'm using the ardupilot SITL (sim_vehicle.sh with ArduCopter)

[rmackay9]

@chataign, looks like we're talking about two different messages. One is the SET_POSITION_TARGET and the other is SET_ATTITUDE_TARGET. It's probably best if we stick to a single issue at a time or at least separate them into separate discussions and instead of discussing it here on a closed issue, feel free to email drones-discuss@googlegroups.com

[chataign]

Hi Randy,

I posted a question about this on the drones-discuss forum as you
suggested, but it's been a few weeks and I've had no responses...

https://groups.google.com/forum/#!topic/drones-discuss/cB_f5bJ0im8

I'm a bit confused because what I'm trying to do is quite standard (issue a
pose+heading request) so I suspect I'm doing something wrong here. Do you
know where I could get more help/support on this issue?

Thank you!
Francois

On 23 October 2015 at 12:31, Randy Mackay notifications@github.com wrote:

@chataign https://github.com/chataign, looks like we're talking about
two different messages. One is the SET_POSITION_TARGET and the other is
SET_ATTITUDE_TARGET. It's probably best if we stick to a single issue at a
time or at least separate them into separate discussions and instead of
discussing it here on a closed issue, feel free to email
drones-discuss@googlegroups.com

—
Reply to this email directly or view it on GitHub
#2959 (comment).

[rmackay9]

@chataign,
sorry, missed your email but I've replied now.
I think your solution posted above is the right way to go, so we should pull that into master.
thanks!

[damanfb]

I have two questions for the SET_ATTITUDE_TARGET. I'm using Mavros so it looks like I need to publish the topic setpoint_raw/attitude. My first question, can I mix which values are rates and orientations? I would like to control roll and pitch angles, yaw rate, and thrust. My second question, is to use these setpoints the APM needs to be in the Guided mode, but I'm operating indoors with no GPS. Is it an option to disable the GPS prearm check or what other options do I have?

[squilter]

@damanfb To answer the second question, no that problem isn't fixed yet. See #2790

[tizianofiorenzani]

Is there any update on that issue? Setting attitude reference in GUIDED mode would be of great help in indoor experiment. Is there any way around it? Rather then overriding the RC channels (very dangerous)