Robot Operating System - Revision history

LIMS: /* Highlights */

2011-06-11T20:42:20Z

Highlights

LIMS: /* Control Node */

2011-06-11T20:24:19Z

Control Node

LIMS: /* Marker Node */

2011-06-11T20:22:27Z

Marker Node

LIMS: /* Keyboard Node */

2011-06-11T20:16:57Z

Keyboard Node

LIMS: /* Installation */

2011-06-11T20:09:42Z

Installation

LIMS: /* Camera Node */

2011-06-11T20:06:49Z

Camera Node

LIMS: /* Control Node */

2011-06-11T20:05:04Z

Control Node

LIMS: /* Object Tracker */

2011-06-10T17:58:52Z

Object Tracker

LIMS: /* Estimator Node */

2011-06-10T17:52:26Z

Estimator Node

LIMS: /* Serial Node */

2011-06-10T17:48:49Z

Serial Node

@@ Line 128: / Line 128: @@
 ==Highlights==
+The following highlights are things that were learned over two quarters of coding in ROS
 ===Timers===
+ROS has made it easy to implement timers that run in different threads.  Find details [http://www.ros.org/wiki/roscpp/Overview/Timers here].
 ===Parameter Server===
+The parameter server is essentially a reserved space in ROS for global variables.  Any node can check to see if they exist, get them, or set them.  Check [http://www.ros.org/wiki/Parameter%20Server here] for details.
 ===Severity Levels===
+Although it is still possible to use basic print statements in ROS, there is a built in system for creating print statements with severity levels attached to them.  These severity levels are DEBUG, INFO, WARN, and ERROR.  The system defaults to only printing INFO, WARN, and ERROR.  As such, it is a good idea to put debug statements all over your code and just leave them there.  Although you will not see them normally, you can change this using the [http://www.ros.org/wiki/rxconsole rxconsole] command line tool.  ROS also automatically color codes the different severity levels so you can easily distinguish between them.  This is very helpful when you are printing out a ton of information.
 ===Launch Files===
+Launch files are hugely helpful when you begin working with larger systems.  They allow you to launch multiple nodes at the same time and pass configuration parameters to them.  Find more information about them [http://www.ros.org/wiki/roslaunch here].
-===Command Line Tools===
+===Data Logging===
+ROS has a built in system for collecting, compressing, saving, replaying, and viewing any message data being passed within the system.  They call the compressed files bag files.  You can use [http://www.ros.org/wiki/rosbag rosbag] to collect the data and [http://www.ros.org/wiki/rxbag rxbag] to view and replay the data.
+===System Diagram===
+rxgraph is a tool for visualizing the layout of your current ROS system.  This can be very useful for debugging system structure problems.  Find details [http://www.ros.org/wiki/rxgraph here].
+===Visualization===
+Although a little troublesome at times, rviz is a tremendously powerful tool for visualizing all sorts of spacial data.  Any robotic system can benefit hugely from this tool.  Find details [http://www.ros.org/wiki/rviz here]
 ==Resources==

@@ Line 119: / Line 119: @@
 ===Control Node===
-The control node lies downstream of the estimator node and is driven by updates to the system_state topic.
+The control node lies downstream of the estimator node and is driven by updates to the system_state topic.  This is the most complex node in the system and is responsible for using the optimal control gains, desired state, and current state to generate the next set of controls to be sent to the robot.
 ===Keyboard Node===

@@ Line 125: / Line 125: @@
 ===Marker Node===
+This node uses ROS's visualization stack to generate markers that are visible in rviz.  These markers are easy to implement and are tremendously helpful for debugging transformations and data with a spacial component.  This node is subscribed to and driven by the system_state topic.  Although the data is not in the same coordinate system as the optimization and the control node, it lines up properly with the Kinect point cloud and camera image.
 ==Highlights==

@@ Line 122: / Line 122: @@
 ===Keyboard Node===
+The keyboard is a dedicated node for user input.  In any system with so many nodes, you end up running programs in several different terminals.  As such, it is often hard to quickly start or stop certain nodes.  This is a problem when you are trying to recover from an error or stop the robot from doing something unsafe.  To fix this, you can use a dedicated node that changes variables stored on the global parameter server and modify the other nodes to watch these parameters.  The keyboard node was designed to do just this, and responds to several different commands.  The primary function of this node is to change the system state between idle, calibrate, run, and stop.  Although there is a fifth condition, emergency stop, only other nodes can set the system to that condition.  This node uses a timer and the kbhit function to check stdin at 200Hz.  Any key that isn't explicitly defined will set the system condition to stop.
 ===Marker Node===

@@ Line 94: / Line 94: @@
 ===Installation===
 All of the packages used in this example can be found on the following [https://github.com/jakeware/ github page].  Here are individual links to the packages: ([https://github.com/jakeware/serial_node Serial Node], [https://github.com/jakeware/estimator_node Estimator Node], [https://github.com/jakeware/puppeteer_control Control Node], [https://github.com/jakeware/object_tracker Object Tracker Node], [https://github.com/jakeware/puppeteer_markers Marker Node], [https://github.com/jakeware/keyboard_node Keyboard Node], [https://github.com/jakeware/puppeteer_msgs Puppeteer Messages])
+Note that these repositories are constantly being updated and their overall structure may diverge from the descriptions listed below.  You can find static versions of the source code [[Puppeteer_Code.zip |here]].
 Once you are in a folder in the ROS package path, enter the following commands to download build the package:
@@ Line 106: / Line 108: @@
 rosmake
 </pre>
-If you would like to just look at the source code, you can find a zip file with all of the source code [[Puppeteer_Code.zip |here]].
 ===Serial Node===

@@ Line 116: / Line 116: @@
 ===Object Tracker===
+The object tracker is responsible for finding the mass position given a RGBD point cloud from the Kinect.  It has two modes of operation.  First, it looks at the point cloud from the entire area under the puppeteer stage and finds the centroid of all the points in this cloud.  Once it has found the object, it will only look at a cube several inches wide around the last valid centroid position.  This reduces the computational time and cuts out noise dispersed across the entire point cloud.  If it ever finds a centroid from a cloud with very few data points, it assumes it has lost the mass and returns to looking at the entire puppeteer stage.  Although the mass position is passed to the estimator node through the object1_position topic, it also publishes a point cloud for the object, a point cloud for all of the Kinect data, and a frame for the mass position.  All three of these can be viewed in rviz.
 ===Control Node===
 ===Keyboard Node===

@@ Line 113: / Line 113: @@
 ===Estimator Node===
+The estimator node is responsible for collecting both the state of the mass and the robot.  Currently, it is driven by the Kinect frequency and will not function unless the object tracker publishes a new mass position on its outgoing topic.  Once the estimator node gets a new mass position, it calls the position request service and waits for the serial node to pass back the robots reported position. Once it has all of this information, it assembles the system state and publishes it on the system_state topic.
 ===Object Tracker===
 ===Control Node===