Mavros: expose local_position_setpoint bitfield

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

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

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

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...

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 <[email protected]

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
https://github.com/mavlink/mavros/issues/402#issuecomment-149937951.

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

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.

Ok!

On Wed, Oct 21, 2015 at 2:15 PM, Andreas Daniel Antener <
[email protected]> wrote:

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

—
Reply to this email directly or view it on GitHub
https://github.com/mavlink/mavros/issues/402#issuecomment-149966297.

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

setpoint_mixed?

On Wed, Oct 21, 2015 at 3:10 PM, Vladimir Ermakov [email protected]
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
https://github.com/mavlink/mavros/issues/402#issuecomment-149981060.

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

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 [email protected]
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
https://github.com/mavlink/mavros/issues/402#issuecomment-150366905.

Hmm, setpoint_raw!

@v01d, @AndreasAntener done, but untested.

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

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

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

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;
}

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

on a different matter, I finally merged https://github.com/PX4/Firmware/pull/3405 to PX4. Doesn't resolve your problem though @locustcox

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.