Differences

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

--- doc:beginner:process_modules [2014/10/21 12:31] – Continued work on the "Writing a process module for the turtlesim" section. mpomarlan
+++ doc:beginner:process_modules [2015/05/11 17:01] (current) – removed gkazhoya
@@ Line 1: / Line 1: @@
-====== Creating process modules ======
-**Description:** in this tutorial you will learn about CRAM process modules and write a simple one to move the turtlesim.
-**Previous Tutorial:** [[doc:beginner:designators|Creating designators for the turtlesim]]\\
-**Next Tutorial:**
-===== Process modules: an overview =====
-A process module is a program that controls a robot actuator. Different robots will have different kinds of actuators, requiring different kinds of controllers, and we would like to abstract away such specifics at the high level of task specification. When we ask a robot to clean a kitchen, we don't care that it has two arms or one; rather, as long as it has some capacity to manipulate objects, and some ability to move around, we can issue the cleaning task to it. Process modules allow us this flexibility by providing a well-defined, robot-independent interface to high level planning which works as an abstraction layer over the robot controllers.
-For better organization, process modules can also be referenced by aliases that describe what kind of function they can perform. Currently, in the cram_highlevel stack for manipulation platforms the following aliases are defined:
-  * :navigation
-  * :ptu
-  * :manipulation
-  * :perception
-A plan will typically refer to a process module by the alias. The process module would be defined for the particular robot in use and associated with the proper alias when the system is initialized.
-Here's an example of invoking a process module:
-<code lisp>
-(with-designators ((my-designator (location '((close-to 'fridge)))))
-  (pm-execute :navigation my-designator))
-</code>
-This will run a process module associated to :navigation and use my-designator to pass parameters to it. In this case, the designator is a semantic description of a target location and it's up to the process module to ask that this designator be resolved (by some appropriate other module in the system) so as to get an actual location and then control the robot to reach the target. The specifics of the controller may vary enormously; the robot might be differential drive, or legged. But these details are not important for this high level plan. All we want is for the robot to approach the fridge, in whatever way it can carry itself there.
-===== Writing a process module for the turtlesim =====
-Once again, some new dependencies must be declared in the tutorial files you've been working on.
-In your package.xml file you need to add build and runtime dependencies on actionlib_lisp, turtle_actionlib, and cram_process_modules:
-<code>
-  <build_depend>actionlib_lisp</build_depend>
-  <build_depend>turtle_actionlib</build_depend>
-  <build_depend>cram_process_modules</build_depend>
-  <run_depend>cram_process_modules</run_depend>
-  <run_depend>actionlib_lisp</run_depend>
-  <run_depend>turtle_actionlib</run_depend>
-</code>
-Similarly, in your .asd file you should add cram-language-designator-support, actionlib, actionlib_tutorials-msg, process-modules, turtle_actionlib-msg to the :depends-on list, so your .asd file should now look like this
-<code lisp>
-(defsystem cram-beginner-tutorial-workthrough
-  :depends-on (roslisp cram-language turtlesim-msg cl-transforms geometry_msgs-msg designators cram-reasoning
-                 cram-language-designator-support actionlib actionlib_tutorials-msg process-modules turtle_actionlib-msg)
-  :components
-  ((:module "src"
-            :components
-            ((:file "package")
-             (:file "tutorial" :depends-on ("package"))))))
-</code>
-==== A process module for the turtlesim ====
-We first need to connect to the turtlesim as a client for an action that will have the turtle draw a shape. To do this, append the following to your tutorial.lisp file
-<code lisp>
-(defvar *navp-client* nil)
-(defun init-action-client ()
-  (setf *navp-client* (actionlib:make-action-client
-                       "turtle_shape"
-                       "turtle_actionlib/ShapeAction"))
-  (roslisp:ros-info (turtle-shape-action-client)
-                    "Waiting for turtle shape action server...")
-  ;; workaround for race condition in actionlib wait-for server
-  (loop until
-    (actionlib:wait-for-server *navp-client*))
-  (roslisp:ros-info (turtle-shape-action-client)
-                    "Turtle shape action client created."))
-(defun get-action-client ()
-  (when (null *navp-client*)
-    (init-action-client))
-  *navp-client*)
-</code>
-The above code simply declares a variable *navp-client* which we can then initialize with a pointer to our ROS action client and retrieve this pointer later with the init-action-client and get-action-client functions, respectively.
-We'll need a way to tell the action client to move along a shape (which is specified by a number of edges and a radius), so append this to tutorial.lisp:
-<code lisp>
-(defun make-shape-action-goal (in-edges in-radius)
-  (actionlib:make-action-goal (get-action-client)
-                        edges in-edges
-                        radius in-radius))
-(defun call-shape-action (&key edges radius)
-  (multiple-value-bind (result status)
-      (with-failure-handling
-          ((simple-error (e)
-             (format t "An error occured!~%~a~%Reinitializing...~%~%" e)
-             (setf *navp-client* nil)
-             (retry)))
-        (let ((actionlib:*action-server-timeout* 10.0))
-          (actionlib:call-goal
-           (get-action-client)
-           (make-shape-action-goal edges radius))))
-    (roslisp:ros-info (turtle-shape-action-client) "Nav action finished.")
-    (values result status)))
-</code>
-In the above code we define a simple function to convert an edge and radius pair of values into a goal for the action client, and a function that will call said action client, with some error handling built in (for example, if the function is called without an action client being defined, it will (re)initialize one and retry).
-Now that the lower level of controlling the turtlesim is taken care of, it's finally time to look at process modules and their interface to the higher levels. Append the following to tutorial.lisp:
-<code lisp>
-(cram-process-modules:def-process-module turtle-actuators (action-designator)
-  (roslisp:ros-info (turtle-process-modules)
-                    "Turtle navigation invoked with action designator `~a'."
-                    action-designator)
-  (destructuring-bind (cmd action-goal) (reference action-designator)
-    (ecase cmd
-      (shape
-         (call-shape-action
-          :edges (turtle-shape-edges action-goal)
-          :radius (turtle-shape-radius action-goal))))))
-(defmacro with-turtle-process-modules (&body body)
-  `(cpm:with-process-modules-running
-       (turtle-actuators)
-     ,@body))
-</code>
-First, we use the cram-process-modules:def-process-module macro to define turtle-actuators as a process module taking one parameter (action-designator). The other lines in the def-process-module are comprise the code for turtle-actuators.
-destructuring-bind will map the results from (reference action-designator) to the variables cmd and action-goal respectively. Note that the inference rules we defined previously provide a name for the kind of action goal we have (currently, all are "shape"), and a turtle-shape object. We run an ecase on the kind of goal (currently, we only have the shape case) and use the call-shape-action to tell the lower level to move the turtle around, given these parameters we infer from designator resolution.
-The with-turtle-process-modules macro is a macro we define for convenience. It allows us to set up a context in which to run commands, knowing that the turtle process modules are all running concurrently. Right now we only have one defined, turtle-actuators. When we will have several, we will add them to the list we pass to cpm:with-process-modules-running. Note that the cpm:with-process-modules-running macro (and therefore with-turtle-process-modules too) needs to be run inside a top-level macro. We will see this below.
-Let's try this out. Make sure you have roscore, turtlesim, and turtle_actionlib running. In a terminal tab for each,
-<code>
-$ roscore
-$ rosrun turtlesim turtlesim_node
-$ rosrun turtle_actionlib shape_server
-</code>
-(**Note** on Oct. 21st 2014: you should check out then catkin_make the ROS common_tutorials from github to make sure you have the newest turtle_actionlib version available, otherwise the turtle might not move. To clone the ros_common tutorials, you will need to
-<code>
-git clone https://github.com/ros/common_tutorials
-</code>
-inside the src folder of a ROS workspace, then catkin_make it.)
-For convenience, let's append one more function to tutorial.lisp that will do all our calls for us:
-<code lisp>
-(defun start-tutorial ()
-  (let ((turtle-name "turtle1"))
-    (start-ros-node turtle-name)
-    (init-ros-turtle turtle-name)
-    (top-level
-      (with-turtle-process-modules
-        (cpm:process-module-alias :manipulation 'turtle-actuators)
-          (cram-language-designator-support:with-designators
-            ((trajectory (action '((type shape) (shape hexagon) (radius 3))))
-              (loc (location '((type navigation) (vpos top) (hpos center)))))
-            (cpm:pm-execute :manipulation trajectory))))))
-</code>
-What the function does is simply start a ROS node for our turtle and sets up the action client, then activates the turtle process modules (in our case, the sole existing one), creates a designator to describe how the turtle should move, and calls the cpm:pm-execute macro to have the process module follow the trajectory specified by the designator.
-Two other things to observe here are the use of the top-level macro, which sets up a CRAM running context and is needed for with-turtle-process-modules. Also, we declare that :manipulation is the alias for our turtle-actuators process module. That way, our plan can invoke a generic name like :manipulation, rather than a robot-specific one like turtle-actuators.
-Reload the tutorial in REPL, and let's try to start the tutorial
-<code lisp>
-TUT> (start-tutorial)
-[(ROSLISP TOP) INFO] 1413894471.489: Node name is /turtle1
-[(ROSLISP TOP) INFO] 1413894471.489: Namespace is /
-[(ROSLISP TOP) INFO] 1413894471.489: Params are NIL
-[(ROSLISP TOP) INFO] 1413894471.489: Remappings are:
-[(ROSLISP TOP) INFO] 1413894471.489: master URI is 127.0.0.1:11311
-[(ROSLISP TOP) INFO] 1413894472.493: Node startup complete
-[(TURTLE-PROCESS-MODULES) INFO] 1413894472.501: Turtle navigation invoked with action designator `#<ACTION-DESIGNATOR ((TYPE
-                                                                        SHAPE)
-                                                                       (SHAPE
-                                                                        HEXAGON)
-                                                                       (RADIUS
-)) {10084BC463}>'.
-An error occured!
-Client lost connection to server.
-Reinitializing...
-[(TURTLE-SHAPE-ACTION-CLIENT) INFO] 1413894480.479: Waiting for turtle shape action server...
-[(TURTLE-SHAPE-ACTION-CLIENT) INFO] 1413894482.480: Turtle shape action client created.
-[(TURTLE-SHAPE-ACTION-CLIENT) INFO] 1413894505.711: Nav action finished.
-[TURTLE_ACTIONLIB-MSG:SHAPERESULT
-   INTERIOR_ANGLE:
-.094395160675049d0
-   APOTHEM:
-.598076105117798d0]
-:SUCCEEDED
-</code>
-You should also see the turtle move in the turtlesim window and trace the required trajectory.
-== Next ==
-//to be defined//