A ROS system is made up of many different programs running simultaneously. Each program is called a *node*. The nodes are communicating with one another with a peer-to-peer manner by passing *messages*. That means messages are not passing through the roscore , each node just uses roscore to find each other.
Messages are just data structures:
This message is called Point. It represents a point in a coordinate system. It has three float values x, y, z. A message is like a structs or class without methods. You will use this concept a lot in the future. Anytime you want to do anything in ROS system, you have to have some kind of message to talk to the system (of course, you can create your own message which will be introduced later).
Topics are names for streams of some messages with defined types. For example, the lidar sensor(the one is spinning on top of the turtlebot) is constantly publishing message LaserScan on the topic named scan.
In ROS, there are countless topics, nodes are posting messages on topics each time(with various rate). One classic way you want to manipulate the ros system is through taking the messages from topics, making use of them and posting some messages on some topics back. In ROS, it’s called Publish and Subscribe. Lots of nodes are basically following this model.
A natural question to ask is: How do I know what topics are there? It’s nice and easy, just use command
This will list all the topics that are currently existing in the system. What I mean by that is there are countless topic, but each time in your system there are only few nodes posting messages on some topics. I just need to care about ones that are currently existing.
ROS gives a very convinient way of working with topics.
rostopic info /odom to view the odom topic.
/odom is the odometry information currently in the system. As shown in the picture, the gazebo simulator is publishing odom and the android/virtual_joystick is subscribing this and the message type is nav_msgs/Odometry.
rostopic echo /odom to view the data in real time.
keep in mind these three commands, you will use them a lot.
Services: synchronous remote procedure calls.
For topics, subscribing and publishing are all happening on where the node is running. For services, after setting up the server, when you make a service call, the computation is sent to the server which is another node. A service call would look excactly like a normal function call, except the fact that it will wait for the result from server.
The add_two_ints() is the local proxy function. It’s obtained by asking from rospy(underlying ROS system).
'add_two_ints' is the name of the service, which has been advertised before. The second parameter is the type of the service, which has to be defined before in a similar way as defining messages. The the call
add_two_ints(1, 2), is actually sent to other node to be computed. Read more.
The ROS system takes care of all the communication behind the scene. It’s a good way to distribute the computation workload. Service calls are well suited to things that you only need to do occasionally and that take a bounded time to complete. For example, letting the robot navigate to a destination is not a well suited task for the service model, since you have no idea about when it can be done or if it can be done and you don’t want to wait at the service call forever.
Actions are designed to solve this problem:
ROS actions are the best way to implement interfaces to time-extended, goal-oriented behaviors like navigation. This will be introduced more throughfully in the future talk - Navigation in ROS. An action is defined with three part: goal, result and feedback. Each of them is some kind of data structure. Usually, actions, services and topics uses the same set of data structure for a easy communication. For actions, it’s like service model, you have to have a server which is another node. The server will take a goal, react accordingly and send back a result. Also, you can set up a feedback which will be sent back to the client.