ros2: set bit mask in global position setpoint #54
Conversation
| using namespace mavros_msgs; | ||
| // Publishes position setpoints sequentially as trajectory setpoints | ||
| mavros_msgs::msg::GlobalPositionTarget msg; | ||
| msg.header.stamp = this->get_clock()->now(); | ||
| msg.coordinate_frame = mavros_msgs::msg::GlobalPositionTarget::FRAME_GLOBAL_REL_ALT; | ||
| msg.type_mask = 0.0; | ||
| msg.type_mask = path_mask; |
There was a problem hiding this comment.
Might be better to directly use the enums in the message definitions,
| msg.type_mask = path_mask; | |
| msg.type_mask = mavros_msgs::msg::GlobalPositionTarget::IGNORE_YAW | IGNORE_YAW_RATE; |
There was a problem hiding this comment.
Good suggestion @Jaeyoung-Lim - I need to check what happens to the highest bits in the mask using this approach - may need to update AP's handling as well to ensure a match.
There was a problem hiding this comment.
Interesting, this is part of the mavlink standard no? Or is it something special to the ardupilot dialect?
There was a problem hiding this comment.
AP does not use the POSITION_TARGET_TYPEMASK flags to construct the checks, instead uses a hardcoded unint16_t bit pattern (as was done here). Just need to check the AND logic used in the case evaluation there works as expected.
|
@srmainwaring Are there any updates regarding this? |
Sorry @Jaeyoung-Lim, got sidetracked with getting DDS integration to work for AP (it now is). Your suggestion is the right way to do this. I'll make the corresponding changes in ArduPilot, where some additional work is required in any case. |
srmainwaring
force-pushed
the
prs/pr-set-global-position-bitmask
branch
from
1dc324e
to
eb2af50
Compare
Signed-off-by: Rhys Mainwaring <rhys.mainwaring@me.com>
srmainwaring
force-pushed
the
prs/pr-set-global-position-bitmask
branch
from
eb2af50
to
05662a9
Compare
Set the
POSITION_TARGET_TYPEMASKfield in the global position setpoint. This is required by the flight controller to select the appropriate control behaviour.For example in ArduPilot Plane there is a separate handler to respond to an off-board change altitude request.
For path following we mark
lat_int,lon_int,alt,vx,vy,vz,ax,ay,azas not ignored.