ros-controls / control_msgs Goto Github PK

To take into account the new error_string field in the FollowJointTrajectory action result.

At my lab and many other places people need an improved GripperCommand action that can handle multiple joints. I saw this being discussed online with ROS very recently, but I cannot find it despite much searching. So I'm asking here what people's thoughts are on this idea? It seems like simply adding [] after many/all of the variables in the GripperCommand action would be sufficient, but we're not sure yet. I might call it EndEffectorCommand and add it to this repo.
@adolfo-rt @mikeferguson @tfoote @isucan @jbohren @mcevoyandy

These messages/actions have become very stable and very commonly used, and not yet released into Indigo. Maintenance cost appears to be near zero, should this be moved to the common_msgs for Indigo?

@tfoote @isucan

What's the difference?

Type: [‘control_msgs/action/FollowJointTrajectory_Feedback’,
‘control_msgs/action/FollowJointTrajectory_FeedbackMessage’]

If I use this message type to publish the feedback I can echo the topic and see the data:
control_msgs::action::FollowJointTrajectory::FeedbackMessage

If I just use:
control_msgs::action::FollowJointTrajectory::Feedback I get the error:
The message type 'control_msgs/action/FollowJointTrajectory_Feedback' is invalid

Since we aren't merging this into common_msgs, can we get an indigo release? This is one of the last low-level messages missing in Indigo. Thx.

Otherwise the messages get generated as PointHeadActionAction.msg.

(Or does it need to be different than the original PointHead.action in pr2_controllers_msgs?

Hello folks,

ROS Kinetic is missing control_msgs for the final release.
I volunteer to do the release but I'd like to have some +1-s before.

@adolfo-rt @davetcoleman @efernandez

Hi,

Can I know the license under which I can use this control_msgs,

Thanks,

As of now, the result of a FollowJointTrajectory action is an error_code, which is partially informative. It lets you know whether execution was successful or not, and in case of failure, a general assessment of the failure type.

Still, I'd find it useful to have some additional information for at least user feedback.

Usecase

A motion fails because goal time constraints were violated for joint foo.

Current state

The error_code of the action result message states GOAL_TOLERANCE_VIOLATED. Assuming we're using the joint_trajectory_controller from ros_controllers in a realtime deployment, no log statements are issued, as currently there is no mechanism for logging from a realtime context.

Proposal
For most cases I think that it would suffice to create a complementary error_string member containing messages like:

• In case of INVALID_JOINTS:

Command specifies a trajectory for joint 'bar', which is not part of
controller 'right_arm' .

• In case of GOAL_TOLERANCE_VIOLATED:

Goal tolerance violated for joint 'foo'. Position error: 0.03 (max 0.01).

Although we could set up a mechanism for logging these messages from a realtime context, I think it's still relevant to add this to the action spec, so that the message can be used in the context of the client, like displaying it in a GUI.

Would you mind releasing control_msgs to ROS Noetic? It looks like all of its dependencies have been released, and recursively 103 repos need it.

I'm not sure how much work it will need. At a minimum it needs #40.

We have travis enabled for this repository but it's not set up.
https://travis-ci.org/ros-controls/control_msgs

Can I ask a volunteer to set it up please?
@ipa-mdl or @efernandez perhaps?

When using the joint trajectory controller it would be useful to know the current segment being executed in the trajectory in the event of a path tolerance violation to allow recovery. Would the maintainer be open to PR adding this to the feedback message?

For ROS2, it looks like .h and .hpp header files are installed to install/control_msgs/include/control_msgs/msg. Probably only want the .hpp versions (that's what other ROS2 packages seem to use).

I have built with the --symlink-install option.

My package depends on control_msgs, I am trying to update my package to ROS2 Dashing, unfortunately, since control_msgs is not yet released for ROS2 Dashing I a quite stuck. Are you planning to create a release for Dashing?

I'm in the process of testing a new extension to the ROS1 bridge for ROS2 to support actions: ros2/ros1_bridge#256

One of the objectives I'd like to test is controlling a Fetch platform (with binary blobs for ROS1 joint controllers) from ROS2, as I mention here: ros2/ros1_bridge#256 (comment) . This of course necessitates the use of FollowJointTrajectory action for controlling the robot arm. From comparing the current ROS1 to ROS2 branches, it seems all changes are either purely additive with new message types and new message fields, or modify only existing message field types to comply with the latest IDL type standards in ROS2.

kinetic-devel...galactic-devel

I'd like to ask if any of these major message type changes, like from #55 for example, would require any additional configuration for ROS1 bridge users? To what degree do we expect ROS1 controllers and ROS2 planners to interoperate, if at all? For example:

Do we need to install custom mapping rule files along with this message package?

https://github.com/ros2/ros1_bridge/blob/master/doc/index.rst#how-can-i-install-mapping-rule-files

This would be similar to other existing message packages in ROS2:

• ros2/geometry2#48
• ros2/demos#525

CC @ipa-hsd @aefrank @DLu @mamoll @bmagyar @AndyZe

Would it be possible to add / recommend a copyright notice for this package?

Usually most packages in ROS 2 utilize ament_copyright to automate this chore a bit, but you dont necessarily have to use it if you dont want.

An automated scheduled build failed on master: https://github.com/ros-controls/control_msgs/actions/runs/8611388829

Hi. How is the duration field of the JointJog message intended to be used? What is supposed to happen with the position and velocities at the end of the duration? Is it supposed to be used with position values when velocities are not provided in order to calculate velocities? Are the position values always supposed to be relative displacements or can they be also used to mean absolute positions from some coordinate system? Are these messages available for Dashing? The README says so, but there does not appear to be a Dashing branch. Thanks!

This message package is going to be a blocker for a number of robot-related releases into Jade.

Hi,

The license is listed as BSD in the package.xml, but there is no LICENSE file provided, and there are multiple variants of the BSD license out there.

Can you clarify which BSD license variant control_msgs is covered by?

Has anyone attempted to convert this to ros2? A bunch of the ros-industrial code depends on this great package and we are converting to ros2.

If not, i am going to go ahead and do that.

Thanks!

An automated scheduled build failed on master: https://github.com/ros-controls/control_msgs/actions/runs/8276504436

As with ros-controls/control_toolbox#87, should setup CI for ROS2 branches

The ROS2 branches are still running kinetic-devel CI, and then falsely succeeding without having actually tested on ROS2. The build status on the README is pretty misleading at the moment.

as reported on ROS answers.

rosidl_generate_interfaces should get called.

@AustinDeric: Please have a look at it.

ROS2 Eloquent is going to be released very soon, it would be nice to make a new version of the control_msgs package supporting this version of ROS2 (there is probably nothing to change from the Dashing version).