OverviewDuration: 3:00 Services within the Robot Operating System (ROS) are often used to control your robot. After getting your robot built and software installed, the next step is to make it do something. Before a deep dive into writing software, let’s create a few simple service calls to do some basic actions with your robot.
What you’ll learnIn this tutorial we’ll cover how to discover and call ROS 2 services on an OpenMANIPULATOR-X robot arm from Robotis. Using a different robot? No problem! The commands are very similar, but you’ll get different results depending on the services made available with your robot. So long as you’re running ROS 2, you should be able to use this tutorial! What you’ll needAll you need to complete this terminal is a running robot arm assembled and set up for ROS 2 according to the manufacturer’s directions. Alternatively you can also work through this tutorial using the turtlesim demo described in the ROS 2 tutorials. An introductory level knowledge of YAML will also help, since we’ll be using YAML to communicate with ROS services. How will you use this tutorial?
56voters What is your current level of experience with ROS?
55voters Discover ServicesDuration: 12:00 Let’s look to see what services the robot publishes. Before beginningLaunch your robot according to the instructions. Here’s how to launch the OpenMANIPULATOR-X robot: You should see a successful launch similar to the following: The arm should now stay locked in position and will remain locked so long as this command is running. Leave this running and work through the rest of this tutorial in a new terminal window. Find ServicesUse the This is a long list. However, many of these services with the “parameters” name are internal to ROS 2 and not something we’ll be using. Use grep to filter out those services with this command: This results in a much smaller list and can group them by function (spacing added for readability): Although the service names seem pretty self-explanatory, reviewing the documentation for the robot may also help you to better understand the purpose of these services. In the next step we’ll dig into the the Discover the Service InterfaceDuration: 7:00 Messages are used to communicate with ROS services. In order to control a service, we need to figure out how to craft a message it understands, and these messages types are defined in the service interface. Find the service message typeAn easy way to find the message type for the This shows the type of message expected by the service: Many services can use the same message type, but each service accepts only a single type of message. For our example, the set_actuator_state service has an interface type Explore the message interfaceArmed with the type of message, we now need to how to craft a message of the right type. This requires exploring the actual message structure: the message interface specification. You can find the details for a message interface using the This returns two different message structures separated by dashes. The first structure is the message type sent to the service, while the second structure is the message type returned by the service: This interface is quite simple: send a Boolean true/false value, and receive a Boolean true/false message in response.
To better understand service interfaces, compare the output of the command Send a simple message to a serviceDuration: 5:00 Now we have everything we need to send a message to the robot. It’s time to use the
The message values need are sent in YAML format. Since our message simply requires a single Boolean value named The final command looks like this: You should see the following response: The response matches our expectations: a single variable named “is_planned” set to True which means the robot plans to carry out our request. Congratulations! You’ve now sent your first service command to your robot. Lock the arm again (hint: send the same message, but set the value to “true”) and then let’s work with something a bit more complex. Craft a Complex MessageDuration: 7:00 Our next challenge will be to open and close the robot gripper. Find the service interfaceA slightly more complex message is to open and close the robot gripper. This is done through the goal_tool_control service. Using the ros2 service and ros2 srv commands, we can map out how to communicate with the service:
Hmm. The arguments planning_group and path_time are primitive field types (string and float64), but the variable joint_position is a message of type JointPosition: this is message type encapsulated within the service request. We need to find out how to craft a JointPosition message within our reqest. Use output from the command Many messages such as GoalInfo come installed with ROS, but your robot often will also use custom types, which is the case for our JointPosition message. As you can see from the interface information, this message is part of the This command gives us details about the message structure: The brackets after the data type for joint_name and joint_position arguments means these are arrays, not individual values. When we craft the YAML message for the service we need to send an array, not an individual value.
We’ve come a long way without referring to vendor documentation, but at some point you may find that you have to actually read the manual. A quick look at the documentation for the robot arm lets us know the joint_name of the servo we’re trying to move is called “gripper”, and its position must be a value between -0.01 (fully closed) and 0.01 (fully open). We now have enough information to create a well formed service call which opens the joint: Another quick look at the documentation (or a bit of trial-and-error) shows that we can take default values for most of the parameters and remove them from the message. This results in a fairly simple command we can use to open the gripper: Can you create a service call to close the gripper? Move to a Point in SpaceDuration: 5:00 We’re on a roll. Let’s make the arm move! Set a poseIn order to move the arm to a specific position, we’ll use the SetKinematicsPose interface. This service interface contains a number of nested message structures, but the steps you’ve already completed should allow you to create a well-formed YAML request. Here’s a summary of message types and fields used by SetKinematicsPose. Can you reproduce this list on your own using the commands we’ve already covered?
Now we can call the SetKinematicsPose service. Fill in the YAML structure with the information gathered from exploring the message structure to move the robot arm to position (x=0, y=0, z=0): Did your robot arm move? If not, it’s probably because moving this robot moving to (0, 0, 0) may be unreasonable. Instead try moving to (0.15, 0.00, 0.20) and see how that works! Keep in mind that ROS has standardized on the International System of Units for all measurements, so distances are all in meters. Once again we can remove some unnecessary arguments (for now) to simplify: ConclusionDuration: 2:00 Congratulations! You’re now able to control your robot to run some straight forward tasks without having to compile and run code. Next StepsContinue exploring the wealth of documentation on how to create and use services in ROS 2 89. You can also roll a few of these utility commands into a simple shell script to quickly do some work with your robot. Here’s an example sample script to get you started: Futher Reading
|
|
|
Does 
