Table of contents
1. Introduction to ROS
ROS (Robot Operating System, robot operating system)
What is the operating system: The operating system is to provide some software and hardware interfaces, so that we can use it directly, regardless of what it does inside. Therefore, different platforms and different functions require different operating systems to complete the underlying operations.
The biggest difference between ros and other operating systems is: the communication between processes. The communication between traditional operating system processes is called by the system, which consumes a lot of system resources. But it may not be suitable for robots.
Because a robot may be composed of many sensors, each module communicates with each other to complete the specified task. Therefore, effective and fast communication between processes is a necessary requirement for a robot, and ros provides such a function.
ROS is an open source meta-operating system for robots that provides a series of libraries and tools to help software developers create robotic applications. It provides many functions such as hardware abstraction, device drivers, library functions, visualization, message passing and package management. Compared with ordinary OS, it has the characteristics that can be used for heterogeneous hardware. It also provides the tools and library functions needed to fetch, compile, write, and run code across computers. In some respects ROS is equivalent to a kind of "Robot frameworks". In addition, it also provides data transmission/reception, scheduling and error handling between most different types of hardware required by robot applications in the form of libraries. and other functions. This concept is also called middleware (Middleware) or software framework (Software framework).
Although it is called an operating system, it is not a real operating system. To put it bluntly, it is a framework and a platform. It still depends on specific operations system, now there are more Linux
2. What ROS can do
The above briefly introduces that ros can quickly complete the communication between various modules of the robot (distributed computing), and can receive and send information from different nodes.
Simply put: it can improve the software reusability in the robot development process
3. ROS characteristics
The main goal of ROS is to provide code reuse support for robot research and development
Distributed process: It is programmed in the form of the smallest unit of executable process (node, Node), each process runs independently, and organically sends and receives data
Function package unit management: Multiple processes with the same purpose are managed in the form of function packages, so it is easy to develop and use, and it is easy to share, modify and republish
Public Repository: Each feature pack exposes its feature pack to the developer's preferred public repository (eg. GitHub). and identify the license
API type: When using ROS to develop programs, ROS is designed to be loaded into the code it uses simply by calling the API
4. Features of ROS
4.1 Point-to-Point Design
Through point-to-point design and mechanisms such as service and node managers, ROS can disperse the real-time computing pressure brought by functions such as computer vision and speech recognition. This design can adapt to the challenges encountered by service robots.
4.2 Does not depend on programming language
ROS supports a variety of high-level programming languages. C++, Python and Lisp languages have been compiled and applied in ROS. ROS uses a language-neutral interface definition language (language-neutral interface definition language, IDL) to achieve message transmission between modules.
4.3 Simplification and integration
The system established by ROS has the characteristics of modularization. The code in each module can be compiled separately, and the CMake tool used for compilation makes it easy to realize the concept of streamlining. ROS basically encapsulates the complex code in the library, and only creates some small applications to display the library's functions for ROS. This allows simple code to be ported and reused beyond the prototype. As a new advantage, unit testing is also very easy when the code is dispersed in the library. A single test program can test many features in the library.
ROS does not modify the user's main function, so the code can be used by other robot software. The advantage is that ROS is easily integrated with other robot software platforms. For example, in computer vision, ROS has been integrated with OpenCV. In terms of driving, navigation and simulator, ROS has been integrated with the Player system. In terms of planning algorithms, ROS has also been integrated with the OpenAVE system.
4.4 Ease of testing
Developing software for robots is more challenging than other software development, mainly because of the long preparation time for debugging and the complex debugging process. Moreover, due to factors such as hardware maintenance and limited funds, robots may not always be available for use. ROS provides two strategies to solve the above problems.
The well-designed ROS system framework separates the underlying hardware control module and the top-level data processing and decision-making module, so that the simulator can be used to replace the underlying hardware module, and the top-level part can be tested independently to improve test efficiency.
ROS additionally provides an easy way to record sensor data and other types of message data during debugging and play it back with a timestamp after the experiment. In this way, each run of the robot can get more testing opportunities. For example, data from sensors can be recorded and different data processing algorithms can be tested with multiple playbacks
4.5 Open source
4.6 Powerful library and community
The ROS Open Source Community level is primarily about ROS resources, enabling the sharing of software and knowledge through an independent online community. These resources include:
Distribution - ROS distribution is a series of functional packages with version numbers that can be installed independently. ROS distributions serve a similar role as Linux distributions. This makes it easier to install ROS software and maintain a consistent version across a collection of software.
Repositorie - ROS relies on websites or hosting services for sharing open source code and software repositories, where different organizations can publish and share their robot software and programs.
ROS Wiki - The ROS Wiki is the main forum for documenting information about the ROS system. Anyone can register an account and contribute their own documentation, provide corrections and updates, write tutorials, and other information.
Mailing list——The ROS user mailing list is the main communication channel about ROS, and can exchange various questions or information from ROS software updates to ROS software usage.
5. Development of ROS
6. ROS Architecture
6.1 OS layer
ROS is not an operating system in the traditional sense like Windows and Linux, and cannot run directly on computer hardware, so it needs to rely on the Linux system.
6.2 Middle layer
The Linux system itself has no middleware developed for robots, so ROS has done a lot of work in the middle layer. The first is the TCPROS/UDPROS communication system based on the TCP/UDP network and further encapsulated on top of it. In addition, ROS also provides an in-process communication method - Nodelet, which provides a more optimized data transmission method for multi-process communication. On top of the communication mechanism, ROS provides a large number of libraries developed by robots to provide calls to the application layer.
6.3 Application layer
In the application layer, ROS needs a manager—Master, which is responsible for managing the normal operation of the entire system and establishing connections between nodes.
7. Communication Mechanism
ROS uses a point-to-point distributed communication mechanism to realize point-to-point loosely coupled connections between modules. All software functions and tools are built on this communication mechanism to provide users with multi-node (process) communication services. Among them, ROS The three core communication mechanisms are topic (Topic) communication mechanism, service (Service) communication mechanism and parameter (Parameter) management mechanism.
8. Calculation graph
The functional modules of the ROS system run independently in units of nodes, and can be distributed in multiple different or the same hosts, connected through an end-to-end topology.
8.1 Node (Node)
A node is a process that performs a specific task or an executable file that runs independently. Usually, a system consists of multiple nodes, and the nodes can communicate with each other through ROS client libraries (such as roscpp, rospy). Different nodes can use different programming languages, and can be distributed and run on different hosts. Node names must be unique within the system.
8.2 Node Manager (Master)
The node manager mainly plays an intermediary role in the system and can help nodes find each other. The node manager can provide naming and registration services for nodes, as well as track and record topic/service communication. At the same time, the node manager also provides a parameter server (Parameter Server), which the node uses to store and retrieve runtime parameters.
8.3 Message (Message)
The message itself is based on the topic communication mechanism of the publish/subscribe model. It has certain types and data structures, including standard data types provided by ROS and user-defined data types.
8.4 Topic (Topic)
Topic communication adopts an asynchronous communication mechanism. Topic communication is based on the publish/subscribe model, and data is transmitted from the publisher to the subscriber. Among them, the node can not only publish messages as a publisher, but also subscribe to messages as a subscriber. The publisher and subscriber of the same topic may not be unique, and another node may also publish or subscribe to multiple messages. Generally, publishers and subscribers are unaware of each other's existence. The publisher publishes the information in a global work area, and when the subscriber finds that the information is what it subscribes to, it can receive the information. Usually used for data transfer.
8.5 Service (Service)
Service communication uses a synchronous communication mechanism. Service communication is based on the client/server model. The client (Client) sends request data (Request), and the server (Server) returns response data (Response) after processing. Unlike a topic, only one node is allowed to provide a named service in ROS. Usually used for logic processing.
8.6 Actions
Action is a question-and-answer communication mechanism based on the ROS message mechanism. Based on the client/server model, the server can continuously feed back data to the client, and the client can stop running the task. The action interface is mainly composed of goal, cancel, status, feedback and result. The client can issue the task goal goal to the server before the task starts, or send a cancel request to the server to cancel the task during the task process. The server feeds back the current status of the server to the client, or periodically feeds back the monitoring data of the task running, and the result is only published once during the running of the task, and only a final result is fed back after the server completes the action.
8.7 Message recording package (Bag)
A message recorder is a file format for saving and replaying ROS message data. It uses the .bag format to save messages, topics, services and other ROS data information, and can check what happened in the system by calling and replaying the data using visualization tools after an event occurs. A recorded package file can reproduce a scene in ROS like a real-time session, sending the same data to the topic at the same time. Typically used for debugging algorithms.
8.8 Parameters
The parameter server can save some parameters as a global shared dictionary. All nodes in the system can access these shared dictionaries through the network, store and retrieve parameter names or parameter values of parameters, and the data types in the dictionary include int integer, float floating Dot type, string string, etc. The communication mechanism used for parameter storage and retrieval is the lower-level RPC, rather than topics or services. It is more suitable for storing static, non-binary configuration parameters, and not suitable for storing dynamic configuration data.
8.9 Function Package (Package)
The function package is the basic unit in the ROS software, including node source code, configuration files, data definitions, etc.
8.10 Package manifest
The function package manifest records the basic information of the function package, including author information, license information, dependency options, compilation flags, etc.
8.11 Meta Package
A metapackage is a special kind of package that contains only the metapackage manifest file. Its role is to integrate multiple function packages with the same function into a logically independent function package, similar to a collection of function packages.
Some websites of ROS
ROS official website: ROS http://wiki.ros.org/ROS
ROS introduction: https://www.oschina.net/p/ros?hmsr=aladdin1e1
ROS introduction: https://blog.csdn.net/zytgg123456/article/details/110846751
ROS introduction: https://blog.csdn.net/qq_25267657/category_8406377.html
IDL introduction: https://www.codeproject.com/Articles/19605/Basics-of-an-IDL-file
