moveit / moveit_msgs

ROS messages used by MoveIt

MoveIt Msgs

This package includes the ROS messages specific to MoveIt

GitHub Actions - Continuous Integration

moveit_msgs's Issues

Add LICENSE file

This repo should have a BSD license file.

Kinetic initial release

Done ros/rosdistro#12374

Once the deb files of this package getｓ ready in shadow-fixed repository, we'll be able to bloom https://github.com/ros-planning/moveit into Kinetic.

Any plan for the noetic release

Hi,

It seems this repository hasn't been released for the noetic version yet.
Any concrete plans for it?

Ryan

Divergence of MotionPlanRequest.msg between ROS 1 and 2 Versions

Stumbled across a breaking change between versions of msg/MotionPlanRequest.msg while building a ROS Bridge. Reading through Issues/PR's it looks like there's an intentional history. Adding this issue to highlight the difference.

Brief History:

#113, message field was added, but wrong name used.
#122, attempts to correct field names.
#130, rewrite of 122, successfully merged into master.

All ROS 2 versions appear to be 9 commits behind, critically f562cc8

I'm unfamiliar with the ROS 2 moveit ecosystem to say the appropriateness of whether it's okay for these to match. At this time, users attempting to bridge MoveIt messages are unable to do so without modifying one side or the other. Given ROS Noetic is around until 2025, it may be useful to have them match.

Release moveit_msgs (Indigo 0.7.5, Kinetic 0.9.x)

My local build broke because I was only using moveit_msgs from shadow-fixed, which is missing 4eb711c

@130s thanks!

Unclear how to define a PositionConstraint msg

I am trying to define a Position Constraint msg in the following way:

moveit_msgs::PositionConstraint position_constraint;
position_constraint.header.frame_id = "world";
position_constraint.link_name = group_->getEndEffectorLink();
position_constraint.target_point_offset.x = 0.01;
position_constraint.target_point_offset.y = 0.01;
position_constraint.target_point_offset.z = 0.01;
shape_msgs::SolidPrimitive bounding_region;
bounding_region.type = bounding_region.SPHERE;
bounding_region.dimensions.resize(1);
bounding_region.dimensions[0] = 2000;
position_constraint.constraint_region.primitives.push_back(bounding_region);
position_constraint.constraint_region.primitive_poses.push_back(target_pose_);
position_constraint.weight = 1;
planning_constraints.position_constraints.push_back(position_constraint);

However, upon execution I get the following error:
Exception caught executing *final* adapter 'Fix Start State Path Constraints': Bounds for real vector space seem to be incorrect (lower bound must be stricly less than upper bound). Sampling will not be possible

Given that it is not possible for my end-effector to be outside of such a large bounding region, I was wondering whether I am doing something wrong in the constraint definition or there is a bug somewhere.

MINOR: Typo in msg/MoveItErrorCodes.msg

int32 UNABLE_TO_AQUIRE_SENSOR_DATA=-5 should be ACQUIRE.

I'm not sure if there's any issues in changing it, maybe adding an additional const value with the corrected spelling would work?

moveit_msgs/msg/MoveItErrorCodes.msg

Line 11 in 9756797

int32 UNABLE_TO_AQUIRE_SENSOR_DATA=-5

CollisionObjects don't collide with environment after attaching to robot

Hi community

I am attempting to use the addCollisionObject function to incorporate a tool-changing functionality, mostly following the MoveIt!-tutorial (https://ros-planning.github.io/moveit_tutorials/doc/move_group_interface/move_group_interface_tutorial.html). Loading the mesh of the tool or primitives is not an issue as they appear in the planning scene as expected. When attaching the object of the tool to the robot to use it for collision checking with the environment however, collision with the tool-object is not considered by MoveIt!.

code:

    //Setup movegroup interface
    moveit::planning_interface::MoveGroupInterface move_group("manipulator");

    //Setup planning scene interface to add and remove collision objects in the scene
    moveit::planning_interface::PlanningSceneInterface planning_scene_interface;

    //Collision object
    moveit_msgs::CollisionObject gripper;
    gripper.header.frame_id = "tool0";
    moveit_msgs::CollisionObject block;
    block.header.frame_id = "map";
    //Identifier
    gripper.id = "gripper";
    block.id = "block";
    //Define object 
    shapes::Mesh* mesh = shapes::createMeshFromResource("FILEPATH", {0.001, 0.001, 0.001});
    shape_msgs::Mesh gripper_mesh;
    shapes::ShapeMsg mesh_msg;
    shapes::constructMsgFromShape(mesh, mesh_msg);
    gripper_mesh = boost::get<shape_msgs::Mesh>(mesh_msg);

    shape_msgs::SolidPrimitive primitive;
    primitive.type = primitive.BOX;
    primitive.dimensions.resize(3);
    primitive.dimensions[primitive.BOX_X] = 0.1;
    primitive.dimensions[primitive.BOX_Y] = 1.5;
    primitive.dimensions[primitive.BOX_Z] = 0.5;

    //Give a pose
    geometry_msgs::Pose gripper_pose;
    gripper_pose.position.x = 0.0;
    gripper_pose.position.y = 0.0;
    gripper_pose.position.z = 0.1;
    gripper_pose.orientation.x = 0.7071068;
    gripper_pose.orientation.y = 0.0;
    gripper_pose.orientation.z = 0.0;
    gripper_pose.orientation.w = 0.7071068;

    geometry_msgs::Pose box_pose;
    box_pose.orientation.w = 1.0;
    box_pose.position.x = 0.5;
    box_pose.position.y = 0.0;
    box_pose.position.z = 0.25;

    //Put in collision object
    block.primitives.push_back(primitive);
    block.primitive_poses.push_back(box_pose);
    gripper.meshes.push_back(gripper_mesh);
    gripper.mesh_poses.push_back(gripper_pose);
    gripper.operation = gripper.ADD;
    block.operation = block.ADD;

    std::vector<moveit_msgs::CollisionObject> collision_objects;
    collision_objects.push_back(gripper);
    collision_objects.push_back(block);

    //Add it to the scene
    planning_scene_interface.applyCollisionObjects(collision_objects);
    //Attach to robot
    move_group.attachObject(gripper.id, "tool0");

Does anyone know if I am missing something or what I might be doing wrong?
Thanks!
Ivo

remove GetConstraintAwarePositionIK.srv

It does not make sense to me to have two almost identical services. I have added a flag for collision checking and a Constraints message to the regular IK request (this costs just a few bytes (i believe 8 bytes) in the request) and an if statement in the implementation. It makes life easier for implementing things and also to call things.
The only code that uses that service is kinematics_constraint_aware

ExecuteKnownTrajectory not present in humble branch

Hi, the file srv/ExecuteKnownTrajectory.srv does not seem to be present in the branch humble but move_group package in moveit2 repo has this capability that requires it moveit_ros/move_group/src/default_capabilities/execute_trajectory_service_capability.cpp

I was not sure if this intentional or just missing

OrientationConstraint axis-angle error tolerances interpreted as roll, pitch and yaw angles.

The OrientationConstraint.msg allows you to specify axis-angle error tolerance:

# optional axis-angle error tolerances specified
float64 absolute_x_axis_tolerance
float64 absolute_y_axis_tolerance
float64 absolute_z_axis_tolerance

I think this comment can be misleading, as the values are used with roll, pitch and yaw angles in the code that checks these constraints.

Or is there other code that I missed?

But: the TrajOpt planner uses angle-axis error, but does not support tolerance bounds, only weights for specific error terms. But it could be extended in the future, and then the tolerance values mentioned above can have multiple uses. (Orientation error is not yet implemented in the MoveIt version of TrajOpt.)

ros2 branches

Before we merge anything in here we should make branches for the released version of moveit_msgs for both foxy and galactic. I propose we also change the ros2 branch to main and make it the default branch targeting rolling.

Target offset field in position constraint msg

I was wondering what is the purpose of this field. The Position Constraint msg defines a region and a link of the robot that should remain inside this region. So, there is no target position involved, is there?

Release moveit_msgs (I 0.7.2, J 0.8.1)

@mikeferguson @IanTheEngineer @130s Can we do a release of moveit_msgs in indigo for this new feature?

TrajectoryConstraints message needs better documentation

The TrajectoryConstraints message, and the trajectory_constraints field in the MotionPlanRequest message need better documentation. I was unsure about how it is different from path_constraints, why it has an array of constraints within it, and what a motion planner should be doing with such constraints.

MotionPlanRequest reference_trajectories confusion / redundancy

I’m confused by the new field reference_trajectories in a MotionPlanRequest, as introduces in #46.

It seems that there is some redundancy in that we can specify a list of a lists of trajectories

In the MotionPlanRequest, we have the field: GenericTrajectory[] reference_trajectories

A generic trajectory allows for both joint or Cartesian trajectories, the latter in the field:
moveit_msgs/CartesianTrajectory[] cartesian_trajectory
(a better name for this field would be cartesian_trajectories maybe?)

Going furter down, a CartesianTrajectory has a field:

• CartesianTrajectoryPoint[] points
• wich has a field CartesianPoint point
• which has a field geometry_msgs/Pose pose (the thing I’m interested in).

Am I understanding this correctly? I'm not sure if I even followed my own explanation, it is just turtles all the way down...

remove GetKinematicSolverInfo.srv

It is only used by pr2_arm_kinematics and nobody calls it. With the new plugin API for kinematics, this is not needed and causes confusion.

Enable pull request testing by ROS buildfarm

Can any admin of this repo help to enable the pull request testing by only a few clicks? Please follow this instruction ("Recommended" section).

Other chores is already taken care of (e.g. in ros/rosdistro#14529).
Once it's done, then pull request testing powered-by ROS buildfarm will become available.

PositionIKRequest has no member named attempts

Hello there,

I am trying to get a workspace that was written for melodic running on noetic. I've encountered the following error:

error: ‘moveit_msgs::PositionIKRequest’ {aka ‘struct moveit_msgs::PositionIKRequest_<std::allocator<void> >’} has no member named ‘attempts’

Apparently, 82cda0e removed that field.
Why?

Not clear if `orientation_constraint.absolute_x_axis_tolerance` is +/- or total tolerance

For example, is this:

orientation_constraint.absolute_x_axis_tolerance = 0.4;

+/- 0.4 rad?
Or +/- 0.2 rad?

ROS2: moveit_msgs takes a long time to re-build

After already having built moveit_msgs with ament, I still find it takes a minute or so to rebuild moveit_msgs in ROS 2. Has anyone else seen this issue?

May 2020 Melodic Release

I copied this from what I put in the moveit release issue. I don't think we need nearly as much time to push this out and I'm unsure if all these steps are necessary. Please let me know if we can drop any of them. I would like to push this out quickly though because jog_arm depends on the changes I just got back-ported here.

Timeline

1. May 7 - Create Issue to decide on issues
2. May 10 - Issues picked and PR(s) for backports created (jog_arm and other fixes)
3. May 11 - Backport PR(s) merged, Code freeze of melodic-devel
4. May 13 - Create shadow repo for testing and post on discord
5. May 15 - Run bloom

Backport Discussion

Here are the changes in master that are not in melodic-devel and the one I merged. LMK if any of these should be backported, and if I'm missing any that are merged but not yet in a release so we can put them in the release notes. Anything that changes API of an existing message is struck out.

Back-Ported Changes

• Add messages to plan for sequences (#65): #74
• bump cmake version (#67)
• Change jogging drift dimensions (#63)
• Add ChangeControlDimensions.srv for moveit_jog_arm (#61)

Message API Changing Changes

Add origin Pose to CollisionObject (#69)
Add field quality to PlaceLocation (#64)
Extend MotionPlanRequest with seed trajectories (#46)
Ability to hide visualized robot states (#55)

Next release candidates (changes made for PR not yet merged in moveit)

Add service to update pointcloud octomap (#66)

Tasks (with owners)

• Create an issue to track release - @tylerjw
• Plan the possible date - @tylerjw
• Revert subframes change from melodic-devel - @rhaschke / @v4hn
• Decide on what will be backported - @rhaschke / @v4hn
• Create backport PRs - @tylerjw
• Merge backport PRs - @rhaschke / @v4hn
• Notify release section of discourse - @JafarAbdi
• Run buildfarm tests - @JafarAbdi
• Update changelogs - @mlautman
• Create tag with version number - @mlautman
• Update versions in package.xml - @mlautman
• Run bloom - @mlautman
• Publish release notes on moveit.ros.org - @mlautman
• Post to MoveIt Discourse - @mlautman

Updates

• Update: Struck out anything that changes an existing message API
• #66 moved to next release candidates

Branching for Kinetic

I've just branched for kinetic, the next Kinetic release we should update rosdistro to point to this new branch.

This will allow me to address #4 and #3

@130s

moveit_msgs depends on common_msgs which is a metapackage

Catkin packages cannot depend on metapackages. This causes rosmake to fail when building dry packages which depend on moveit_msgs.

I've been hacking these things to work in my setup, so if I figure it out soon I'll submit a pull request.

See also: moveit/geometric_shapes#1

Noetic Release (0.11.1)

MoveIt Noetic Release (0.11.1)

moveit.ros.org release documentation

Checklist

• Update changelogs
• Bloom

Missing moveit_msgs package and other for Moveit2 and ROS2 Galactic

Following the documentation:
https://moveit.ros.org/install-moveit2/source/
to install Moveit2 for ROS2 Galactic, I noticed that by running the: git clone https://github.com/ros-planning/moveit2.git -b main and then vcs import < moveit2/moveit2.repos,
the moveit_msgs package is missing as well as the srdfdom package.
The ros2_control and ros2_controllers packages are also missing, but at least there is the repository to get them from:
https://github.com/ros-planning/moveit2/blob/main/moveit2_galactic.repos

Same ROS distribution in Windows and Ubuntu (Noetic) but different md5

Hi! I've been using ROS on Ubuntu for years and it works great. Recently I have to use ROS in Windows so I followed this tutorial http://wiki.ros.org/Installation/Windows. It works fine and they can communicate between two computers (export ROS_MASTER_URI..)

However, when I tried to use Moveit, it gives me the following error:

Client [/move_group] wants topic /move_group/goal to have datatype/md5sum [moveit_msgs/MoveGroupActionGoal/152e336e337dce7cbe639f1bd9c65def], but our version has [moveit_msgs/MoveGroupActionGoal/6514728724a6f4ce3f2f5a26db255bc9]. Dropping connection.

Clearly something not compatible here. Then I find that, in windows:

F:\ws>rosmsg md5 moveit_msgs/MoveGroupActionGoal
6514728724a6f4ce3f2f5a26db255bc9

However, in Ubuntu:

rosmsg md5 moveit_msgs/MoveGroupActionGoal
152e336e337dce7cbe639f1bd9c65def

It seems like Ubuntu has the correct md5sum since it matches my other Ubuntu PC with ROS noetic.
I am not sure what happened. They are both Noetic versions but how can the msg md5 not be the same...

Noetic release?

Hi,

It seems this repository hasn't been released for the noetic version yet.
Any concrete plans for it?

Ryan

Move some other *_msgs packages into moveit_msgs repo

household_objects_database_msgs and manipulation_msgs are dependended by MoveIt! AFAIK. Both of those packages are maintained in a separate repo as a unary package, which duplicated the effort upon making a release. Since the primary usage of those packages might be MoveIt! these days, it makes sense to move them into MoveIt!-related repo and combine the maintenance effort.

Caveat is, all packages in a single repo needs to align the same version AFAIK. We can adjust to the highest available version as 0.9.x without any issue IMO.

• 0.1.2 household_objects_database_msgs
• 0.2.1 manipulation_msgs
• 0.9.1 (kinetic-devel) moveit_msgs

New "parameterization" field for OrientationConstraint message

I think it could be useful to add an extra field to the message for orientation constraints that specifies how the orientation should be parameterized when testing the constraints. Currently, the tolerances are applied to the XYZ Euler angles (intrinsic rotations), but they could be just as well be applied to any three number parameterization.

While working on #2092, I seem to notice that exponential coordinates (rotation angle * rotation axis) performed better for projection-based sampling.

My proposal would be to add something like this:

# How should the orientation be parameterized with three numbers
# the absolute axis tolerances are applied to these numbers
uint8 parameterization

# The different options for the orientation constraint parameterization
uint8 XYZ_EULER_ANGLES=0
uint8 EXPONENTIAL_COORDINATES=1

Edit An alternative proposed by @felixvd is to use separate fields for the two different tolerances.

# (optional) Angle tolerance. Only one of the below representation may be used. Not all solvers may support all of them.
# in Euler angles
float64 absolute_x_axis_tolerance
float64 absolute_y_axis_tolerance
float64 absolute_z_axis_tolerance
# in exponential coordinates [add link or explanation here]
float64 value_1
float64 value_2
float64 value_3

The implementation in kinematic_constraints.cpp could look like this: (we would also need to update the constraint samplers)

ConstraintEvaluationResult OrientationConstraint::decide(const moveit::core::RobotState& state, bool verbose) const
{
    /* ... some other code ... */
    Eigen::Isometry3d diff(desired_rotation_matrix_inv_ * state.getGlobalLinkTransform(link_model_).linear());
    if (parameterization_ == Parameterization::EXPONENTIAL_COORDINATES)
    {
      angle_axis = Eigen::AngleAxisd(diff.linear());
      xyz = angle_axis.axis() * angle_axis.angle();
      xyz(0) = fabs(xyz(0));
      xyz(1) = fabs(xyz(1));
      xyz(2) = fabs(xyz(2));
    }
    else if (parameterization_ == Parameterization::XYZ_EULER_ANGLES)
    {
      // use Euler angles by default
      // 0,1,2 corresponds to XYZ, the convention used in sampling constraints
      xyz = diff.linear().eulerAngles(0, 1, 2);
      xyz(0) = std::min(fabs(xyz(0)), boost::math::constants::pi<double>() - fabs(xyz(0)));
      xyz(1) = std::min(fabs(xyz(1)), boost::math::constants::pi<double>() - fabs(xyz(1)));
      xyz(2) = std::min(fabs(xyz(2)), boost::math::constants::pi<double>() - fabs(xyz(2)));
    }
    else 
    { /*default */ }
  }

  bool result = xyz(2) < absolute_z_axis_tolerance_ + std::numeric_limits<double>::epsilon() &&
                xyz(1) < absolute_y_axis_tolerance_ + std::numeric_limits<double>::epsilon() &&
                xyz(0) < absolute_x_axis_tolerance_ + std::numeric_limits<double>::epsilon();

   /* ... some other code ... */
}

A typical planning problem where we want to keep a gripper level to the ground, that can also be solved with the new constraints.

This problem could also be specified using tolerances on Euler angles, but for planners that don't like Euler angles, it is useful to have this alternative. For example, TrajOpt does not use Euler angles.

Comment in DisplayTrajectory is too long

See the text overflowing at
http://docs.ros.org/en/melodic/api/moveit_msgs/html/msg/DisplayTrajectory.html

This is super low hanging fruit. We should also remember to backport to at least melodic.

The file that needs fixing is https://github.com/ros-planning/moveit_msgs/blob/master/msg/DisplayTrajectory.msg

ros1-based branch being the default may be confusing

Switch the default to ros2 or any branch appropriate?

Galactic Release

Blocked by wg-perception/object_recognition_msgs#12

Indigo release 0.7.1

This seems to be blocking moveit/moveit_ros#662