In this video, we're going to see how we can do SLAM on our robot. So we're going to use the lidar on the robot along with the ROS `slam_toolbox` to generate a map of the environment around the robot and then figure out the robot's position within that map.

Then, in the next video, we're going to be able to reuse that map with the Nav2 stack so it can use the map to figure out where any obstacles are and autonomously navigate a safe path towards a goal.

If you're familiar with SLAM, you'll be aware that it comes in many different shapes and forms that use many different sensors, but today we're going to be focusing on grid SLAM with a 2D lidar.

So I'm going to start with a quick overview of what SLAM is and how it works.

Then we'll look at how SLAM integrates into ROS.

Then we'll learn about the `slam_toolbox`, and we'll get that up and going using Gazebo. And then finally, we'll run SLAM on our actual robot.

SLAM is an acronym, and it stands for Simultaneous Localization and Mapping. So what are localization and mapping? Well, let's start with mapping.

Imagine you want to make a map of your street. You've got a phone on you so that you can track your GPS location.

And as you walk along the street, you take note of what you see: orange house on the left, greenhouse on the right, turn the corner, red roof on the right, white fence on the left, and so on.

Once you're finished, you'll have a nice little map of your street. Now that you've got your map, you can use it for localization.

Let's say your phone battery runs out, so you've got no GPS, and you need to figure out where you are.

you can see a white fence on your right and a red roof further up on the left. Using the map, you'll be able to pretty accurately pinpoint your location wherever you are.

You've found your location in the global coordinate system, you've localized. It's worth pointing out here that localization isn't navigation.

Navigation also uses our map, but that's where we're calculating a path to reach an objective, like how do I get to the orange house via the house with a red roof, and planning a safe path to follow through the environment.

Advanced navigation may involve dynamically updating the path as new or moving obstacles are detected.

We'll be covering navigation in the next tutorial when we look at the Nav2 stack. The problem with the approach we just saw is that we needed that GPS on our phone in the first place to make an accurate map.

But sometimes we might only have a GPS coordinate for our starting position or no GPS at all.

In that case, we need to do SLAM. We need to simultaneously localize and map.

From our starting position, we might be able to see the orange house and the greenhouse. And as we walk, we'll keep an eye on where they are and consequently where we are compared to them.

We could also use our stride length to help us with this position estimate. Then, whenever we see a new object, we know where it is because we know where we are, and it all just goes on continuously.

Congratulations, we just SLAMmed. And the result may not be as accurate as with the GPS, but it's much better than having no map at all.

SLAM comes in many different forms with many different algorithms, but often we can categorize most SLAM methods into one of two categories: there's feature or landmark SLAM and grid SLAM.

So what we saw just then, that was feature SLAM. So our features are our landmarks, for things like a red roof or a white fence.

Grid SLAM, on the other hand, is where we divide the world that we're seeing up into a series of cells, and each cell can either be occupied or unoccupied, or somewhere in between.

SLAM Toolbox that we're going to be using today is a grid map based approach.

Before we start using SLAM in ROS, we need to take a moment to understand some of the coordinate frame conventions.

This is some stuff I probably should have covered earlier in the series, but, you know, better late than never.

So to start off with, we know that the frame attached to our robot is called `base_link`. Up until this point, when we've driven the robot around, we've set our fixed frame in RViz to something called `odom`.

In the absence of any other reference, `odom` represents our world origin, and the transform from `odom` to `base_link` is calculated by the differential drive controller using the wheel odometry.

When our robot first starts up, it's at 0, 0.

The two frames are on top of each other. As the robot drives around, `base_link` will move compared to `odom`. Now, here's the important bit: the motion of `base_link` relative to `odom` may not be exactly correct, but it will be smooth.

What I mean is, it's possible that you drive the robot forward in real life by two meters, but when you check RViz, `base_link` is only at 1.9 meters ahead of `odom`.

This 100 mil error did not suddenly appear; it built up over time as the odometry drifted, you could take any small section of that trajectory and it would be nice and smooth and basically correct, but it just slowly got away from the truth.

This is because odometry is effectively a measurement of the robot's velocity, even if it's technically measuring wheel angular position. This velocity is then integrated smoothly over time to produce the position transform estimate.

Let's say we now introduce a system that can correct for this drift, like GPS or SLAM.

Because these systems directly measure the robot position, if we were to use them to update the Odom to base link transform, this could cause the robot to jump around.

Now, this might not be a problem, but some algorithms won't like it. Instead, we want to introduce a new frame, the map frame, and we can now express the location of Base link compared to that.

So we can have the base link compared to the Odom frame, or we can have the base link compared to the map frame.

This gives us a new problem though, which is that a frame in ROS can only have one parent.

The way we get around this is that the code will need to take the position estimate from SLAM or GPS or whatever, along with the current Odom to base link transform, and calculate the appropriate map to Odom transform.

This is a bit weird, since the map to Odom transform is kind of meaningless out of context, but it means that we can get the base link pose relative to either reference point with no troubles, and it should move smoothly but drift compared to Odom, and jump around but stay generally correct over time compared to map.

As well as the Odom and map frames, you'll also find Odom and map topics, which contain the data about the odometry and the map.

The Odom topic contains basically the same position information as the Odom to base link transform, but it also contains the current velocity and the associated covariances.

The map topic contains the actual occupancy data for the grid map so that it can be shared to other nodes, and we'll be using this one later in this tutorial.

One other thing to be aware of is that in addition to the base link frame, some SLAM systems also like you to have a base footprint frame.

And that's because some robots can move up and down in 3D. The base link will move up around in Z, but we want to treat the SLAM problem in this case as a 2D SLAM problem.

So the base footprint frame is kind of like the shadow of the base link frame on the ground.

So it's stuck to the XY plane, Z equals zero. It's stuck on the ground and it'll move around underneath the base link and be used for SLAM.

One last note on phrasing, I'll sometimes use the word pose, which refers to the robot's position, its location and its orientation, what angle it's at.

And the pose is pretty much equivalent to the robot's transform frame.

All of this coordinate frame stuff can be super confusing and hopefully it'll start to make a little bit more sense once we put it into practice on our robot.

If you do want to find out more about it, you can find it in the ROS standards, particularly REP 105 and also a little bit in REP 120.

For this tutorial, we're going to be using the fantastic slam_toolbox package by Steve Macenski. Now Steve has contributed a number of great packages to the ROS 2 ecosystem, particularly slam_toolbox and also Nav 2 that we'll be looking at in the next video.

Before we install it though, I'm going to go ahead and add an extra link to our robot URDF, and that's that base footprint, oh this one, that's uh the base footprint that I talked about just before.

So if we go up to here to our base link, I'm just going to add it here just under the base link.

I've already got it copied, and we can see it's the base footprint link.

The name is just base_footprint and it's attached to the base link rigidly with no offsets or anything. So it's going to be just sitting exactly on top of the base link because our robot is just sitting on the ground anyway.

So I'm going to save that and then I'm going to go ahead and install slam_toolbox.

So `sudo apt install ros-foxy-slam-toolbox`. slam_toolbox has a few different modes that it can run in and a lot of different options.

Now the mode that we're going to be using today is called online asynchronous. So online means we're running it live rather than running it through some previously logged data, and asynchronous means that we don't care about processing absolutely every scan.

Instead, say that our processing rate is a bit slower than the scan rate, we just always want to be processing the latest scan, even if that means we miss one occasionally.

Now to make things a bit easier for us, slam_toolbox comes with some launch files and params files that help us set the options.

So I'm going to take one of those params files and actually copy it into our local directory.

So I'm going to copy `/opt/ros/foxy/share/slam_toolbox/config` and now you can see there's a few different options here.

I want `mapper_params_online_async` and I'm going to copy them into my workspace into my config directory.

And now if we swap back to VS Code and look at our config directory, we can see the file here. So this should be all the parameters that we might want to change for slam toolbox.

Now, it looks pretty scary. We're actually only going to change a couple of these in this video, but the rest are there for you to play around with and see how it works.

And to start off with, we're going to be running in mapping mode, like we see here.

And we can see that it's going to use the Odom frame as Odom, the map frame as map, and the base frame as base footprint, and the scanner topic as scan.

So everything as we've already got it set up. So I'm going to hop into our workspace.

I'm just going to build it with Colcon just in case anything's changed and source the workspace.

And I'm going to launch our simulation and I'll also launch RViz. We should see our robot come up like normal. And if I just drive it around for a little bit.

And what I'm going to do is here in Gazebo, I'm going to try and come straight back onto the origin.

And what we'll probably find in RViz is that I'm actually shifted a bit from where I started. Now, to be honest, that's that's pretty good.

I've actually ended up quite close. Maybe our Gazebo odometry is a bit better than it would be in real life.

But usually you'd find that the robot at this point has drifted away a little bit from where you started. So what I'm going to do now is I'm going to restart the Gazebo simulation to put our robot back at the origin.

I'm restarting RViz as well. You really shouldn't need to, but I find that sometimes it just plays up and gets stuck in a bit of a state, so we'll rerun it all.

All right, there's our robot back at the origin.

And now what I'm going to do in a new tab, I'm going to type `ros2 launch slam_toolbox` and we can see what launch files we've got here.

And we want `online_async.launch.py`. We'll specify the `params` file, so that's a parameter for this launch file, and that'll be `source/articubot_one/config/mapper_params_online_async.

yaml`. And then we can also set `use_sim_time` to `true`, and that should pass it down to everything underneath.

So that should be running SLAM now. And what we can do back in our RViz is we're going to add a map.

I'm going to set the topic to `/map` and hopefully what we'll see is our map appears.

So this is the area around the robot and the rays that it's casting. Now I'm going to go ahead and change the fixed frame to the map frame.

And what that's going to mean is that the robot can jump around and the map is going to stay steady.

If I left it at Odom, the robot would be moving smoothly, but sometimes the map could jump around. It's the same thing, it's just a matter of perspective.

So now with the map frame fixed, I can start driving the robot around and we'll see that as we drive it around, it starts to generate a map of what it's seeing.

And you can go ahead and tweak the parameters in the config file to change this. As I move out of bounds, it should just grow the map to contain the new area that I'm in.

And sometimes it might look like things are a little bit off, and this is where it helps to swap your RV's view to top-down orthographic.

So this is a 2D view. I can't rotate in 3D anymore, but we should find that everything stays in roughly the right spot with no perspective errors.

And so if I keep driving and get back to the origin, now what we'll see is that if I get back to the map origin, which is here, I'd expect to be very close to my origin in Gazebo.

But if we open up the transform tree and show the names, you can see that the Odom frame has drifted a little bit.

So that distance there, which is, I don't know, maybe 200 mil that way, 400 mil that way, that's how much the Odom has drifted compared to the ground truth.

And we've used the map to keep us locked in to where the robot really is.

Once we've made that map, we might want to save it to use in the future. Now if I open a new tab and write `ros2 service list`, we should see that `slam_toolbox` offers us a whole bunch of services for things like saving map and serializing map.

But to make that a little bit easier, it also comes with an RViz plugin. So we can go add new panel, `slam_toolbox` plugin, and we see all these options here and in particular the Save Map and Serialize Map buttons.

Now this is really confusing, but as I understand it, Save Map is to kind of save in the old format that maps use.

So you want to do that if you want to pass it into some kind of external system that's using the map.

So serializing the map is if you want to save it to reuse with `slam_toolbox`, either to localize with it or say you want to modify the map in the future.

So I'm going to actually save in both formats and I'm going to call it my map save and my map serial.

Easy SLAM with ROS using slam_toolbox

Instructional and entertaining videos on the subject of robotics. Including theory, practice, and using ROS.

Articulated Robotics

이번 영상에서는 로봇에서 SLAM을 수행하는 방법을 알아봅니다. 로봇의 라이다와 ROS `slam_toolbox`를 사용하여 로봇 주변 환경의 지도를 생성한 다음, 해당 지도 내에서 로봇의 위치를 파악할 것입니다.

다음 영상에서는 Nav2 스택으로 해당 지도를 재사용하여 지도를 사용하여 장애물의 위치를 파악하고 목표 지점까지 안전한 경로를 자율적으로 탐색할 수 있도록 할 것입니다.

SLAM에 익숙하다면 다양한 센서를 사용하는 다양한 형태의 SLAM이 있다는 것을 알 수 있지만, 오늘은 2D 라이다를 사용한 그리드 SLAM에 집중할 것입니다.

먼저 SLAM이 무엇이고 어떻게 작동하는지에 대한 간략한 개요로 시작하겠습니다.

그런 다음 SLAM이 ROS에 어떻게 통합되는지 살펴보겠습니다.

그런 다음 `slam_toolbox`에 대해 배우고 Gazebo를 사용하여 시작하고 실행합니다. 마지막으로 실제 로봇에서 SLAM을 실행합니다.

SLAM은 약어이며 Simultaneous Localization and Mapping의 약자입니다. 그렇다면 localization과 mapping은 무엇일까요? 먼저 mapping부터 시작하겠습니다.

거리의 지도를 만들고 싶다고 상상해 보세요. 휴대폰으로 GPS 위치를 추적할 수 있습니다.

거리를 걸으면서 보이는 것을 기록합니다. 왼쪽에 주황색 집, 오른쪽에 온실, 모퉁이를 돌면 오른쪽에 빨간색 지붕, 왼쪽에 흰색 울타리 등이 있습니다.

완료되면 거리의 멋진 작은 지도가 생깁니다. 이제 지도가 있으므로 localization에 사용할 수 있습니다.

휴대폰 배터리가 방전되어 GPS가 없고 현재 위치를 파악해야 한다고 가정해 보겠습니다.

오른쪽에 흰색 울타리가 보이고 왼쪽에 빨간색 지붕이 더 멀리 보입니다. 지도를 사용하여 현재 위치를 정확하게 파악할 수 있습니다.

전역 좌표계에서 위치를 찾았고, localization했습니다. 여기서 localization은 탐색이 아니라는 점을 지적할 가치가 있습니다.

내비게이션도 저희 지도를 사용하지만, 여기서 목표 지점에 도달하기 위한 경로를 계산합니다. 예를 들어 빨간 지붕이 있는 집을 거쳐서 주황색 집에 어떻게 가는지, 그리고 환경을 통과하는 안전한 경로를 계획하는 거죠.

고급 내비게이션은 새로운 장애물이나 움직이는 장애물이 감지될 때 경로를 동적으로 업데이트하는 것을 포함할 수 있습니다.

Nav2 스택을 살펴볼 다음 튜토리얼에서 내비게이션을 다룰 예정입니다. 방금 본 접근 방식의 문제점은 정확한 지도를 만들기 위해 휴대폰에서 GPS가 필요했다는 것입니다.

하지만 때로는 시작 위치에 대한 GPS 좌표만 있거나 GPS가 전혀 없을 수도 있습니다.

이 경우 SLAM을 수행해야 합니다. 즉, 동시적 위치 추정 및 지도 작성을 해야 합니다.

시작 위치에서 주황색 집과 온실을 볼 수 있을 겁니다. 그리고 걸으면서 계속해서 그것들이 어디에 있는지, 결과적으로 그것들과 비교하여 우리가 어디에 있는지 주시할 겁니다.

보폭 길이를 사용하여 이 위치 추정을 도울 수도 있습니다. 그런 다음 새로운 물체를 볼 때마다 우리가 어디에 있는지 알기 때문에 그 물체가 어디에 있는지 알게 되고, 이 모든 것이 계속 진행됩니다.

축하합니다, SLAM을 방금 수행했습니다. 결과가 GPS를 사용하는 것만큼 정확하지 않을 수 있지만, 지도가 전혀 없는 것보다는 훨씬 낫습니다.

SLAM은 다양한 알고리즘과 함께 다양한 형태로 제공되지만, 대부분의 SLAM 방법은 피처 또는 랜드마크 SLAM과 그리드 SLAM의 두 가지 범주 중 하나로 분류할 수 있습니다.

방금 본 것은 피처 SLAM이었습니다. 따라서 피처는 빨간 지붕이나 흰색 울타리와 같은 랜드마크입니다.

반면에 그리드 SLAM은 우리가 보고 있는 세계를 일련의 셀로 나누고 각 셀은 점유되거나 비어 있거나 그 중간일 수 있습니다.

오늘 사용할 SLAM Toolbox는 그리드 맵 기반 접근 방식입니다.

ROS에서 SLAM을 사용하기 전에 잠시 시간을 내어 좌표 프레임 규칙을 이해해야 합니다.

이것은 시리즈 초반에 다뤘어야 할 내용이지만, 늦더라도 안 하는 것보다는 낫죠.

우선 로봇에 연결된 프레임은 `base_link`라고 합니다. 지금까지 로봇을 운전할 때 RViz에서 고정 프레임을 `odom`이라고 설정했습니다.

다른 참조가 없는 경우, `odom`은 우리의 세계 원점을 나타내며, `odom`에서 `base_link`로의 변환은 휠 오도메트리를 사용하여 차동 구동 컨트롤러에 의해 계산됩니다.

로봇이 처음 시작될 때 0, 0에 있습니다.

두 프레임이 서로 겹쳐 있습니다. 로봇이 주행함에 따라 `base_link`는 `odom`에 비해 이동합니다. 여기서 중요한 점은 `odom`을 기준으로 한 `base_link`의 움직임이 정확하지 않을 수 있지만 부드럽다는 것입니다.

실제로 로봇을 2미터 전진시켰지만 RViz를 확인했을 때 `base_link`가 `odom`보다 1.9미터 앞에 있는 경우도 있을 수 있습니다.

이 100mm 오차가 갑자기 나타난 것이 아니라, 오도메트리가 드리프트되면서 시간이 지남에 따라 누적된 것입니다. 궤적의 작은 부분을 가져와도 멋지고 부드럽고 기본적으로 정확하지만, 진실에서 서서히 벗어난 것입니다.

이는 오도메트리가 휠 각도 위치를 측정하더라도 로봇의 속도를 효과적으로 측정하기 때문입니다. 이 속도는 시간 경과에 따라 부드럽게 통합되어 위치 변환 추정치를 생성합니다.

GPS 또는 SLAM과 같이 이러한 드리프트를 보정할 수 있는 시스템을 도입한다고 가정해 보겠습니다.

이러한 시스템은 로봇 위치를 직접 측정하기 때문에 이를 사용하여 Odom에서 base link로의 변환을 업데이트하면 로봇이 여기저기 뛰어다닐 수 있습니다.

이것이 문제가 되지 않을 수도 있지만 일부 알고리즘은 좋아하지 않을 것입니다. 대신, 새로운 프레임인 맵 프레임을 도입하고 이제 Base link의 위치를 해당 프레임과 비교하여 표현할 수 있습니다.

따라서 Odom 프레임과 비교하여 base link를 가질 수도 있고, 맵 프레임과 비교하여 base link를 가질 수도 있습니다.

하지만 이것은 ROS에서 프레임이 하나의 부모만 가질 수 있다는 새로운 문제를 야기합니다.

이 문제를 해결하는 방법은 코드가 SLAM 또는 GPS 등에서 위치 추정치를 가져와 현재 Odom에서 base link로의 변환과 함께 적절한 맵에서 Odom으로의 변환을 계산해야 한다는 것입니다.

이건 좀 이상한데요. 맵에서 오돔으로의 변환은 문맥상 의미가 없지만, 이걸 통해 기준점을 기준으로 베이스 링크 포즈를 문제없이 얻을 수 있습니다. 오돔에 비해 부드럽게 움직이지만 드리프트가 발생하고, 맵에 비해 점프는 있지만 시간이 지날수록 대체로 정확하게 유지됩니다.

오돔 및 맵 프레임 외에도 오도메트리 및 맵에 대한 데이터가 포함된 오돔 및 맵 토픽도 찾을 수 있습니다.

오돔 토픽은 기본적으로 오돔에서 베이스 링크로의 변환과 동일한 위치 정보를 포함하지만, 현재 속도와 관련 공분산도 포함합니다.

맵 토픽은 그리드 맵의 실제 점유 데이터를 포함하므로 다른 노드와 공유할 수 있으며, 이 튜토리얼의 뒷부분에서 이 데이터를 사용할 예정입니다.

또 하나 알아두어야 할 점은 베이스 링크 프레임 외에도 일부 SLAM 시스템에서는 베이스 Footprint 프레임도 필요로 한다는 것입니다.

일부 로봇은 3D로 위아래로 움직일 수 있기 때문입니다. 베이스 링크는 Z축에서 위아래로 움직이지만, 이 경우 SLAM 문제를 2D SLAM 문제로 취급하고 싶습니다.

따라서 베이스 Footprint 프레임은 마치 지면에 드리워진 베이스 링크 프레임의 그림자와 같습니다.

XY 평면에 고정되어 있고 Z는 0입니다. 지면에 고정되어 베이스 링크 아래에서 움직이며 SLAM에 사용됩니다.

구문에 대한 마지막 참고 사항으로, 저는 때때로 로봇의 위치, 즉 위치와 방향, 각도를 나타내는 포즈라는 단어를 사용합니다.

그리고 포즈는 로봇의 변환 프레임과 거의 같습니다.

이 모든 좌표 프레임 관련 내용은 매우 혼란스러울 수 있지만, 로봇에 적용하면 조금 더 이해가 될 것입니다.

자세한 내용을 알고 싶으시면 ROS 표준, 특히 REP 105와 REP 120에서 약간 찾을 수 있습니다.

이 튜토리얼에서는 Steve Macenski의 훌륭한 slam_toolbox 패키지를 사용할 것입니다. Steve는 ROS 2 생태계에 많은 훌륭한 패키지를 기여했는데, 특히 slam_toolbox와 다음 비디오에서 살펴볼 Nav 2가 있습니다.

설치하기 전에 로봇 URDF에 추가 링크를 추가할 건데요. 방금 전에 얘기했던 베이스 footprint입니다.

여기 베이스 링크 바로 아래에 추가하겠습니다.

이미 복사해 놨고, 베이스 footprint 링크라는 것을 알 수 있습니다.

이름은 base_footprint이고, 오프셋 없이 베이스 링크에 단단히 연결되어 있습니다. 로봇이 바닥에 있기 때문에 베이스 링크 바로 위에 위치하게 됩니다.

저장하고, slam_toolbox를 설치하겠습니다.

`sudo apt install ros-foxy-slam-toolbox`를 입력합니다. slam_toolbox는 여러 가지 모드로 실행할 수 있고 다양한 옵션이 있습니다.

오늘 사용할 모드는 온라인 비동기 방식입니다. 온라인은 이전에 기록된 데이터를 사용하는 것이 아니라 실시간으로 실행한다는 의미이고, 비동기는 모든 스캔을 처리하는 데 신경 쓰지 않는다는 의미입니다.

스캔 속도보다 처리 속도가 느린 경우에도 가장 최신 스캔을 항상 처리하려고 합니다. 가끔 하나를 놓치더라도 말이죠.

더 쉽게 사용할 수 있도록 slam_toolbox는 옵션을 설정하는 데 도움이 되는 런치 파일과 파라미터 파일이 함께 제공됩니다.

이 파라미터 파일 중 하나를 복사해서 로컬 디렉토리에 넣겠습니다.

`opt/ros/foxy/share/slam_toolbox/config`를 복사합니다. 여기에는 몇 가지 다른 옵션이 있습니다.

`mapper_params_online_async`를 제 작업 공간의 config 디렉토리에 복사하겠습니다.

VS Code로 돌아가서 config 디렉토리를 보면 파일이 있습니다. 여기에는 slam toolbox에 대해 변경할 수 있는 모든 파라미터가 있습니다.

꽤 복잡해 보이지만, 이 비디오에서는 몇 가지만 변경할 겁니다. 나머지는 직접 사용해 보면서 어떻게 작동하는지 확인해 보세요.

우선 여기 보이는 것처럼 매핑 모드로 실행하겠습니다.

그리고 오돔 프레임을 Odom으로, 맵 프레임을 맵으로, 베이스 프레임을 베이스 footprint로, 스캐너 토픽을 스캔으로 사용하는 것을 볼 수 있습니다.

모든 것이 이미 설정되어 있습니다. 이제 작업 공간으로 들어가겠습니다.

Colcon으로 빌드하고 변경 사항이 있는지 확인하고 작업 공간을 소싱하겠습니다.

시뮬레이션을 시작하고 RViz도 시작합니다. 로봇이 정상적으로 나타나는 것을 볼 수 있습니다. 그리고 잠시 운전해 보겠습니다.

Gazebo에서 원점으로 똑바로 돌아오려고 합니다.

RViz에서 실제로 시작 위치에서 약간 벗어난 것을 알 수 있을 것입니다. 솔직히 말해서 꽤 좋습니다.

실제로 꽤 가까이에 도착했습니다. 아마 Gazebo의 Odometry가 실제보다 약간 더 나을 것입니다.

하지만 일반적으로 이 시점에서 로봇이 시작 위치에서 약간 벗어난 것을 알 수 있습니다. 이제 Gazebo 시뮬레이션을 다시 시작하여 로봇을 원점으로 되돌리겠습니다.

RViz도 다시 시작합니다. 그럴 필요는 없지만 때로는 제대로 작동하지 않고 멈추는 경우가 있어서 모두 다시 실행합니다.

좋습니다. 로봇이 원점으로 돌아왔습니다.

이제 새 탭에서 `ros2 launch slam_toolbox`를 입력하고 여기에 어떤 launch 파일이 있는지 확인할 수 있습니다.

그리고 `online_async.launch.py`를 원합니다. `params` 파일을 지정합니다. 이것은 이 launch 파일의 파라미터이며, `source/articubot_one/config/mapper_params_online_async`가 될 것입니다.

yaml`. 그리고 `use_sim_time`을 `true`로 설정할 수도 있습니다. 그러면 모든 것에 전달될 것입니다.

이제 SLAM이 실행되어야 합니다. RViz로 돌아가서 맵을 추가할 수 있습니다.

토픽을 `/map`으로 설정하면 맵이 나타날 것입니다.

자, 이것은 로봇 주변 영역과 로봇이 투사하는 광선입니다. 이제 고정 프레임을 맵 프레임으로 변경하겠습니다.

이것이 의미하는 바는 로봇이 점프할 수 있고 맵은 계속 안정적으로 유지된다는 것입니다.

Odom에 그대로 두면 로봇은 부드럽게 움직이지만 때로는 맵이 점프할 수 있습니다. 똑같은 것이고 관점의 문제입니다.

이제 맵 프레임이 고정되었으므로 로봇을 운전하기 시작할 수 있습니다. 로봇을 운전하면 로봇이 보는 것을 기반으로 맵을 생성하기 시작합니다.

구성 파일에서 파라미터를 조정하여 변경할 수 있습니다. 경계를 벗어나면 맵이 확장되어 제가 있는 새로운 영역을 포함해야 합니다.

때로는 상황이 약간 어긋나 보이는 경우가 있는데, 이럴 때는 RViz 보기를 하향식 직교로 바꾸는 것이 도움이 됩니다.

이것은 2D 보기입니다. 더 이상 3D로 회전할 수 없지만 원근감 오류 없이 모든 것이 대략 올바른 위치에 유지되는 것을 알 수 있습니다.

계속 운전하여 원점으로 돌아가면 맵 원점(여기)으로 돌아갈 경우 Gazebo의 원점에 매우 가까울 것으로 예상됩니다.

하지만 변환 트리를 열고 이름을 표시하면 Odom 프레임이 약간 벗어난 것을 볼 수 있습니다.

저 거리는, 글쎄요, 아마 저 방향으로 200밀리미터, 저 방향으로 400밀리미터 정도 될 텐데, 그것이 Odom이 실제 위치와 비교하여 얼마나 벗어났는지 보여줍니다.

그리고 우리는 맵을 사용하여 로봇이 실제로 있는 위치에 고정했습니다.

일단 맵을 만들었으면 나중에 사용하기 위해 저장하고 싶을 수 있습니다. 새 탭을 열고 `ros2 service list`를 입력하면 `slam_toolbox`가 맵 저장 및 맵 직렬화와 같은 작업을 위한 다양한 서비스를 제공하는 것을 볼 수 있습니다.

하지만 좀 더 쉽게 하기 위해 RViz 플러그인도 함께 제공됩니다. 새 패널, `slam_toolbox` 플러그인을 추가하면 여기에 있는 모든 옵션, 특히 맵 저장 및 맵 직렬화 버튼이 표시됩니다.

이게 정말 혼란스러운데, 제가 이해하기로는 Save Map은 맵에서 사용하는 이전 형식으로 저장하는 것과 같습니다.

따라서 맵을 사용하는 외부 시스템에 전달하려면 그렇게 해야 합니다.

Easy SLAM with ROS using slam_toolbox

Easy SLAM with ROS using slam_toolbox

스크립트