Class 5: Understanding the gripper and torso controllers
- How did using the robot go? Any problems? Did people implement their controller? Why or why not?
- Demos if applicable
- Any vm/native ubuntu installation questions
For more details view: http://wiki.ros.org/actionlib
In order for the client and server to communicate, we need to define a few messages on which they communicate. This is with an action specification. This defines the Goal, Feedback, and Result messages with which clients and servers communicate:
To accomplish tasks using actions, we introduce the notion of a goal that can be sent to an ActionServer by an ActionClient. In the case of moving the base, the goal would be a PoseStamped message that contains information about where the robot should move to in the world. For controlling the tilting laser scanner, the goal would contain the scan parameters (min angle, max angle, speed, etc).
Feedback provides server implementers a way to tell an ActionClient about the incremental progress of a goal. For moving the base, this might be the robot's current pose along the path. For controlling the tilting laser scanner, this might be the time left until the scan completes.
A result is sent from the ActionServer to the ActionClient upon completion of the goal. This is different than feedback, since it is sent exactly once. This is extremely useful when the purpose of the action is to provide some sort of information. For move base, the result isn't very important, but it might contain the final pose of the robot. For controlling the tilting laser scanner, the result might contain a point cloud generated from the requested scan.
(from ros wiki)
- current controller's running
- review command_torso and command_gripper functions
- look at rostopic echo to see action status
- Same as grippper and torso but uses a joint trajectory goal
- looking ahead: arm commands are sent with joint trajectory goals