Currently, we are investigating to create a Cartesian robot control interface similar to the FollowJointTrajectory interface which is broadly being used to control robot manipulators in joint space.
Many manufacturers actually offer Cartesian interfaces manually, but there’s (to our knowledge) no standardized ROS interface to communicate with such an interface. However, in certain applications such as gluing or welding it would make a lot of sense to specify a Cartesian control interface.
We are aware, that there have been multiple approaches to define something similar in the past, which is why we started off with a design document where we try to cover existing interfaces and we try to wrap up an interface proposal to turn it into an REP and a reference implementation at some point.
As we recently pushed our design document to GitHub and readthedocs, we would like to invite you as the ROS community to participate in discussing Cartesian interfaces. We think that it makes sense to generate an interface which is most suitable for everyone.
So, if you like, have a look at our design document over at readthedocs and enter the discussing by commenting or creating new issues at the corresponding GitHub repository.
Just to be clear: We are currently talking about ROS as in not ROS 2. Obviously this doesn’t mean that the developed concepts and messages cannot be used and implemented inside of ROS 2, as well.
Supported by ROSIN - ROS-Industrial Quality-Assured Robot Software Components.
More information: rosin-project.eu
This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement no. 732287.
This looks really comprehensive and detailed. I don’t think anyone could ask for a better point of departure for a discussion. Big props for compiling this.
Great work. It will be nice to be able to use this action with behavior trees, like BehaviorTree.CPP
Will you also have any recommendations or proposals on the hardware driver interface for anyone who wants to write new hardware drivers to implement this action or wrap existing drivers?
Some drivers may be able to implement some or all of this action directly, otherwise should they expose a standard set of topics, services, and actions so that some other controller can handle it?
Many drivers may only be able to support a subset of this action’s possibilities.
Thanks @fmauch for compiling this. Perfect timing as I am programming Trajectory interfaces right now but for ROS2. My plan is most similar to Banachowicz in that I only plan for the end-effectors and the IK does the linkage joints. I am using Orocos KDLs Trajectory APIs to generate the smooth motions. I am currently using RViz2’s interactive markers (Axis manipulators and menus mostly) to plan and execute the trajectories. I am open to discussing higher level interfaces though.
@peterpolidoro I just spent an hour reviewing your BehaviorTree link, I will definitely be using that.
Our plan is to integrate it into the UR driver as a reference implementation.
However, as we plan to leverage ROS-Control for this, it should be fairly easy to integrate into other robot drivers, as well.
Currently, we are also working on a second chapter where we wrapup a couple of vendor interfaces, as we would also like to propose a more industrial-like interface where you can send complete motion commands to the robot similar to REP: I0003. We hope to publish it (at least as a PR) this week.
Very impressive investigation into a needed standardization! I think we in the MoveIt project should look into this as we’ve had long debates about how to balance all the various needs of different control approaches. @AndyZe
I don’t see any serious shortcomings with the proposal.
The posture fields should definitely be optional. I think it would be an annoyance more often than not.
This sentence is a little vague:
With this definition users can define tolerances per axis, where rotational constraints are meant to be angle differences in the local coordinate system.
Does local frame mean tcp_frame or the frame in the header?
