Differences

This shows you the differences between two versions of the page.

--- teaching:se-kiba:manipulation-assignment:executive [2013/04/24 16:57] – [Moving the Arms (a first glance)] bartelsg
+++ teaching:se-kiba:manipulation-assignment:executive [2016/05/19 09:19] (current) – external edit 127.0.0.1
@@ Line 50: / Line 50: @@
 Hints: You can peek [[http://www.ros.org/wiki/pr2_controllers/Tutorials/Moving%20the%20arm%20using%20the%20Joint%20Trajectory%20Action|here]] to know how to use the controller, and [[http://www.ros.org/wiki/roslaunch/XML/remap|this page]] shows how to remap topics in a launch-file.
 ===== Moving the Arms (revisited) =====
+Now that we have the code to make one arm move, let's try to make it more convenient and reusable:
+  * In our executive package, create a sub-directory config.
+  * Copy left_arm_goals.yaml and right_arm_goals.yaml from the materials directory to config
+  * In the launch-file, load the params given in left_arm_goals.yaml in the namespace of our executive. Look [[http://www.ros.org/wiki/ROS/Tutorials/Roslaunch%20tips%20for%20larger%20projects|here]] for an example of how to do it.
+  * After starting your launch-file, a test could be this:
-[[http://www.ros.org/wiki/ROS/Tutorials/Roslaunch%20tips%20for%20larger%20projects|roslaunch tips]]
+  $ rosparam list | grep goal
+  <bla>
+  /your_executive/first_goal_configuration/execution_time
+  /your_executive/first_goal_configuration/joints
+  /your_executive/first_goal_configuration/positions
+  /your_executive/first_goal_configuration/velocities
+  <blub>
+  $ rosparam get /your_executive/first_goal_configuration/joints
+  [l_shoulder_pan_joint, l_shoulder_lift_joint, l_upper_arm_roll_joint, l_elbow_flex_joint, l_forearm_roll_joint, l_wrist_flex_joint, l_wrist_roll_joint]
-[[http://www.ros.org/wiki/roscpp/Overview/Parameter%20Server|loading from the parameter server]]
+Your next assignment is to load and use these parameters from the parameter server. We will do this in a new library package. This package will not contain any executable but just library code to be used by other packages.
-===== Exposing a Library =====
+  * Create a new package called iai_seminar_manipulation_utils. Add a dependency on roscpp
+  * Copy ParameterServerUtils.h from the materials to include directory of that package.
+  * Create the equivalent cpp-file in src, and add it to the build requirements of the utils package in the CMakeLists __as a library__. The following [[http://answers.ros.org/question/33779/how-do-i-link-an-executable-with-library-in-other-package/|discussion on ROS answers]] should help you to (a) expose the functionalities as a library and (b) use it in another package.
+NOTE: ROS libraries are a great thing that basically offer two advantages. (1) They help __you__ re-use code in various of your ROS application. (2) If you provide some generic algorithm as library as a pure c/c++ library, you even allow __non-ROS-users__ to use your algorithm in their work. This is hard to achieve but the ultimate design goal: A clean cut between functionality/algorithm and meta-OS, i.e. ROS.
+  * Now, implement all functionality described in ParameterServerUtils.h to load values from the parameter server. Consider using the data already one the server to test your functions. ([[http://www.ros.org/wiki/roscpp/Overview/Parameter%20Server|This]] should give you some good examples.)
+  * Afterwards, let the executive package depend on the library package. Use the parameter-server-functions (and our original initGoal and startTrajectory) in the executive package to implement the second version of initGoal and startTrajectory of the RobotArm class -- it should be quick!
+  * Now, use the new initGoal(ros::NodeHandle&) and startTrajectory() in main.cpp. This should remove any need for hard-coded goals, and instead use the ones from the parameter server.
+Using parameters from the server instead of hard-coded values the way we just did has several tremendous advantages:
+  * It shows users which kind of parameters your node needs to produce useful results.
+  * It also provides them with a set of _specific_ example parameters that should work (always nice for demonstrations)
+  * It allows you to change your current choice of parameters without recompiling the node. This will save you a lot of time in the future.
+===== Moving the Arms (re-using code) =====
+Finally, we will re-use our code to move both arms:
+  * In the launch-file, give our executive a name that indicates that it takes care of the left arm.
+  * In the launch-file, start another second node for the right arm. It should be just like the left one, just map the action to the right arm controllers and load the parameters from right_goal_configuration.yaml
+That's it. We have just completely re-used our code to control another arm! Imagine how much time you could save on a spider... ;)