Exploring ROS: ROS Computation Graph Model

As discussed in the previous article, running sets of ROS-based processes are represented in a graph architecture where processing takes place in nodes that may receive, post, and multiplex sensor data, control, state, planning, actuator, and other messages.

ROS Computational Graph

The Computation Graph is the peer-to-peer network of ROS processes that process data together. The basic Computation Graph concepts of ROS are

1. Nodes: Nodes are processes that perform computation.
2. Master: The ROS Master provides name registration and lookup to the rest of the Computation Graph. Without the Master, nodes would be unable to find each other, exchange messages, or invoke services.
3. Parameter Server: The Parameter Server allows data to be stored by key in a central location. It is currently part of the Master.
4. Messages: Nodes communicate with each other by passing messages. Messages are data structures used for communication between nodes.
5. Topics: it is a named channel that facilitates communication between nodes. Topics follow a publish-subscribe messaging model, allowing for asynchronous communication. Multiple nodes can publish or subscribe to the same topic, enabling decentralized communication and modular system design.
6. Services: The publish/subscribe model is a very flexible communication paradigm, but its many-to-many, one-way transport is not appropriate for request/reply interactions, which are often required in a distributed system. Request/reply is made via services, defined by a pair of message structures: one for the request and one for the reply. A providing node offers a service under a name, and a client uses the service by sending the request message and awaiting the reply. ROS client libraries generally present this interaction to the programmer as a remote procedure call.
7. Bags: Bags are a format for saving and playing back ROS message data.

The ROS Master acts as a name service (A name services store information in a central place that users, workstations, and applications must have to communicate across the network) in the ROS Computation Graph. It stores topic and service 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 create connections as new nodes are run dynamically.

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 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.

Some basic commands

rosnode

1. rosnode info print information about the node.
2. rosnode kill kill a running node.
3. rosnode list list active nodes.
4. rosnode machine <machine-name> list nodes running on a particular machine or list machines.
5. rosnode ping test connectivity to node.
6. rosnode cleanup purge registration information of unreachable nodes.

rosparam

1. rosparam set set parameter.
2. rosparam get get parameter.
3. rosparam load load parameters from the file.
4. rosparam dump dump parameters to file.
5. rosparam delete delete parameter.
6. rosparam list list parameter names.

rostopic

1. rostopic bw display bandwidth used by the topic.
2. rostopic delay display delay for a topic that has a header.
3. rostopic echo print messages to the screen.
4. rostopic find find topics by type.
5. rostopic hz display the publishing rate of the topic.
6. rostopic info print information about the active topic.
7. rostopic list print information about active topics.
8. rostopic pub publish data to the topic.
9. rostopic type print topic type.

rosservice

1. rosservice call call the service with the provided args.
2. rosservice find find services by service type.
3. rosservice info print information about the service.
4. rosservice list list active services.
5. rosservice type print service type.
6. rosservice uri print service ROSRPC URI (Universal Resource Identifier).

rosbag

1. rosbag record record a bag file with the contents of specified topics.
2. rosbag info summarize the contents of a bag file.
3. rosbag play playback the contents of one or more bag files.
4. rosbag check determine whether a bag is playable in the current system or if it can be migrated.
5. rosbag fix repair the messages in a bag file so that it can be played in the current system.
6. rosbag filter convert a bag file using Python expressions.
7. rosbag compress compress one or more bag files.
8. rosbag decompress decompress one or more bag files.
9. rosbag reindex reindex one or more broken bag files.

How to study a rqt_graph

rosrun turtlesim turtlesim_node

Circular entities are nodes, rectangular entities are topics, and the arrows indicate the flow of data between the nodes through the topics i.e., represent publication(if it enters a topic)/subscription(if it goes out of topic).

The connection between nodes or topics is in accordance with TCPROS, as discussed above.

tf is seen quite often while working with rqt_graph, it is a package that lets the user keep track of multiple coordinate frames over time.

tf maintains the relationship between coordinate frames in a tree structure buffered in time, and lets the user transform points, vectors, etc between any two coordinate frames at any desired point in time.

Sometimes lines are dashed, which represent a subscription between nodes.

Often times there is a connection made but there is no data being shared, this has to be checked by rostopic hz /topic_name.

rosparam set enable_statistics true is used to annotate the ROS graph with statistical information automatically.

Source

• “5.0 Hz” indicates the observed publish frequency.
• “110.0ms” indicates the average age of the message
• line color: red marks a high average age, and green is a young age.
• line thickness: A thick line means the connection has a large throughput in Bytes/s

Summary

Through this article, we have covered the following:

• Overview of ROS Computation Graph Model
• How to study rqt_graph

Resources

1. Documentation — ROS Wiki

Feedback/Suggestions:

For any feedback or suggestions, please comment below or drop a mail at ashutoshsuthar01@gmail.com, or connect with me via Twitter or Linkedin.