I haven't used ROS for almost a year, but even so, if someone asks the ROS blog that I wrote before, they will still answer it very carefully. Combining these issues, plus some previous experience and experience, make a simple sorting and summary.
table of Contents
2.1 A preliminary exploration of ROS
2.2 Simple development and understanding of ROS
2.3 Application and development of ROS
2.4 ROS development experience
1 Robot
Robot research has always been a hot topic in major laboratories and research institutes, and it involves many subdivisions. It is cutting-edge, high-end, challenging, and often a combination of multiple disciplines, making it easier to collide with sparks of innovation. Later, the company began to continuously invest in development and product launches. I think it is related to two factors:
1. In 2015, the two sessions put forward the concept of "Made in China 2025" to improve the intelligence of manufacturing. Then, on March 31, 2015, the "OFweek 2015 China Robot Industry Summit Forum" was successfully held in Shenzhen to promote the further development of the robotics industry. Robots are an important force in the manufacturing industry, so a large number of companies have established robotics research institutes, and a large number of robotics startup companies have emerged.
2. The vigorous promotion of ROS at home and abroad, the emergence of ROS has indeed reduced many obstacles to making robots. And because of its open source, a large number of algorithms and drivers can be found in the ROS community (wiki.ros, GitHub, etc.), which has almost become an excellent model for robots. So for developers, you can focus more on what you want to achieve; for researchers, you can better optimize the algorithm. The following focuses on the development experience using ROS .
2 ROS
2.1 A preliminary exploration of ROS
When I first started ROS, I confirmed that it was a bit troublesome. First, it runs in the Ubuntu environment. Although ROS2.0 can now run under Windows ( summary of ROS exploration (55) -Windows version ROS installation trial ), but still use Ubuntu to compare the original ecology, and the Ubuntu system is free, and the real-time performance is relatively high. Some people may be discouraged when they look at linux programming. One is not as convenient as the visual operation under Windows, and the directory structure and file attributes are also very different; second, there is no Visual Studio, the best IDE in the universe, and many breakpoint debugging are very troublesome. In fact, there are many installation tutorials on the Ubuntu system on the Internet. It is really impossible to install a virtual machine under Windows. Regarding the use of operating systems, most of them are carried out in the form of command lines or scripts. You can read the book "Niaoge's Linux Private Kitchen". The commonly used instructions are mainly those (it shouldn’t be too many people to go deep into the meaning behind the instructions, this is related to the Linux kernel, the deeper you dig, the deeper you may deviate from the direction), and the instructions that you don’t understand will be checked when encountered Learn quickly. In fact, for software developers, being able to write scripts is a very important skill, and foreigners are very fond of using instructions to operate, and I have seen that many major developers have also made many scripting tools under Windows to compile and debug. , Testing, etc., it can batch a lot of things and reduce a lot of repetitive things, so you have to learn to use more instructions or scripts to operate as much as possible.
After installing and having a general understanding of the Linux operating system, you can install ROS. For installation instructions, please refer to http://wiki.ros.org/ROS/Installation . Basically, the operation is based on a gourd. However, before the use of ROS, can ROS official website look on, look at ROS is probably how it is. Or refer to Gu Yueju 's blog. His blog has a system explanation of ROS and many technical sharing. In order to install ROS faster, we generally switch to domestic mirror sources such as Tsinghua University . The installation of ROS takes about half an hour. After the installation, you can start the ROS journey. But before we start, we can think about some more questions, such as what does /etc/apt/sources.list do and where are the downloaded installation packages? /etc/apt/sources.list is the configuration file used by the package management tool apt to record the location of the software package repository, as well as the files located in /etc/apt/sources.list.d/*.list. The software package downloaded through the apt-get command will be placed in the /var/cache/apt/archives directory. The deb format is an exclusive installation package format for Debian systems (including Debian and Ubuntu), and it is a very popular installation package under Linux in conjunction with the APT software management system. Knowing this will be helpful for later software release and deployment under Linux.
2.2 Simple development and understanding of ROS
The primary tour of ROS mainly starts from the ROS tutorial . It is almost like creating messages, broadcasting topics, and writing services. Most textbooks and blogs on the market also take this as an example and expand it. There are too many ways to write code. Of course, the simplest and rude is to use gedit, but for the convenience of jumping and readability, there is also http://wiki.ros.org dedicated to the IDE on the wiki. /IDEs , just choose one you like. I recommend QtCreator. For how to configure it, please refer to " Three Methods to Load Qt Library in ROS for GUI Design ". I have been exploring this configuration for a long time.
If you customize message publishing, save loading parameters, write services, use some commands to view ROS status such as rostopic, rosnode, rosparam, rossrv, rosservice, use some visual gadgets for analysis and monitoring such as rqt_graph, rqt_reconfigure, rqt_plot, rivz, rqt_console, etc. , Then the learning of ROS is progressing well. I believe that everyone will encounter different problems and pitfalls when using the above tools. However, you are not afraid of problems. The key is to solve them and enjoy the process of solving them.
We can also think about two more questions, 1. What is the core framework of ROS and how it implements these mechanisms (topics, services, etc.). 2. What is catkin_make and what role does it play.
2.2.1 ROS core framework
For the first question, I haven't studied the source code carefully. The core code is basically composed of python and C++, using the xmlrpc mechanism, and each running node can be understood as a process. Some of the inter-process communication is shared memory (such as message_filter), and some should be through sockets. However, the core framework of ROS, ros-base, is mainly designed, provided and maintained by Willow Garage and some developers. It provides some basic tools for distributed computing.
sudo apt install ros-melodic-ros-baseThe distributed computing framework can be understood as all nodes of ROS need a main controller ROS Master (opened by roscore command) when running. ROS Master provides registration list and other calculation charts through RPC (Remote Procedure Call Protocol) Find. Without the controller, the node will not be able to find other nodes, exchange messages or call services. The connection between nodes is direct, and the controller only provides query information, just like a DNS (Domain Name System) server.
The framework of ROS is quite complicated, and some theoretical introductions may have some concepts, but there must be many details in the actual implementation.
When actually applying the ROS framework, there are actually some shortcomings, such as
- When ROS nodes communicate with each other, how do they know the status of another node, whether it is down or normal, because it strongly depends on the central node ROS Master. Frequent creation of topics in the system itself is not a good thing, it will cause much memory fragmentation. When using ros::Subscriber sub = n.subscribe("chatter", 1000, chatterCallback), this 1000 is the number of message buffers in the queue. If it is an image or data with a relatively large point cloud, don't just write 1000, otherwise The memory will be consumed.
- When there are a large number of topics and data in the system, the delay of local data transmission is large and uncertain, and the data transmitted remotely is more affected by bandwidth and processing performance. For robot control, if you want to achieve more precision, the communication delay must be made smaller, and the real-time and stability of the communication mechanism of ROS is not very good.
- The msg of ROS uses md5 code to verify. If one person changes it without notifying the other person, it often leads to the embarrassing situation that the other person's package cannot run.
- When ROS communicates with the visual interface, sometimes it is not known whether it is the interface or the ROS mechanism, and the interface will crash inexplicably (rviz often has such problems).
- Regarding the saving of dynamic parameters of ROS, such as how to load the adjusted parameters after restarting roscore after adjusting the parameters in rqt_reconfigure. I have spent a long time, see " Processing yaml files in ROS " and " C++ Python implementation of ROS dynamic reconfigure client and server ", but it has not been solved well. Many functions may only be suitable for developers, but there are still many places worth optimizing to use as a product.
2.2.2 catkin workspace
The second question is also very important and critical, just like how to create a VS sln project and compile and run it, how to create a pro Qt project, how to create a nodeJS project, etc. catkin_make acts on a workspace of ROS. The workspace contains a standalone ROS package. See http://wiki.ros.org/catkin/workspaces , which defines a ROS development specification or a ROS project What should be included in it.
Catkin_make can be understood as another encapsulation of cmake. When compiling CMakeLists.txt, a syntax adapted to the ROS framework is added, such as catkin_package, add_message_files, etc., and most of the rest are the same as cmake syntax. So in addition to using IDE to build projects, learning to use cmake is also an essential skill for developing ROS. In the beginning, C++ programs were compiled directly with g++. When the program scale becomes larger and larger, there are many folders and source files, and the input compilation instructions become longer and longer, especially when it involves dependent system libraries, third-party libraries, and An efficient and convenient tool is even more necessary when defining a library. Therefore, some rules are written to deal with compilation problems in the way of makefiles, but for a large project, writing makefiles is a complicated matter, so cmake tools are available. After it reads all the source files, it automatically outputs various makefiles or project files, followed by the compilation of CMakeLists.txt files, according to the rules of cmake. cmake is cross-platform. I think this is one of the reasons why ROS is compiled based on cmake. I have tried to compile the ROS project with cmake and make, it is also possible, please refer to the ros_cmake project at https://github.com/WelinLee/ROS_QT_GUI .
Secondly, we need to have a certain understanding of the namespace and naming conventions of ROS programming. This does not refer to the C++ namespace or scope, and it is a detail to pay attention to when communicating between ROS nodes. For example, some nodes have "/" or "~" before their names, see http://wiki.ros.org/Names for details .
| Node | Relative (default) | Global | Private |
| /node1 | bar -> / bar | / bar -> / bar | ~bar -> /node1/bar |
| / by / node2 | bar -> /wg/bar | / bar -> / bar | ~bar -> /wg/node2/bar |
| / by / node3 | foo/bar -> /wg/foo/bar | /foo/bar -> /foo/bar | ~foo/bar -> /wg/node3/foo/bar |
2.2.3 Extension of ROS
In addition to its own framework of things, the biggest feature of ROS is that it can integrate many other things to form a complete robot development ecosystem. No wonder ROS is called the robot operating system, and its mission to power the world's robots is no exaggeration. The extension of ROS, the ROS universe, is a global code that is developed and maintained by ROS community organizations in different countries. Some are library codes, such as OpenCV, PCL, etc.; the upper layer of the library is the code provided from a functional perspective, such as face recognition, navigation, etc., calling the lower-level library; the uppermost code is the application-level code, allowing the robot to complete a certain One definite function. ROS is really all-encompassing. Various libraries and functional frameworks can be incorporated to make it more and more powerful. There are generally two ways to use third-party libraries:
- One is to add through the cmake method. Some libraries, such as Qt, OpenCV, PCL, etc., may be nested in when you download ROS directly, and you can rely on these libraries directly through the environment variables of ROS. But I prefer to keep the ROS framework unchanged and download and install other libraries separately. Because the third-party library downloaded through ROS is generally incomplete or the version is wrong, which leads to limited development, etc., it is best to install the third-party library directly and then use cmake to find the location of the third-party library installed on the machine (find_package), so that the library and the library are The relative relationship between them is very clear. The basic framework of ROS has not been filled too much, and it can be kept relatively clean, and it will not be bothered by not being able to find environment variables. The interdependence of ROS and third-party libraries has probably troubled many people. I often spend a lot of time on library dependencies.
- The other is to allow third-party libraries to add some interfaces to adapt to the ROS framework, which is to make a ROS package. Some manufacturers, such as lidar or some CAN bus protocols, directly provide a ROS interface, which can be easily used. It can be said that basically most of the mature algorithms (manipulator arm forward and inverse solution, SLAM navigation, point cloud, image processing, etc.), sensor interfaces (sick, kinect, etc.), communication protocols (EarthCAT, CANOpen, USB, etc.) can be used in Found on ROS wiki and GitHub.
2.3 Application and development of ROS
Through the study and practice of Section 2.2, we should have a certain concept and understanding of robot development in the development of ROS, and know how to build a robot framework. Generally speaking, the development of robots on the market is divided into two mainstreams, one is mobile robots (AGV), which should mainly be hotel delivery, restaurant navigation + food delivery, warehouse logistics, banking processing, etc.; the other is collaborative robots, six freedoms Degree, used for grasping, welding, etc. Of course, there are also the combination of these two to form a composite robot that can be transported and grasped. In some small directions, there are humanoid robots and drones.
Take the development of AGV as an example . For AGV, especially for indoor applications, the most important thing is map construction and navigation, which is SLAM technology. There are three main areas involved:
- Map building, such as gmapping, hector_slam, and cartographer algorithms, builds maps by collecting point cloud data. The point cloud data here is generally a specific plane, how to sick tim571, Pepperl+Fuchs R2000, Radium and other sensors can achieve this function, and provide the corresponding ROS package, or convert it to kinect, realsense three-dimensional sensor Two-dimensional data. Regardless of the sensor, unlike the interface, the lidar is generally in the form of a network port and forms a local area network with the running Ubuntu computer, and the 3D point cloud is generally used to obtain data from ROS through USB or serial communication. So the advantage of using ROS is that you don't have to pay too much attention to the definition of hardware interfaces or even physical interfaces. For the use of ROS mapping package, I have detailed instructions in " Interpretation of slam_gmapping and map_server source code in ROS and the use of librviz ".
- For positioning, the AMCL algorithm is commonly used, that is, the current position coordinate information of the robot in the map obtained for the above-mentioned mapping. Because it is a two-dimensional map, the data obtained are x, y coordinates and direction angles. AMCL packages are generally combined with navigation packages. It is listed separately here to illustrate that there are other positioning methods, such as light reflection navigation positioning, ultrasonic navigation positioning, wifi positioning, etc. There is a good summary of the blog " Navigation and positioning technology and principles commonly used in autonomous mobile robots " for reference.
- Navigation and path planning, that is, move_base package, which also contains local path planning, global path planning, dwa path search and costmap_2d. Regarding the calls between these packages, there are too many such pictures on the Internet, and I don't need to post them again. Costmap is the algorithm proposed by David V. Lu , that is, the cost map. Its core idea is to expand the map including the robot itself to a certain extent, that is, to reserve a certain space to consider the size of the robot, otherwise when driving, Especially when turning, the robot will collide with obstacles. Regarding the application of costmap, especially adding the layer you want, Dr. He's family has a good practice, see " Navigation of ROS Tutorial: Creating Costmap Layer Plugin in Catkin Environment ".
With these packages, can the robot run? The answer is definitely no, but at least these packages can be simulated in Gazebo and rviz, and the effect seems pretty good. However, the difference between simulation and reality is still too great, such as the data collected by lidar in the real environment, and the map established in the real environment. In addition, building a small robot system will go through a very painful process from hardware selection to successful debugging . In order to get started quickly or verify, you can start with some ready-made robots, such as TurtleBot . But these are more suitable for laboratory research, such as algorithm verification. It also has certain reference value for the real development of robot products.
Generally speaking, the system architecture diagram of AGV is as follows:
It can be seen that the main core control is running on an industrial-grade computer in Ubuntu. The lidar is basically a ready-made module. The voice system is generally an optional module. There are many such modules, such as iFlytek, etc., according to project requirements . Equally important is the sensor acquisition module, that is, the ARM layer or the PLC layer. This layer is mainly used to collect peripheral data including motor drives and report to the ROS layer, so this workload is also very large, and the communication protocols involved are also More. The most important thing is the communication between the ARM layer and the PC. Both the transmission rate and the stability of the protocol have to be verified. The sticky packets that were caused by the communication protocol are also very difficult to locate. So try not to use your own protocol, and use stable modbus 232, CANopen bus, etc. are better choices. Regarding the issue of communicating with the hardware, to quote a foreigner, I think it is more stable to follow this principle, especially in the process of loading the hardware initialization.
A way to enable a correct sync -> the HW should wait to send the ackknowledge until they really finished the write procedure. That's it what an acknowledge to a write call should stand for: "Understand, verified, operation done". With this double sync solution we can track all misbehavior and implement correct reaction to that in the system software.
Secondly, AGVs generally have a two-wheel or four-wheel structure, and the selection of drivers and motors is also very important, otherwise the cumulative error caused by the odometer will affect the mapping and positioning accuracy. Now there is a company that specializes only in AGV controllers, that is, the ROS layer and the ARM layer in the picture ( note: it may not necessarily be the ROS framework used ). The controller itself is reserved for IO and can be adapted Certain 485 protocols and control certain types of motor drivers, in addition to other modules can be directly plugged in, and a variety of external interfaces are also provided for secondary development. Therefore, customers focus more on the application layer, that is, HMI, such as mobile phone applications, web displays, PC software, etc. This secondary development generally uses C/S or B/S architecture. I saw a good example of the human-computer interaction interface for AGV debugging is Ros_Qt5_Gui_App (searching ros qt gui on GitHub is ranked first to me).
Finally, there is the structural problem. I don’t know if it’s because of the influence of Internet giants such as Tencent, Alibaba, NetEase, ByteDance, etc. We are paying more and more attention to software development, thinking that the development of ROS layer and embedded layer is the key . In fact, for manufacturing products, industrial design and structural design are very important. No matter how good the software is designed, even a slight deviation in the size of the structure will cause the machine to run unstable. The definition of the urdf model file in ROS is also related to the structure of the design (size, location, etc.). In addition, the structural design needs to consider whether it is easy to install, maintain, replace parts, AGV balance, precision, beauty, etc. It is not an easy task.
Regarding development debugging , ROS is easy to get started but debugging is difficult. One is the lack of single-step debugging. The method I currently see is to use the GDB debugger, but it still feels very troublesome. It doesn’t require too many people and more bug debugging. Still through the log view. Second, because of the various communication interfaces designed in ROS, serial port debugging tools, TCPView, wireshark, CAN analyzer, etc. are all commonly used tools.
Regarding the development of ROS, especially those complex algorithms, I personally feel that it is more practice and application. It is rare to refactor and write a new algorithm to extract some key information for visualization research or improvement and optimization. . For example, the following technical issues:
Finally, summarize some good information about the development of ROS, which will be often used in the ROS development process:
- For things related to the ROS core framework, you can find the source code on https://github.com/ros.
- Use ROS for some visual analysis, graphical interface operations, etc. You can find the source code on https://github.com/ros-visualization, mainly the combination of ros and qt or pyqt, which is very helpful.
- ROS is mainly to solve the problem of robot control. The navigation open source library can be viewed at https://github.com/ros-planning/navigation, and the robot arm planning corresponds to the moveit package.
- Sensors are indispensable for robots, which is the perception system of robots. You can view a large amount of source code at https://github.com/ros-perception, such as the use of opencv, the use of point cloud library PCL, laser, IMU data collection Wait.
2.4 ROS development experience
Through the description of ROS development in the previous three sections, we will find that using ROS to build a robot requires a lot of things to master, such as Linux related instructions, cmake syntax, setting of various environment variables and loading of the third library, C++/python, The use of boost/STL library, log recording and analysis, the use of various small tools, understanding of various communication protocols, networking, how to build a simulation environment, software version management and packaging, research or testing related algorithms, etc. There are constantly new things to explore. In this way, it seems that it is more interesting and challenging than pure front-end development, mobile phone application development, game development, and automated software development. Therefore, people who have a little idea and want to do something find ten or twenty like-minded partners to set up a robotics company, and they keep catching up with robots. So I think the emergence of ROS has made robot development better and better, and it has made many people realize what robot development is all about and how to develop it. At the same time, on the other hand, I think the emergence of ROS has lowered the threshold for robot development. Why do you say that? I used to think that making robots is a very high and difficult task. Now there are a large number of robotic startup companies in Shenzhen alone, and a large number of companies have established robotics divisions or research institutes. Unlike certain things such as chips, precision sensors, PLCs, CTs, etc., there may be just a few or a few in the world. Ten companies can do it, which means that you don’t know how to do it after you see it, and you don’t even know its system architecture and production process. These are the things with core competitiveness and challenges.
It takes a long time to develop a robot and must work hard. For example, in the AGV system block diagram drawn in Section 2.3, a lot of aging tests are required for each link, software and hardware communication, and performance testing of industrial PCs. Especially for industrial routing, because the debugging of AGV is generally independent of a single car body, and it moves around, the active area is relatively large, and it is difficult to test with wired connections, so the reliability of the deployed network is very high, especially when it comes to When multiple AGVs are running. In addition, I think indoor laser navigation also has its limitations or technical bottlenecks. It is more suitable for relatively regular static scenes. For scenes with tables, chairs and people, the accuracy of the mapping will be low. The map is also compared with the previous few days. There are differences that lead to inaccurate positioning due to the movement of some obstacle information. For a relatively large area, it is also a painful process to rescan the map and redesign the path every time, add location information, etc. In addition, every time slam scans the map, I feel very awkward. I always feel that the customer experience is not friendly. There are always people who cannot see that the information on the map corresponds to the actual location.
Secondly, DevOps (Development and Operations), the collective term for processes, methods, and systems, is used to promote communication, collaboration and integration between development, technical operations, and quality assurance (QA) departments. It can be understood as a development model. This is a concept that appeared in 2009 and has now covered a very rich content, including organizational culture, automation, lean, feedback and sharing and other different aspects. This concept is widely used in large factories, especially Internet companies, which is a change of development model. The waterfall development was more popular before. That is to say, R&D personnel conduct cross-references at the agreed time point according to their needs. The frequency of iteration is once a month or once a quarter. R&D focuses on functional development. After the function development is completed, the test team is delivered to the test team for testing. After repeated testing and problem repair, the test team is delivered to the operation and maintenance team to go online. After that, the availability and stability of the production environment are responsible for the operation and maintenance. The problem with this development model is that the requirements cannot be quickly verified. It is very likely that the things that the team has spent half a year to develop are no longer suitable for the market. There is also a possibility that the R&D requirements are not well understood during the development stage and wait until later. If there is a problem during verification, make adjustments and delay the overall construction period. At present, the more popular development method is the agile development model, which is used for frequent demand changes and rapid development. The more popular cases are Scrum and XP Extreme Programming. Before the start of the new iteration (generally 2-6 weeks), the product manager splits the requirements into specific development tasks, the R&D personnel claim the tasks, and the daily stand-up will review the tasks until the development is completed and a new usable version is released.
Finally, we must do a good job of a robot product, and the four links of R&D, production, supply chain management and after-sales service are indispensable. Many robotics startups have to invest more in the R&D and testing phases. Even if the demo is very beautiful, why is it difficult to produce robotic products? One reason may be that the market demand is not so great. The second reason I think is that R&D is too far away from the next three links, or it hasn't reached that point yet. For example, the transfer process from R&D to production is a very important indicator. Whether the product development is good or not, just do a test. Let the R&D personnel personally assemble 10 devices he developed. If he feels that the installation is still relatively smooth, and the correlation of these 10 operation is similar, and can run continuously for more than 72 hours without failure , Which shows that the product is not bad in design or reliability.
Quoting Gu Yueju's words to summarize the development of robots with ROS: The robots do well, not necessarily because you use ROS, and the robots do not do well, nor are they necessarily because you don't use ROS . If we are poets, then ROS is a dictionary, which provides us with many beautiful characters, of course, there are also many words and sentences, but you can't copy the original sentence when you write a poem. Whether you can write a good poem depends on the poet. Talent. This is also the reason why Gu Yueju embarked on ROS promotion and training. ROS is a bit like a teacher, taking you into the world of robotics, but the master leads the door, and the practice is personal.
3 Future Outlook
There are too many articles about the prospect of robots. I am not a person who likes to talk about macro things. I focus more on technical details. Talk is cheap, show me the code. In fact, there are many AGVs, such as the research on the navigation method of a single AGV, so that one controller can adapt to multiple navigation methods; the scheduling research of multiple AGVs, and the material information of the factory or warehouse at the same time; across floors, The transportation of AGV between buildings. In short, there are too many subdivisions worth exploring and thinking, too many technologies worth breaking through, and the industries involved are not limited to one or two. AGV manufacturers cannot be limited to selling only one or one model of products. It is difficult to promote. They must provide a complete set of solutions to form an AGV ecosystem. In other words, the AGV industry has been developing for more than ten years, and there is no special unified standard. The market is mixed, and there is still a blue ocean ahead. I believe that there will be robots or AGVs that will promote the development of the entire industry in the future. It is similar to Apple leading the development of the mobile phone industry, Siemens leading the direction of industrial control, Google leading the direction of Internet development, and Tesla leading the direction of new energy vehicles.
Regarding the dynamics of the entire robotics industry, which company has produced what products, what investments have been received, and what new applications are there, you can look at the Advanced Robotics Journal or the public account published by the Advanced Industrial Research Institute, which is very detailed. The analysis is also in place.
LWL in Shenzhen