Robot Operating System - Revision history

LIMS: /* Highlights */

2011-06-11T20:42:20Z

Highlights

@@ Line 128: / Line 128: @@
 ==Highlights==
 ===Timers===
 ===Parameter Server===
 ===Severity Levels===
 ===Launch Files===
 ==Resources==

LIMS: /* Control Node */

2011-06-11T20:24:19Z

Control Node

← Older revision		Revision as of 15:24, 11 June 2011
Line 119:		Line 119:

	===Control Node===		===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===		===Keyboard Node===

LIMS: /* Marker Node */

2011-06-11T20:22:27Z

Marker Node

← Older revision		Revision as of 15:22, 11 June 2011
Line 125:		Line 125:

	===Marker Node===		===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==		==Highlights==

LIMS: /* Keyboard Node */

2011-06-11T20:16:57Z

Keyboard Node

← Older revision		Revision as of 15:16, 11 June 2011
Line 122:		Line 122:

	===Keyboard Node===		===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===		===Marker Node===

LIMS: /* Installation */

2011-06-11T20:09:42Z

Installation

← Older revision		Revision as of 15:09, 11 June 2011
Line 94:		Line 94:
	===Installation===		===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])		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:		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		rosmake
	</pre>		</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===		===Serial Node===

LIMS: /* Camera Node */

2011-06-11T20:06:49Z

Camera Node

← Older revision		Revision as of 15:06, 11 June 2011
Line 122:		Line 122:

	===Keyboard Node===		===Keyboard Node===
	===~~Camera~~ Node===		===Marker Node===

	==Highlights==		==Highlights==

LIMS: /* Control Node */

2011-06-11T20:05:04Z

Control Node

← Older revision		Revision as of 15:05, 11 June 2011
Line 119:		Line 119:

	===Control Node===		===Control Node===
			The control node lies downstream of the estimator node and is driven by updates to the system_state topic.

	===Keyboard Node===		===Keyboard Node===
	===Camera Node===		===Camera Node===

LIMS: /* Object Tracker */

2011-06-10T17:58:52Z

Object Tracker

← Older revision		Revision as of 12:58, 10 June 2011
Line 116:		Line 116:

	===Object Tracker===		===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===		===Control Node===
	===Keyboard Node===		===Keyboard Node===

LIMS: /* Estimator Node */

2011-06-10T17:52:26Z

Estimator Node

← Older revision		Revision as of 12:52, 10 June 2011
Line 113:		Line 113:

	===Estimator Node===		===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===		===Object Tracker===
	===Control Node===		===Control Node===

LIMS: /* Serial Node */

2011-06-10T17:48:49Z

Serial Node

← Older revision		Revision as of 12:48, 10 June 2011
Line 110:		Line 110:

	===Serial Node===		===Serial Node===
			This package is the only node with access to the serial port. Therefore, it is the only node that can use the XBee to talk with the robot. Its primary function is to provide two services to the rest of the system. One is the speed command service, and the other is the position request service. When another node calls either of these services, the serial node takes the incoming message definition and compiles a string of custom floats to send to the robot. If the serial node received a speed command, it simply sends the string out to the XBee and replies to the requesting node whether or not that operation was successful. If the serial node received a position request, it compiles a similar string, and then waits for the reply from the robot. When it receives the reply, it sends this information back to the node that made the original request. If it does not get a reply from the robot, it will eventually time out and return a failure to the requesting node. This node also has an added safety feature where it looks for a key strike on the stdin for its terminal and, if it sees one, it shuts down both services and begins sending the stop string repeatedly.

	===Estimator Node===		===Estimator Node===