mirror of
https://gitlab.com/obbart/universal_robots_ros_driver.git
synced 2026-04-10 10:00:48 +02:00
12
README.md
12
README.md
@@ -16,21 +16,21 @@ A new driver for the UR3/UR5/UR10 robot arms from Universal Robots. It is design
|
|||||||
|
|
||||||
* Publishes IO state on */ur\_driver/io\_states* (Note that the string */ur\_driver* has been prepended compared to the old driver)
|
* Publishes IO state on */ur\_driver/io\_states* (Note that the string */ur\_driver* has been prepended compared to the old driver)
|
||||||
|
|
||||||
* Service call to set outputs and payload - Again, the string */ur\_driver* has been prepended compared to the old driver (Note: I am not sure if setting the payload actually works, as the robot GUI does not update. This is also true for the old ur\_driver )
|
* Service call to set outputs and payload - Again, the string */ur\_driver* has been prepended compared to the old driver (Note: I am not sure if setting the payload actually works, as the robot GUI does not update. This is also true for the old ur\_driver )
|
||||||
|
|
||||||
|
|
||||||
* Besides this, the driver subscribes to two new topics:
|
* Besides this, the driver subscribes to two new topics:
|
||||||
|
|
||||||
* */ur\_driver/URScript* : Takes messages of type _std\_msgs/String_ and directly forwards it to the robot. Note that no control is done on the input, so use at your own risk! Inteded for sending movel/movej commands directly to the robot, conveyor tracking and the like.
|
* */ur\_driver/URScript* : Takes messages of type _std\_msgs/String_ and directly forwards it to the robot. Note that no control is done on the input, so use at your own risk! Inteded for sending movel/movej commands directly to the robot, conveyor tracking and the like.
|
||||||
|
|
||||||
* */joint\_speed* : Takes messages of type trajectory\_msgs/JointTrajectory. Parses the first JointTracetoryPoint and sends the specified joint speeds and accelerations to the robot. This interface is intended for doing visual servoing and other kind of control that requires speed control rather than position control of the robot. Remember to set values for all 6 joints. Ignores the field joint\_names, so set the values in the correct order.
|
* */joint\_speed* : Takes messages of type _trajectory\_msgs/JointTrajectory_. Parses the first JointTracetoryPoint and sends the specified joint speeds and accelerations to the robot. This interface is intended for doing visual servoing and other kind of control that requires speed control rather than position control of the robot. Remember to set values for all 6 joints. Ignores the field joint\_names, so set the values in the correct order.
|
||||||
|
|
||||||
* Added support for ros_control.
|
* Added support for ros_control.
|
||||||
* As ros_control wants to have control over the robot at all times, ros_control compatability is set via a parameter at launch-time.
|
* As ros_control wants to have control over the robot at all times, ros_control compatibility is set via a parameter at launch-time.
|
||||||
* With ros_control active, the driver doesn't open the action_lib interface nor publish joint_states or wrench msgs. This is handled by ros_control instead.
|
* With ros_control active, the driver doesn't open the action_lib interface nor publish joint_states or wrench msgs. This is handled by ros_control instead.
|
||||||
* Currently two controllers are available, both controlling the joint position of the robot, useable for trajectroy execution
|
* Currently two controllers are available, both controlling the joint position of the robot, useable for trajectroy execution
|
||||||
* The velocity based controller sends joint speed commands to the robot, using the speej command
|
* The velocity based controller sends joint speed commands to the robot, using the speedj command
|
||||||
* The position based controller send joint position commands to the robot, using the servoj command
|
* The position based controller sends joint position commands to the robot, using the servoj command
|
||||||
* I have so far only used the velocity based controller, but which one is optimal depends on the application.
|
* I have so far only used the velocity based controller, but which one is optimal depends on the application.
|
||||||
* As ros_control continuesly controls the robot, using the teach pendant while a controller is running will cause the controller **on the robot** to crash, as it obviously can't handle conflicting control input from two sources. Thus be sure to stop the running controller **before** moving the robot via the teach pendant:
|
* As ros_control continuesly controls the robot, using the teach pendant while a controller is running will cause the controller **on the robot** to crash, as it obviously can't handle conflicting control input from two sources. Thus be sure to stop the running controller **before** moving the robot via the teach pendant:
|
||||||
* A list of the loaded and running controllers can be found by a call to the controller_manager ```rosservice call /controller_manager/list_controllers {} ```
|
* A list of the loaded and running controllers can be found by a call to the controller_manager ```rosservice call /controller_manager/list_controllers {} ```
|
||||||
@@ -106,7 +106,7 @@ Now, the actual transform between *base* and *tool0_controller* will not be publ
|
|||||||
|
|
||||||
NOTE: You need an up-to-date version of *robot_state_publisher* that is able to deal with floating joints, see: https://github.com/ros/robot_state_publisher/pull/32
|
NOTE: You need an up-to-date version of *robot_state_publisher* that is able to deal with floating joints, see: https://github.com/ros/robot_state_publisher/pull/32
|
||||||
|
|
||||||
## Compatability
|
## Compatibility
|
||||||
Should be compatible with all robots and control boxes with the newest firmware.
|
Should be compatible with all robots and control boxes with the newest firmware.
|
||||||
|
|
||||||
###Tested with:
|
###Tested with:
|
||||||
|
|||||||
Reference in New Issue
Block a user