The main problems of VIO SLAM in engineering implementation and commercial closed loop in the field of robotics

The VIOBOT-PRO development platform has had quite good shipments recently. It has been busy testing and has not done any updates. Thank you to all users and partners for writing this article carefully. My writing is generally very boring, and I tend to get immersed in my own world, and I am trying to make changes.

To avoid dyslexia, some simple explanations:

Triphasicity : Overhead/robustness/accuracy

World view : 3D mapping, real-time and offline

Vector machine : A non-abstract finite vector machine, which is a more realistic representation of hardware and generally refers to hardware cores or devices built in GPU/DSP or other forms for vector and real-time operations.

NPU : Neural network unit, used to build AI-related functions on the SOC side, and can also be used to decompose some functional modules in SLAM.

VIO/IVO : IVO is also made up by myself. It mainly distinguishes the difference between visual and imu-led systems. In fact, there is indeed a difference.

RTOS : Bare metal environment, which enables the system to run with better real-time performance and makes development more difficult.

1. Market segment

At present, the main market for VIO/SLAM is highly concentrated in the fields of autonomous driving/XR/robots .

Autopilot. . . good Q difficult

Play the cool and fast YVR of your dreams

There are currently a lot of scenes that VIOBOT is working on. . .

The biggest feature of the first two vertical markets is that they are difficult to

Among them, the XR field requires extremely strong real-time performance (such as a response of more than 50fps for the Body system). It also requires the main SOC to perform a large number of application calculations, leaving VIO with very limited computing power. At the same time, XR equipment involves many sensing parts. , the calibration is also more complex. Most positioning in the XR field relies on VIO. The good thing is that it does not involve too much loopback and map management.

Autopilot. . . Everyone knows how difficult this is. Serious industry, massive calibration data and target recognition, HD maps, a lot of semantic segmentation, BEV, more than 6 CAM/Lidar and multi-source fusion bring about the most difficult calibration, either extremely dependent on lidar or calculation Endless hunger and thirst. Especially L4, it is even more difficult.

Robotics is one of the most interesting fields, but it also has the following difficulties and problems:

(1) AGV type for large space fixed range operations (such as airports, ports)

This is a rigid need , and its essence is very similar to autonomous driving. The simple part is that the target objects and driving areas are no longer so complicated. The difficult part is that the travel route is very fixed and strict , and the requirements for accuracy and map management are extremely high. This type of operational radar and high-precision a priori maps are a must.

It cannot exceed the left and right lines on the ground. . . troublesome scene, mmp

(2) Fixed-range operating robots in small spaces (such as warehousing and logistics robots, commercial cleaning, lawn mowers, inspection robots, etc.)

Each of these businesses has its own characteristics. The perception and planning of warehousing and logistics robots are closer to the first type, and the control will be more complex.

Hairou rushes, be careful next door Haikang~~

The biggest difficulty for commercial cleaning robots is to achieve or approach the cleaning effect and efficiency of humans (which is difficult), and at the same time, customer needs are easy to diverge .

Gao Xian is quite handsome in this little car~~

Overall, I am more optimistic about lawn mowing robots . Although it is currently at a trough, it has a series of advantages in terms of scenarios. As long as it is not overly divergent, it is easier to proactively guide user needs and participate in industry standards.

In fact, I really want to release a domestic product. . . It’s better to forget it, so as not to start a war.

Generally speaking, business (2) has a great opportunity to use VIO as the main sensing unit in multiple scenarios to close the loop, just like us humans, right?

(3)UAV

Although there is leading DJI in this area, I think it still has a bright future. The top view gives humans a broader imagination and gives us more work possibilities!

However, when designing VIOBOT/PRO and communicating with user partners, we will be more inclined to use our eyes and front-end computing power to close the loop at close range/indoors . If it involves aerial secondary operations , such as maintenance, jetting or even direct delivery of goods For matters like this, it is recommended to first check whether there are any funds in your account that cannot be spent. . . At the same time, there is no need to be limited to 2B or 2C, there are many worlds in the sky.

TANGO and UAV, so cool!

(4) Small robot

This is the most promising business for our team in the long term. Businesses such as Astro/Loona/Ring are all imaginative implementations. In the future, robots like WALLE will play various roles in production and life.

Sand sculpture Astro. . . Looking at 2 Xixi

So cute Loona

In fact, there is a Greater Bay Area version, and the original version is also very controversial, and everyone complains about it. Come and subvert them!

WALLE, my favorite, EVA is so ugly

You need to think carefully whether it is a pet , a toy , a tool , or a robot . How do the attributes between them change and integrate? They do not require cm mm level accuracy . What they need more is confirmation of their own basic posture and basic understanding of the surrounding world.

Recently, many small partners working in this direction want to use closed-loop SLAM at extremely low cost or directly on the local SOC, which is not to say that it is impossible. But if you can easily close the loop by just setting up ORB-SLAM3 or the original solution, it may not be a bit too underestimating the technical difficulty. . . The current stage has not been reached, but of course it will be reached. This requires the joint efforts of everyone (scientists/engineers, upper, middle and lower reaches of the industry). Generalization is never a bad thing for industries and businesses, but my country's inexplicable involution environment has given everyone too much anxiety. In addition, if the world view and observation direction are not required, a random sweeper solution will be more in line with the requirements, but it is still difficult to achieve.

" Ignorance is not an obstacle to survival, arrogance is "

Another more important reason is that if the cost is locked and defined at the beginning , it is equivalent to locking up the overhead and the possibility of development. Although VIOBOT-PRO already has a complete VIO-SLAM, its design still provides a large amount of redundant heterogeneous computing power space. As a development platform, it has the possibility and value of deepening development. Dual-core A55 and 4-core A7 can actually also close-loop VIO, but they can only guarantee three-phase performance to a certain extent.

On the other hand, if a group of scientists and researchers continue to push VIO/SLAM in a more positive direction, it will also become an obstacle to the development of the industry (pure VIO cannot fully achieve the absolute accuracy of radar, and heaps that do not count the cost are wrong direction). When a hundred flowers bloom and a hundred schools of thought contend, VIO/SLAM and its corresponding industry development will be more meaningful and cool.

Maybe there will be new Huawei/Hikvision/DJI companies in the future, but this should be a thing of the past 10 years. The GAP between science and engineering is now too large. We should strive to continuously bridge and bridge it in the market and in the transformation of scientific and technological achievements, and open up a new world step by step. Don’t always think that you can form a new monopoly. The world is so big, are you a DER? This is also for our small midstream group to listen to.

In addition, regarding the recently popular embodied intelligence (humanoid/emotional companion pets) and humanoid robots, what I want to say is that large models and the future lightweight Edge Transformer will indeed bring and will bring huge changes to the industry . , but scientific research and engineering have always been two different things. It is doubtful whether it is really possible to overtake in corners when carried out across stages. But it is true that we have done a lot of miracles in the past. I hope everyone goes well.

2. Engineering part

The writing is mainly based on logic and facts , as well as the experiments and exchanges we have conducted. The purpose of this article is mainly to discuss the problem . It does not mean that our group has closed all relevant problems. In fact, some of the problems are extremely difficult to solve . .

The main difficulty revolves around the three-phase nature and the world view . These four things have been repeated many times so I won’t go into details. Today I will mainly talk about the specific ones:

Difficulty in generalization

(1) Basic issues of feature point method/direct method in VIO

The first problem of the feature point method is sparseness . Sparseness cannot bring an effective world view. If you need to bring an effective world view, you can only use means (such as Mesh), but Mesh itself based on feature points has problems that are difficult to solve unless it is updated. Strong semantic means - source of knowledge points: Dr. He Jia, Dr. Xu Hao).

Isn’t it wrong to always use ORB as a counterexample? . .

The second problem with the feature point method is the weak response in low texture areas , resulting in a high dependence on imu.

Poor ORB2

The third problem of the feature point method is the high overhead of point extraction and matching itself , but this part can be completed relatively easily through vector machine/NPU heterogeneity.

The first problem with the direct method is the photometric problem caused by assumption 1 ( photometric invariance assumption ). Photometric is almost impossible to effectively manage, although there are already corresponding active exposure methods.

The second problem with the direct method is the outlier caused by assumption 2 ( quantity overwhelms quality ), which is also difficult to effectively handle and is a reflection of the basis of the algorithm.

The third problem with the direct method is that it is difficult for imu to play a suitable role in it, although there is already a standard example of DM-VIO.

Only a perfect camera can display the perfect direct method. Outlier can be minimized but cannot be generalized.

(2) Problems with AI in SLAM

The first is NERF/Mobile NERF : The main problem is heavy, but it must be the main direction in the future. It will be widely concerned by scientists for a longer period of time, and will become a dominant part in large-scale three-dimensional reconstruction, but it really falls into place. There is still a long way to go to robot/XR-type SLAM.

Cool picture source: Friend Kun, who is silent

Then there's superpoint/unsuperpoint, superglue/lightglue . The former is quite excellent purely in terms of points/descriptors (scores). At the same time, NPU heterogeneous closed-loop can also be used with a smaller footprint, and the latter provides a more powerful matching method. Can play a very important role in SLAM

Extremely cool Lightglue

But there are also problems: Quote by Ada: "The front-end point raising, whether it is the geometric method or the network method, is not accurate enough and the introduction of errors is not even just in point raising and matching. Image photometry is very complicated to accurately raise points. It is completely impossible. That is to say, Outlier will still exist for a long time. In essence, it is just a super powerful ORB. The main role it can play is heterogeneity (ORB can also be heterogeneous easily). What really works better is loopback. It also requires unique training and models , which is also a generalization barrier.

In addition, raising points and matching itself only completes a small part of the work. There are still problems of how to couple the I MU and back-end optimization . It still relies heavily on the computing power of the CPU itself, and the problem has not been effectively solved.

At the end of this chapter, I will specifically talk about the difference between vector machines and NPUs . This is also the main bifurcation for the backward development of SOC in the future. Currently, only Nvidia and AMD can satisfy both, and the NV ecosystem is better.

Vector machine : Using GPU/DSP or FPGA specifically for Vectors processing, or even ASIC (refer to Navion above), or even specialized CPU to perform vector operations and acceleration in SLAM, is a derivative of the traditional method. It is very difficult and involves a lot of RTOS and C language. The GPU is slightly better and the CUDA ecosystem is quite friendly.

NPU : SLAM is completed through neural networks. The existing problems have been mentioned above.

In the future, competition between the main genres of VIO-SLAM and the hardware that carries it will occur between the two. but. . .

My old club is my spiritual harbor

The area of ​​any chip is limited, and it is difficult to have both vector machines and NPUs. First, the process of mid-to-low-end SOC (3-20 US dollars) ranges from 12-28nm. When carrying an NPU (generally 2-4T in this price range) When the main core is strong, it can only shrink the main core CPU and other vector machines such as DSP/GPU. When the main core is strong, it can only shrink the NPU area. Some suppliers directly castrate L2/L3 cache to close the loop on cost and area.

At present, if my country's main SOC has a powerful NPU, such as 20-90T, its main core and vector machine must be very bad, and may castrate the cache.

So SLAM produced two paradoxes on the end-side NPU main line :

1. If you want to close most of the SLAM work on the NPU side of the mid- to low-end SOC, the remaining NPU computing power will not be enough to close other AI applications, and the backend will occupy limited CPU resources.

2. If you want to implement closed-loop SLAM on a high-end strong NPU main core, there will be insufficient main core computing power, leading to a high degree of dependence on the original factory (most of the powerful original factories work in the end-side NPU closed loop, such as Tesla, and also in China) . There is no long-term development space for small, medium and micro enterprises.

At the same time, most domestic suppliers of NPU use the public version, with very poor power consumption and performance. Only a few manufacturers have closed-loop independent NPUs.

Finally, the conclusion: "This main line, the project will not be enough to close the loop VIO-SLAM for a long time."

Stealing pictures~~ la la

(3) Scale problem

The three-phase nature and world view are based on effective scale/gravity and light control, and these three are also the biggest obstacles to the universal generalization of VIO.

Regarding scale , first of all, it is difficult to manage the scale of monocular VIO, and there is a problem of unobservable 4 degrees of freedom (I won’t explain this, I will explain it in detail, our Zhihu has also written about it).

The scale of binocular VIO will degrade drastically in larger-scale scenes such as outdoors , in different scenes. For example, the scale radius that the VIOBOT-PRO binocular baseline can probably manage is 16 meters. If the features within 16 meters are thin and the robot moves in a long straight line, the scale may degrade. The corresponding solution is to return to monocular depth filtering + imu, so that pure VIO can run smoothly and accurately in a large number of common indoor and outdoor scenes without third-party sensor assistance and loopback :

My photography skills are really good. Taking photos in such a big office is like a workshop.

Our office probably has this structure. I’m envious. Can you see how huge it is?

The view next to our office is great!

The distance between mileage endpoints is 428 meters, the actual distance is 621 meters

Six operations under different weather conditions were fully consistent with the actual operation trajectory of the robot, and RPE/ATE was <0.3%.

However, it should be noted that no matter how big the baseline (40mm-300mm) is, there is a possibility of scale degradation. Next, the last example picture:

Phoenix Bridge. . . help ah ah ah

This is a 10-kilometer-long cross-sea bridge. When ODOM is working on this long straight line, on a very large scale, both binocular and monocular VIO will undergo irreversible scale degradation, causing errors. In extreme cases like this, GNSS and RTK are a must, and of course radar is usually present on such scenarios.

(4) Gravity problem

When the gravity problem develops to the end, it will converge into a Z-drift (Z-axis drift) problem.

In fact, I really don't want to talk too much about this issue, but it exists objectively. . . Even though we're doing pretty well.

Especially on the long straight line of AGV, such as the unbearable picture downstairs. . .

This point cloud is really ugly

This picture corresponds to the outdoor operation where the actual distance between the endpoints upstairs is 428 meters (mileage 621 meters). You can see that 353²+243²+8.7²=183733. The root is a perfect 428.64 meters, regardless of trajectory (reflecting rotation) Still, the errors of the x/y plane are converged to the extreme (ATE/RPE are both <0.3%, reaching the laser level). But Z is a damn 8.7 meters! ! ! Although the actual altitude difference between the two endpoints is about 5 meters, it still produces an unbearable Z-Drift of about 4 meters (RPE0.7%) .

The cause is actually very simple: there are 3 parts in total, when running in a large-scale long straight line:

Limited excitation of the image's Y axis leads to + clouds in the distant sky + luminosity changes

The second problem is very chemical and easy to avoid, and the third problem will be discussed in detail shortly.

The first problem is actually the Achilles heel of VIO: In large-scale and long-distance linear motion, the excitation part of the visual input on the Y-axis corresponds to the Z-axis of the three-dimensional world, which itself is very limited ! Strictly speaking, it is a quasi-observability problem, but it exists objectively and will definitely affect your system.

How to deal with it? Add GNSS or RTK to control Z! Either compress three dimensions into two dimensions and ignore Z.

I'm two-dimensional, Z-Drift, bite me

Just kidding, we are also making a series of efforts. . . I hope everyone has a better way.

In fact, as long as perfection and ultra-high precision are not pursued, this problem will have little impact on the operation of AGV. This problem can be ignored once the UAV is fully stimulated. Of course, new coplanarity problems will arise when flying high .

(5) Photometric problem

Let’s take a look at my handsome photo from the 2023 SLAM Forum~yeah, this was taken when I was asking questions to my idol Professor Cremers:

Why did you forget to shave your beard? . . shit

Tell everyone the conclusion:

First of all, Mr. Cremers’s answer is global shutter . If not, don’t go into the direct method. . . This is consistent with my understanding.

What can partially solve the impact of lightness is the active exposure algorithm. Further, it is the exposure control of entropy or gradient (in the face of too dark or overexposed), or the integration of motion elements (Dr. Lin Yicheng), or the strategy from coarse to fine, real - time Adjust the camera exposure time and introduce a new photometric compensation algorithm (Dr. Wang Yu)

I specifically asked Dr. Hua Colin Yicheng and Dr. Wang Yu from Harbin Institute of Technology for this question. Thank you both for their advice. I will be in trouble with you in the future~~

My last question was how to deal with drastic changes in light intensity. The answer I got was that the only option is to switch the sensor or cool down. . . This answer solved the long-standing confusion in my mind. It’s better not to do anything~ Haha, it’s better to take the initiative to eliminate the weight and jump to the IMU. It will definitely be inaccurate anyway.

Let me talk about what drastic changes in luminosity are: entering and exiting a tunnel, the key indicator of the camera, lumens, can change from 30 to 12,000, a terrifying jump of three levels and four times ! And students, please stop asking me why I don’t use HDR. . . I really don’t want to explain, but I’m going to discuss the details of single-lens HDR with a core sensor manufacturer soon. . .

(6) VIO/IVO problems and terrible IMU

Let me briefly talk about the difference between VIO/IVO in my mind. Both are the coupling of CAM and IMU. The one that focuses on vision is called VIO, and the one that focuses on IMU is called IVO.

VIO: ORB-SLAM3 DMVIO

IVO: VINS-MONO

There is also BASALT that I don’t know how to define. . .

I don’t want to explain the reason in too much detail. Interested students can look at their respective graph optimization methods.

Generally speaking, VIO relies more on visual accuracy , especially DM-VIO, where the delay is more obvious. IVO relies more on the IMU itself .

Just like VINS-MONO, the main pose inputs are p, q, v, Ba, Bg, and the visual reprojection error is tightly coupled (the VINS front-end is very average, which reflects the excellence of the back-end algorithm. Another key point is that it is based on quaternion Pre-integration of numbers), it was born for drones. It performs very well on handheld and drones, but it is not suitable for ground AGVs. There are many reasons, just to name one:

Assume that the IMU has a measuring range of 12g and encounters a violent impact >30g. The IMU releases an impact in the direction of the reaction force, but the force in the direction of the action force is far beyond the range. A huge amount of acceleration of an imu enters the system, and the dynamic integral imbalance problem occurs. No matter how to proceed, filtering, the VIO system will go into crash.

Such situations abound in wheeled AGVs and ground robots.

Both VIO and IVO are not easy, but the VIO system requires more professional vision (such as our team) , while the IVO system requires more specialization in imu and navigation itself . Another point is that VIO is more convenient for mapping. Even if it is ORB, if you don’t have crazy computing power to pile up points, then the calculated things are somewhat interesting.

Why is IMU scary? Isn’t it just Alan’s variance? For ellipsoid calibration, do we need to calibrate external parameters?

It's not that simple. . . I won’t go into details. There are some things that AutoNavi can do and DJI can do. You have to evaluate whether you have the real ability to do it.

Let me make a conclusion (source of knowledge and personal testing: good friend Dr. Wu Xin): "An IMU with a very low BOM can achieve the effect of an IMU worth thousands of yuan through optimization." But I think if his engineering and knowledge level are ignored here, It’s wrong to evaluate the cost~haha. In addition, some companies that specialize in navigation can also do it, but the actual project volume is still relatively large, and generalization is not easy.

Ah Po is so sharp, mmp, if he doesn’t take me and you ask me to take him, ugh

Some relatively weak knowledge points (first of all, let’s state that our imu level is relatively poor):

*IMU's angular velocity is more trustworthy, acceleration bias/noise is more difficult to control, trust is low, and the corresponding speed is also untrustworthy

*Various imu forward angular velocities will have a small amount of random upward pitch output, which is unlikely when stationary.

*When systematic errors occur, strictly distinguish between rotation and translation

Then focus on the difference between VIO and IVO, various influencing factors: shutter, multi-eye, V calibration, I calibration and joint calibration, temperature, exposure

(7) Synchronization and calibration issues

Strictly speaking, calibration and synchronization should be considered the most troublesome engineering issues in VIO SLAM.

Let’s talk about synchronization first. I have done hardware synchronization many times before . If hardware synchronization is not possible, it is recommended not to do it. This is relatively easy to achieve in engineering.

Camera internal parameter calibration: This is a very serious matter, and the parts involved are very delicate, such as distortion, optical axis, luminosity, etc., which I will not expand on. If you don’t have good enough calibration capabilities, you won’t be able to do VIO-SLAM well, but you don’t have to go too far, just get to within 3 pixels.

Camera binocular external parameter calibration: It is also a very serious matter, and it must be standard anyway (it feels like pure nonsense). . .

The last step is the joint calibration of the camera and IMU. A VIOBOT-PRO needs to go through 7 strict calibration steps, and the camera also has its own calibration and repair procedures. Subsequent optimization and simplification of calibration is also one of the core tasks.

The calibration process of those cool drones with 5-6 cameras and IMUs (such as Skydio) that you usually see is more complicated.

SKYDIO aircraft is really powerful. If it tries to capture the consumer business, it still can’t beat DJI, haha.

(8) Binocular point cloud and worldview issues

Binocular native depth maps are terrible! Through simple parallax matching, not only does it require a lot of repeated calculations, but the calculation effect is also extremely poor. It consumes a lot of overhead and gives you garbage, and the point cloud made from garbage will still be very garbage. But if combined with NPU, it will have a very good effect, but it is still a bit heavy, as shown below:

High-quality binocular point cloud from Jianzhi Technology combined with NN

There is also an i-TOF point cloud, which can complete 3D mapping simultaneously. The VIOBOT-iTof version is provided as follows:

Premium i-TOF point cloud from VIOBOT

But this thing also has two shortcomings. One is that the hand is short (only 5 meters), and the second is that it cannot respond to black things (a natural shortcoming of i-TOF).

VIOBOT-PRO's RDF ( Realtime Dense Filter ) point cloud is a very high-quality by-product discovered in the process of engineering research . Only with it can VIOBOT truly have a complete world view. Although it is not so beautiful, it is extremely practical. You can follow the system's high-speed key frame output to complete obstacle avoidance in real time while building a world view of the robot's basic work. If aesthetic issues are not considered, it is very close to the working capabilities of line scan radar.

Native point cloud (it can be seen that there are a large number of Outliers and they are sparse ):

So many Outliers ahhhhhhhhhhhhhhhhhhhhh

RDF point cloud (cleaner and denser than native point cloud, although ugly):

Ugly ugly! Nothing wrong with it except being ugly

It looks really ugly, but fortunately it’s clean and dense.

This kind of point cloud can be easily used for three-dimensional obstacle avoidance on the ground and in the air . At the same time, it can also build a real robot worldview :

If you zoom out this picture, you will think it was built by laser.

In fact, some smaller workspaces can be used offline or through other tools to perform denser three-dimensional reconstructions, which is a story for another time.

Real-time dense and accurate point cloud during robot operation is second only to pose reliability in importance. Otherwise, why do we need lidar?

(9)Temperature and impact

Other issues are highly focused on 2 things: operating temperature and impact

Our calibration will be anchored 3-5 minutes after power-on. The system heat engine will enter a stable working temperature such as surface temperature 32-35°C and sensor panel temperature 40°C. In this way, regardless of rotation or translation, it will be in its best working condition. . However (the following images were completed by Zichuan thermal imager, with an accuracy of ±2°C):

Our thermal imaging camera is a crane

Because the third machine on the right is a testing machine, a power supply close to 55°C is specially installed on it to continuously conduct heat to it, so that its surface temperature reaches 40°C, and the temperature of the sensor board is close to 50°C. At this time, it is almost the same as the normal calibration temperature . 10℃ , causes the following problems:

The one below has become frustrated. . .

For the VIOBOT-PRO below, which operates at 50°C, you will find that the error has spread. Test path 33 meters, about 12 rotations

After returning to the origin, the errors of the above two devices remained at 0.3% and lower, while the error of the third device increased to nearly 1.6%.

This is the negative effect brought by temperature, which will affect the calibration data of both IMU MEMS and the camera itself .

Similarly, cameras like VIOBOT-PRO will also produce the same error expansion phenomenon after experiencing severe impact :

The following is a professional explanation from my good friend Dr. Wu Xin: "The principle of mems is to obtain feedback force by rotating or vibrating the silicon micromechanical structure to amplify the measured Coriolis force. Therefore, vibration and impact will change the mechanical properties of the silicon microstructure. thereby changing the output"

Solution: If the body cannot recover after a severe impact, it is recommended to recalibrate it (it does not happen often, and occasional impacts will have a certain impact on the accuracy). The normal operating temperature of the equipment is very stable. Pay attention to heat dissipation and do not allow other heat sources to flow towards it. Conduct heat .

(10) Ending - loopback/map management, ODOM credibility and planning

Loop closure and map management are essentially relocation , which is a problem that robot SLAM has not been closed. They still have a series of limitations.

Either it is only suitable for small scenes , or it relies on HD maps and third-party sensors .

Whether it is Localmapping in ORB-SLAM3 or the dynamic and static map management mentioned by Dr. Gao Xiang in this SLAM forum, they are all excellent outputs to solve such problems. We currently don’t have any special ideas or methods for this. We have tried to use ICP for visual loopback before , but we actually took many detours and ended up in failure. This can be regarded as a trap for everyone. I hope some experts can figure it out in the future.

Loopback and map management are mainly general-purpose calculations, which are relatively dependent on the CPU and are very troublesome to modify. Simply do CPU parallelization. After all, it is a low-frequency operation. However, we must pay attention to the impact on the system when triggered to avoid causing new problems.

Because our group's map management and planning and development skills are relatively poor, we can only focus our energy on the credibility of ODOM itself. This comes back to the three-phase nature and world view. Since today's topic is to talk about problems, I won't go into details.

ODOM credibility test: refers to using your device to obtain excellent rotation and translation accuracy in a variety of different environments and scenes, without serious scale degradation, and can tolerate certain errors (there will inevitably be a little), but note 2 key points: Random scenes can be repeated a lot . If you fail to hold these two points, your ODOM will have no credibility.

This test was carried out 6 times in total, the endorsement of highly reliable ODOM~ la la la

Good ODOM reliability can reduce a lot of relocation work. For example, if RTK is needed outdoors, GNSS can be used in many scenarios.

Planning: three methods: point-to-point /optimal path/free path . We still prefer the third free path method. For a good VIO-SLAM, what we should tell the robot is where you are/where you want to go, and others. Do it yourself~~~ It’s closer to the way people think and act. As for what to do there? That is the task of planning software or AI. When implementing VIO-SLAM, we must try our best to avoid CM-level scenarios, and we encourage you all to do so.

Guess you like

Origin blog.csdn.net/lovely_yoshino/article/details/132732924