ROS2 Tutorial
ROS Tutorial
Introduction
The Robot Operating System (ROS) is a set of software libraries and tools for building robot applications. ROS2 has different packages for setting up programmes. Usually in ROS you can create packages in CPP and Python. Here we are focused in creating in packages in Python. A python package contain different files like package.xml - which contains the meta-information, setup.py - which contains the instruction set for the package to how to compile it, </package_name – which contains all the python scripts and this directory have always the same name as the package.
For creating a ROS package, it is necessary to operate in a specific workspace called ROS2 workspace. The directory on your hard drive where your ROS2 packages are stored and accessible by ROS2 is known as the ROS2 workspace. The ROS2 workspace directory is typically referred to as ros2_ws.
For create a package, you need to work specifically in ROS2^workspace. The directory on your hard drive where your ROS2 packages are stored and accessible by ROS2 is known as the ROS2 workspace. The ROS2 workspace directory is typically referred to as ros2_ws
When you need to compile a package for it make to work. The command which can be used by ROS2 to compile is the following:
> colcon build <
This command, which must be executed in the ros2 ws directory for it to function, will compile your whole src directory.
ROS2 Nodes
Each node in ROS2 should be in charge of a specific module, such as one node for managing wheel motors, another for managing a laser rangefinder, etc. Different channels are available for each node's communication with other nodes
Source: here
In essence, ROS nodes are ROS programs. Use the ROS2 command to get a list of all the nodes active on a system:
> ros2 node list <
ROS client libraries enable communication between nodes created in different programming languages. Various ROS APIs require standard functionality, which is implemented by a core ROS client library (RCL). Writing client libraries for different languages is now simpler.
Basic Topic commands
There are different commands in ROS2 for various operations. The command ros2 topic list will prints a list which contains all the available Topics. The interface is divided into following groups.
Messages: This can be found as .msg files. The fields of a ROS communication are described in these straightforward text files. They can be utilized to create message source code. Services: which can be found as .srv files. A request and a response are the two pieces that make them up. Both are known as message deceleration.
Actions: Which Can be found as .action files. It contains three parts: a goal, a result, and feedback. All of these part contains a message declaration.
The .msg files and the msg/ directory of a ROS package are the two places where you can look for the descriptions and definitions for messages, respectively. The fields and constants sections make up the.msg files. The official ROS 2 documentation provide more details on this. You can read more about it here: ROS 2 documentation.
For publish a message to a topic, the ros2 topic pub command is used. The command structure is in the format as follows:
> ros2 topic pub <topic_name> <interface_name> <message> <
Topic Publisher: A topic is a place where knowledge can be read or written. A Publisher can now be described as a node that writes data into a Topic.
Custom Interface: Utilizing the interfaces that ROS2 already offers is always advised. Keep in mind that the ros2 interface list command can be used to view all ROS2 accessible interfaces. If none of them do, you can make a new one to suit your needs.
• Make a directory named msg inside your package
• Make a file called name_of_your_message.msg in this directory
• Change the CMakeLists.txt file
• Modifypackage.xml file
• Compile and source
• Use in your node
Service in ROS2
Services are a similar means of communication between nodes in ROS2 like topics. The publisher-subscriber model is used in Topics. And in services use a call-response type model. You can subscribe a node to a topic to receive specific information with ongoing updates, like you saw. However, a Service only offers data when specifically requested by a Client.
The structure of the command to call a Service (send a request) is as follows:
> ros2 service call <service_name> <service_type> <value> <
One example for this as follows:
> ros2 service type /moving <
Service Client
In order to create a service client, you need to create two nodes to request and respond to data through a service. Then you have to add their dependencies and executables to the package configuration files so that it is possible to build and run them. Which makes the service/client system works. Synchronous vs. Asynchronous Service Clients in ROS2
There are two types of calls a Service Client can make: Asychnronos calls and Sychnronous calls. You can use an asynchronous call using the call_async() method. An asynchronous client will instantly return future after sending a request to a service, which is a value that indicates whether the call and response have finished. The returned future can be requested for a response at any moment. An asynchronous client does not block anything when it sends a request. Then, for example, you could do a spin function and a feature check in the same thread. Asynchronous calls are completely secure and are advised for calling Services since they can be made from any location without interfering with other ROS2 activities. When sending a request, a synchronous client will pause the calling thread until the server has responded. After that, nothing else during the call can occur on that thread. The major issue is that you don't know how long it will take for the call thread to finish. This might result in a deadlock, which is the indefinite blocking of a group of concurrent system threads that are vying for communication.
Service Server
Keep in mind that you can use Services to make the nodes communicate. The node that sends a request to a service was designated as Client by the user. The Server node will be the node on the other side that responds to that request.
Custom Service Interface
To create a new Service type (srv), follow the steps below:
1. Create a directory named srv inside your package
2. Inside this directory, create a file z
3. Modify CMakeLists.txt file
4. Modify package.xml file
5. Compile and source
6. Use in code
Using of a Custom Interface
..........
.........
.........
Action in ROS2
Services and actions are pretty similar. When you use an Action, you are using a node's provided capability. Additionally, just like with services, actions are built on a client-server model. There are, however, two key distinctions between actions and services. First one is that, Actions are preemptable. This implies that you have the option to stop an Action in the middle of execution. And the other different is that actions always provides a feedback. This implies that the Server may provide feedback to the Client whilst the Action is being carried out.
Source: here
The Action Server must be present on the node that offers the Action feature. Other nodes are able to use that Action capabilities by calling the Action Server. An Action Client must be present in the node that calls the Action capability. A node can connect to the Action Server of another node via the Action Client. In summary, the workflow is as follows:
• A goal is sent from the Client to the Server. This will cause the Action to "start."
• While the Action is occurring, the server notifies the client with a feedback
• The Server responds to the Client after the Action is complete.
More information is given here: ROS2 Documentation
Calling an Action Server
Sending a goal to an action server constitutes calling it. It all operates by transmitting messages back and forth, just as Topics and Services. The message of a Topic is made up of a sole component, which is the information that the Topic provides. The request and the response are both included in a service's message. The aim, the outcome, and the feedback are the three components that make up an Action Server's message.