expose local_position_setpoint bitfield

[protobits]

This is to discuss the suggested implementation proposed in PX4/PX4-Autopilot#3004 (comment)

Current position/velocity/acceleration setpoint plugins internally set the bitfield of the set_position_target_local_ned function. Since pixhawk allows for individual control of horizontal and vertical controllers (e.g. use velocity controller for XY and position controller for Z, to hold altitude), exposing the bitfield allows for more use cases.

The difficulty I see is that this would require a custom ROS message (maybe, one that combines geometry_msgs/Accel, geometry_msgs/Twist and geometry_msgs/Pose) which is non-standard. If this is done, I would aim to keep standard individual Accel/Twist/Pose topics usable.

This is even a really general scenario. Actually, I would just be happy with, for example, extending the velocity setpoint plugin to allow for holding either XY or Z while controlling the other via velocity (e.g. set via a parameter that when either XY or Z velocity is zero, switch on position control for that axis). I can't really think of other use cases. Anyone?

[AndreasAntener]

I still see no problem with a custom message. It is a "special" interface, and ROS doesn't support that. The old topics would stay the same. If anyone wants to use the bitmask the switch to a different topic/message is easy.
But as @vooon suggested we should have a look at message filters: http://wiki.ros.org/message_filters

[vooon]

What do you thing better: expose type mask or bunch on ignore bool fields?

[AndreasAntener]

16 bools if we can find good names according to https://github.com/mavlink/mavlink/blob/master/message_definitions/v1.0/common.xml#L2325

[vooon]

For now i exposed type mask + ignore constants.

One thing that i do not like in bools - they encoded into bytes. But it is more friendly for human...

[protobits]

Why not the same 16 bit integer with constants? It is trivial to "|"
constants, and these can be defined as part of the ros message.

Just to be clear, there's nothing like this right now, is it? I mean,
should I propose a new plugin for this?

On Wed, Oct 21, 2015 at 12:43 PM, Vladimir Ermakov <notifications@github.com

wrote:

For now i exposed type mask + ignore constants.

One thing that i do not like in bools - they encoded into bytes. But it is
more friendly for human...

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

[AndreasAntener]

@v01d I think @vooon is already on it, see 37d2507

[vooon]

In addition that message can publish returning POSITION_TARGET_LOCAL_NED message.

For now i think that type_mask require less code on my side :) and less to document.

[protobits]

Ok!

On Wed, Oct 21, 2015 at 2:15 PM, Andreas Daniel Antener <
notifications@github.com> wrote:

@v01d https://github.com/v01d I think @vooon https://github.com/vooon
is already on it, see 37d2507
37d2507

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

[vooon]

Next thing: perhaps better to make new plugin (reason is same as for setpoint_position/velocity).
But i can't imagine good name :)

[protobits]

setpoint_mixed?

On Wed, Oct 21, 2015 at 3:10 PM, Vladimir Ermakov notifications@github.com
wrote:

Next thing: perhaps better to make new plugin (reason is same as for
setpoint_position/velocity).
But i can't imagine good name :)

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

[vooon]

Nope, mixed what? position+attitude? Nope, so need other name. setpoint_combined - combined what?
setpoint_position_target - little to long.

[protobits]

setpoint_multi? setpoint_custom? setpoint_mask? setpoint_cartesian?
setpoint_linear?

=)

pd: http://imgs.xkcd.com/comics/permanence.png

On Thu, Oct 22, 2015 at 6:53 PM, Vladimir Ermakov notifications@github.com
wrote:

Nope, mixed what? position+attitude? Nope, so need other name.
setpoint_combined - combined what?
setpoint_position_target - little to long.

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

[vooon]

Hmm, setpoint_raw!

[vooon]

@v01d, @AndreasAntener done, but untested.

[AndreasAntener]

Thanks a lot, I hope I can test this soon.

[vooon]

Checked with PX4 SITL. I did only looks at loopback, but topic handlers is too simple for bugs :).

[AndreasAntener]

@vooon Just did a test using position setpoints with type_mask and it works just fine :) Thanks again.

[lucastcox]

Apparently, exposing the bitfield doesn't make a bit of difference to mavlink_receiver.cpp. I was trying to use setpoint_raw to control Vx,Vz, and Pz, but it was unresponsive. The following appears to be the reason for that:

If ANY of the ignore bits are set for position, velocity, or acceleration, the ignore bool is set and the entirety of position, velocity, or accel portion is ignored. It doesn't allow picking and choosing yet. See the two code fragments below contained in the MavlinkReceiver::handle_message_set_position_target_local_ned function.

/* convert mavlink type (local, NED) to uORB offboard control struct */
        offboard_control_mode.ignore_position = (bool)(set_position_target_local_ned.type_mask & 0x7);
        offboard_control_mode.ignore_velocity = (bool)(set_position_target_local_ned.type_mask & 0x38);
        offboard_control_mode.ignore_acceleration_force = (bool)(set_position_target_local_ned.type_mask & 0x1C0);
        bool is_force_sp = (bool)(set_position_target_local_ned.type_mask & (1 << 9));
        /* yaw ignore flag mapps to ignore_attitude */
        offboard_control_mode.ignore_attitude = (bool)(set_position_target_local_ned.type_mask & 0x400);
        /* yawrate ignore flag mapps to ignore_bodyrate */
        offboard_control_mode.ignore_bodyrate = (bool)(set_position_target_local_ned.type_mask & 0x800);

A few lines farther down...

/* set the local pos values */
if (!offboard_control_mode.ignore_position) {
    pos_sp_triplet.current.position_valid = true;
    pos_sp_triplet.current.x = set_position_target_local_ned.x;
    pos_sp_triplet.current.y = set_position_target_local_ned.y;
    pos_sp_triplet.current.z = set_position_target_local_ned.z;
} else {
    pos_sp_triplet.current.position_valid = false;
}

/* set the local vel values */
if (!offboard_control_mode.ignore_velocity) {
    pos_sp_triplet.current.velocity_valid = true;
    pos_sp_triplet.current.vx = set_position_target_local_ned.vx;
    pos_sp_triplet.current.vy = set_position_target_local_ned.vy;
    pos_sp_triplet.current.vz = set_position_target_local_ned.vz;
} else {
    pos_sp_triplet.current.velocity_valid = false;
}

/* set the local acceleration values if the setpoint type is 'local pos' and none
     * of the accelerations fields is set to 'ignore' */
if (!offboard_control_mode.ignore_acceleration_force) {
    pos_sp_triplet.current.acceleration_valid = true;
    pos_sp_triplet.current.a_x = set_position_target_local_ned.afx;
    pos_sp_triplet.current.a_y = set_position_target_local_ned.afy;
    pos_sp_triplet.current.a_z = set_position_target_local_ned.afz;
    pos_sp_triplet.current.acceleration_is_force =
    is_force_sp;

} else {
    pos_sp_triplet.current.acceleration_valid = false;
}

[vooon]

@locustcox yes, and APM for example wanted only one specific combination for attitude sp.

[AndreasAntener]

on a different matter, I finally merged PX4/PX4-Autopilot#3405 to PX4. Doesn't resolve your problem though @locustcox

[mzahana]

Is this issue still tracked? I am interested to control Vx,Vy and Pz. However, I am not sure if it is fully implemented, or not? Also how to use this topic anyway? I mean how to set the type_mask to indicate vx, vy, pz?

If vx, vy, pz, is not implemented in the FCU side (PX4), then a work around is to go in Altitude mode, and control RC_IN for roll pitch to control horizontal velocity.