Using ROS Visualization

The ROS Visualization container (RVC) has many capabilities. Once you've started the RVC you have the ability to add new packages and whole toolsets onto the container at the command line with apt-get install -y [package name].

This section assumes you have already executed the instructions in the Quick Start section or a customized docker run.

The following sections are brief tutorials that adapt existing ROS Tutorials to RVC and showcase the built-in capabilities of RVC.

• ROS Services
• ROS Topics
• ROS Gazebo
• ROS Moveit

ROS Overview

The ROS Master acts as a nameservice in the ROS Computation Graph. It stores topics and services registration information for ROS nodes. Nodes communicate with the Master to report their registration information. As these nodes communicate with the Master, they can receive information about other registered nodes and make connections as appropriate. The Master will also make callbacks to these nodes when this registration information changes, which allows nodes to dynamically create connections as new nodes are run.

Nodes connect to other nodes directly; the Master only provides lookup information, much like a DNS server. Nodes that subscribe to a topic will request connections from nodes that publish that topic, and will establish that connection over an agreed upon connection protocol. The most common protocol used in a ROS is called TCPROS, which uses standard TCP/IP sockets.

This architecture allows for decoupled operation, where the names are the primary means by which larger and more complex systems can be built. Names have a very important role in ROS: nodes, topics, services, and parameters all have names. Every ROS client library supports command-line remapping of names, which means a compiled program can be reconfigured at runtime to operate in a different Computation Graph topology.

For example, to control a Hokuyo laser range-finder, we can start the hokuyo_node driver, which talks to the laser and publishes sensor_msgs/LaserScan messages on the scan topic. To process that data, we might write a node using laser_filters that subscribes to messages on the scan topic. After subscription, our filter would automatically start receiving messages from the laser.

Note how the two sides are decoupled. All the hokuyo_node node does is publish scans, without knowledge of whether anyone is subscribed. All the filter does is subscribe to scans, without knowledge of whether anyone is publishing them. The two nodes can be started, killed, and restarted, in any order, without inducing any error conditions.

Later we might add another laser to our robot, so we need to reconfigure our system. All we need to do is remap the names that are used. When we start our first hokuyo_node, we could tell it instead to remap scan to base_scan, and do the same with our filter node. Now, both of these nodes will communicate using the base_scan topic instead and not hear messages on the scan topic. Then we can just start another hokuyo_node for the new laser range finder.

• source: http://wiki.ros.org/ROS/Concepts

• roscore: A core program of ROS, which launches a ROS master. Execute roscore before executing nodes.

• rosrun: Execute a node.

• roslaunch: Execute a launch file. roslaunch automatically executes roscore.

• rosnode: List information about ROS nodes.

• rostopic: Print information about ROS topics.

• rosservice: Print information about ROS services.

• rosmsg: Commands related to ROS message types.

• rossrv: Commands related to ROS service types.

• rospack: Commands related to ROS packages.

• roscreate-pkg: Commands related to creating a new ROS package.

• rosbag: Commands related to ROS bags.