Differences

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

--- teaching:se-kiba:manipulation-assignment:executive [2013/04/24 17:12] – [Moving the Arms (revisited)] bartelsg
+++ teaching:se-kiba:manipulation-assignment:executive [2016/05/19 09:19] (current) – external edit 127.0.0.1
@@ Line 66: / Line 66: @@
   [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]
-Your next assignment is to load and use these parameters 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.
-  * Copy ParameterServerUtils.h from the materials to your include directory.
+  * Create a new package called iai_seminar_manipulation_utils. Add a dependency on roscpp
-  * Create the equivalent cpp-file in src, and add it to the build requirements of our executive in the CMakeLists
+  * 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, use the parameter-server-functions (and our original initGoal and startTrajectory) to implement the second version of initGoal and startTrajectory of the RobotArm class -- it should be quick!
+  * 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... ;)