What is ROS
ROS stands for Robot Operating System. Although it's name has "operating system", ROS is not an OS. It's much more like a framework to develop robot applications.
This "framework" is data-centric and fully distributed, which means that it relies on the data itself to give a meaning to the system.
The system is composed of many independent nodes, which communicate with each other by exchanging messages with a pub/sub mechanism called DDS.
A pub/sub architecture is a sort of re-reading of the classical producer-consumer problem, where we have n producers and m consumers. Each node can be consuming or producing a message, and we could have a lot of messages dealing with a lot of things running through the system in parallel.
In order to keep things organized, every "parallel" messaging queue is called a topic.
So a pub/sub system works as follows:
- A publisher is a node that intends to produce a message. This publisher will publish the message in a topic.
- A consumer is a node whose job is to listen to any message of a specific topic and react to it appropriately. So a consumer will subscribe to a topic in order to be alerted by the pub/sub system that a message is available to be read.
Some famous pub/sub solutions such as MQTT usually rely on having a central node, to which every publisher will send messages and from which every subscriber will receive them.
Unlike them, DDS handles pub/sub in a different fashion, it will not use a central node to handle message exchanging, in order to avoid having a single point of failure.
Because of that, DDS is more complex than MQTT, but could also be more reliable in many situations, specially when you can't count on a full system failure scenario due to a critical central node failure.
ROS Topic
So, a ROS Topic is a virtual queue of pub/sub messages that aims to divide the robot system into small independent nodes. So, for example, the work of a sensor node could have nothing to do with what an actuator node does, even though they're dealing with the same portion of the robot.
This somehow mimics the way our body works. A nerve sensor is only responsible for sensing something (pressure, temperature...). It doesn't care about what the liver is doing or if the lungs are breathing. It's not its role.
By breaking things into small independent modules and by using DDS to make those modules interact, each modules end up being much more simpler than it would in a monolithic system.
ROS Service
A ROS Service is another form of communication between nodes. Instead of focusing on data, a service call is a call for action, equivalent of what a GET or a POST in an API-HTTP would do.
A node calls a service, which uses a service server to actually perform the action, then a response to that action is sent back to the caller.
The service calling node is the service client. We can have many clients for the same service, but only one server to handle the service calls.
ROS Parameters
A ROS Parameter is a configuration value of a node. It stores values for node settings such as floats, booleans, strings and lists. Each node maintains its own parameters.
Those parameters are usually used to setup the node at startup and during runtime without code changing. Every parameter is a key-value tuple.
ROS Actions
ROS actions are another type of communication that is intended to handle long running tasks.
This model handles all those situations where we need to perform a heavy task while keeping the system responsive. So it is divided into three parts: a goal, a feedback and a result.
The goal part is a service that will call some code to execute the long-running task. The execution can be canceled at any time
The feedback part is a pub/sub message that will inform whoever is interested in knowing what is the progress of that running task.
The result is a service that describes the outcome of an action.
A typical long-running task is performing by:
- Calling the goal service, waiting for the result
- Receiving the result of the goal request
- Subscribe to the feedback topic
- Calling the result service
- Waiting for the result from the result service. While waiting, the long-running task should publish its status on the feedback topic
- Once the task is finished, it responds to the calling of the result service done on step 4.
Workspace Environment
A workspace is a context which defines an environment for your development and testing. It's a directory containing ROS2 packages, a concept similar to the virtualenv of Python distributions.
You can also work with different versions of ROS by using different workspaces.
Installing ROS
Installing ROS is pretty straightforward. Just follow the instructions on their website. For the Galactic version, you can follow the instructions on this version's install link
What Else?
ROS is not only about process communication. The framework also provides code for process management, pre-built device drivers, some tools for simulation, visualization and data logging.
Also, it gives you an ecosystem with a lot of downloadable opensource packages that you can use to help boost your project's implementation.
Final Thoughts
This blog is not a tutorial website but can be used as an introduction tool. I just put some notes here (along with the computer vision and data science ones) of the things I'm currently studying.
Please check the next posts for more info on ROS 2 and robotics
Nenhum comentário:
Postar um comentário