Replies: 3 comments
-
If you just want to execute trajectories, the action interface is probably fine. If you want to do more advanced, realtime control, or even admittance control, the action interface won't be able to. I understand how ros2_control can be difficult to use initially, and unfortunately it's getting more and more complex (in my opinion). |
Beta Was this translation helpful? Give feedback.
-
Use the action interface if you have an action server already and are interested in "only" executing trajectories.
That's actually the most common case, even when people say it's very limited.
If you want to stay in control of trajectory execution *during the execution*,
you will need to run code in a tight loop around the hardware
interfaces on your machine and ros_control does that for you with
extensible interfaces that some modules in MoveIt can use.
|
Beta Was this translation helpful? Give feedback.
-
Thank you for the replies! The motors of my robot have off-the-shelf controllers that ensure they get to the desired position. I only want Moveit to send a target to these controllers. Monitoring if anything goes wrong with the trajectory execution is enough. |
Beta Was this translation helpful? Give feedback.
-
I used Moveit 1 for the past year on an industrial robot. I used a proprietary action interface to communicate with the robot hardware. The manufacturer doesn't have off-the-shelf drivers for it.
I'm now moving to Moveit 2, and the low-level controller tutorial states that 99% of the users prefer ros2_control over the action interface. Why is that? What are the advantages of ros2_control?
I chose the action interface because it was simpler to understand and implement, in my opinion. To use the action interface on Moveit 2, you only need to create an action server using the control_msgs FollowJointTrajectory. Using the ros2 action list command, you can see the correct namespace used by the Moveit action client.
Beta Was this translation helpful? Give feedback.
All reactions