슬램 툴박스는 환경 지도를 생성하고 해당 지도 내에서 로봇의 위치를 파악하는 데 사용됩니다.

### 로봇  SLAM: ROS 및 SLAM 툴박스를 사용한 동시 로컬라이제이션 및 매핑
* 🤖   이 동영상에서는  LiDAR와 ROS SLAM 툴박스를 사용하여 로봇에서 **SLAM을 수행**하여 환경 지도를 생성하고 해당 지도 내에서 **로봇을 위치 파악**하는 방법을 설명합니다.
* 🗺️    SLAM은 동시 위치 파악 및 매핑의 약자로, **환경 지도를 생성**하고 이를 사용하여 **로봇의 위치를 파악**하는 것을 말합니다.
* 📋   매핑은 환경 지도를 만드는 작업이며, **로컬라이제이션은 지도를 사용하여 로봇의 위치를 정확히 파악**하고 **내비게이션은 목표에 도달하기 위한 경로를 계산**하여 안전한 경로를 계획하는 작업입니다.
* 🔲    SLAM은 다양한 형태로 제공되며, 이 동영상에서는 **2D LiDAR를 사용하는 그리드 SLAM**과 그리드 맵 기반 접근 방식인 **ROS SLAM 툴박스**에 중점을 둡니다.
* 📐   이 동영상에서는  ROS의 좌표 프레임 규칙, SLAM을 ROS에 통합하는 방법, **SLAM 툴박스의 시작 파일 및 매개변수 파일을 사용하여 옵션을 설정**하는 방법에 대해 설명합니다.
* 🗄️   이 동영상에서는  SLAM 툴박스로 지도를 생성한 후 나중에 사용할 수 있도록 **지도를 저장하고 직렬화**하는 방법과 현지화를 위해 **지도를 재사용**하는 방법을 보여 줍니다.
* 🧭   그런 다음  AMCL 현지화 시스템과 함께 지도를 사용하고 **고급 내비게이션 기능을 위한 nav2 스택**을 설치하는 방법을 살펴봅니다.
* 🚀   이 동영상은 실제 로봇에  SLAM 툴박스를 배포하고 **Wi-Fi 전송의 잠재적 문제**와 다양한 SLAM 알고리즘 및 센서에 대한 향후 심층 분석 가능성을 논의하는 것으로 마무리됩니다.

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 water 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 and rosto, 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 zero zero. 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 hundred 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.

whatever along with the current Odeon 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 trebles, 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 Zed. 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 X Y 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 Masenski. 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 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.

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 Odometry 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 Avis is that I'm actually shifted a bit from where I started. Now to be honest, 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 RVs 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. Alright, there's our robot back at the origin. And now what I'm going to do in a new tab is I'm going to type Ross to Launch slam toolbox.

and we can see what launch files we've got here. And we want online async dot launch dot pi. We'll specify the params file so that's a parameter for this launch file, and that'll be Source slash a tickybot one config mapper params online async. 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 viz is we're going to add a map. I'm going to set the topic to slash 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 uh 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 rvis plugin so we can go add new panel slam toolbox plug-in, 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.

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. There's nothing wrong with giving them the same name because they'll have different file extensions. I'm just doing it to make it clear for the tutorial. So I'll hit save map and then serialize map. And there's no kind of prompt or anything but if I open up the file browser and go into our workspace. We can see here we've got my map save.pgm. And look at that we even get a little preview of the map there my mapsave.yaml. So that's the old format and then the serialized ones is dot data and Dot pose graph. Now that we've saved our map we can try to reuse it for localization but first I'm actually just going to clear the map so that we can see that it is actually loading it and

not just keeping it open from before. So I've just rerun slam toolbox, and if we give it a moment, this should clear, all right? So I've just rerun it and cleared the map so that you can see that it's all been reset. So we're going to go back into our parameters. Now we're going to change mapping to be localization. For the map file name, I'm going to write the path to our file but without the extension. So it's this: my map serial one. So it'll be /home, it'll be /home/dev/devws/my map serial. And then I'm going to tell it to start at Doc. So I think that's telling it to start at what's called the first node of the pose graph. What that should mean is that it's starting at the same place that you started when you made the map the first time. You can also use the start pose to specify a specific pose in space to do it, but we're going to go start at Doc localization. All right, all that looks

good. So now I'm going to rerun Slim Toolbox, and you can see it's pre-loaded back up our old map. And if I drive around, we should be localizing just like we were before. So you can see the Odom frame there, that's jumping around a little bit. Our robot would also be subtly jumping, but it's hard to tell. Um, and I can start driving around. If I start driving a bit faster, we should see the jumps a little bit more obviously. Now, the odd thing you will notice is that we do seem to sometimes be creating new maps. At first, I thought this was just kind of part of how the pose graph-based system works, but the more I looked at it, the more it seemed to actually be doing mapping. So I'm not 100% sure what's going on there, but the point is that we can reload an old map and localize against it. Once we've generated our map with Slim Toolbox, we can actually use that map with other localization systems, which might be better for different situations. One of those systems that's

particularly popular is AMCL, which stands for Adaptive Monte Carlo Localization. Now, the standard ROS2 implementation of AMCL is actually part of the Nav2 stack. So, even though we're going to really be doing a deep dive on Nav2 in the next video, I'm going to go ahead and install it now. So, here's the command for installing Nav2. I've just copied and pasted this straight from the getting started guide. Note that if you're on Humble, the command is slightly different and you probably don't need the TurtleBot 3 stuff to start with. But if you're going to go ahead and do the Nav2 tutorials, it's going to be helpful. So, I'm going to go ahead and install that. Actually, running the Nav2 AMCL is a little bit clunky, and so it comes with a launch file, which is very helpful, and we're going to use that in the next video. But this time, we're going to do things the long way. It's a little bit more difficult, but it'll help us to

understand things a bit better. So, the first step of this is that we're going to run a map server. So, that's a node that's going to take that map file that we've saved and make that available on the map topic. So, to run that, I'm going to type ros2 run nav to map server and we want to run the map server node. Now, we've got some arguments for this. So, the first argument is going to be the YAML file name and that's going to be the path to the map YAML file. Now, it's actually in the current directory we're in, so I think it was mymap save.yaml. So, remember we're wanting the one that was saved rather than serialized because it's going to an external system rather than a slim toolbox. And of course, that other parameter is just going to be use_same_time and we'll set that to true. So, we run that and nothing's happening. If we have a look here, it says map server lifecycle node launched waiting on external lifecycle transitions to activate.

actually need to run something else to activate this node. It's kind of waiting in limbo. So, I'm going to open up a new tab and type for us to run `roslaunch nav2_util lifecycle_bringup`. And the one I want to start is the map server. So, if we go back to that, you can see it's found the image file, which was that PGM. So, it's loaded the yaml. The `amcl` node told it where to find the PGM. It's read the map, and it is now publishing it on the map topic. After then re-running RViz and Gazebo, we should see that our map is now loaded up. Now, we don't know where our robot is anymore. There's no localization running. So, as long as our fixed frame is on map, we should see this. Sometimes it doesn't show up properly. You might have to reset or turn the map on and off. Sometimes, like we see here, it's not showing up. We need to change the durability policy to `transient_local`. Sometimes it just works. Anyway, I'm not

sure, but it should be reliable and transient local. Um, and so, yep, we can see our map there. It's loaded up. The next thing we want to run is amcl to localize our robot against the map. So, I'm going to open up a new tab, and we're going to type rost2 run nav2 amcl amcl. And again, the only argument that we're going to provide this time is use sim time. Now, what I'm actually going to do, I'm going to go into gazebo. I'm going to drive the robot around a little bit, just put it somewhere, somewhere slightly different. So, just up here. So again, you can see amcl is now waiting to be launched with the lifecycle thing. So, this time, we're going to run lifecycle bring up on amcl. Nothing happens yet. If we go back to this, we'll see it's subscribed to the map topic. It's found the map. It says it cannot publish a pose or update the transform. Please set the initial pose. So, we need to give amcl a suggestion of

where the robot is to start with now. If you recall, it should be somewhere around here. So we're going to click the 2D pose estimate button in RViz. Make sure we're in the map frame and we can see our map. I'm going to click and hold and then drag in the direction the robot is facing. So it should be like that. And you can see I'm still off for a second and then found the robot. You might notice it printed this failed to transform initial pose issue. That can cause problems sometimes, but for now we're just going to roll with it. So you can see it's found where we are. It's got things a little bit wrong, but if we keep driving around, what we'll generally find is that it should stay roughly correct. Obviously, we're not generating new maps, so I can't go too far out of bounds. But if I go around, I should be able to do some pretty crazy things. And AMCL tends to be pretty stable at getting it back to where it is. It might

not stay perfectly accurate exactly where it should be, but you can see aerodyometry has now drifted way off. And yet AMCL has us located fairly well. You can probably change some of the settings and stuff for AMCL and really dial it in and get it working quite good, but this is pretty good for now. Instead, we're going to head to something more exciting, and that's to run SLAM Toolbox on our actual robot. All right, I've moved things inside the house to give us a bit more space. And to start off with, I'm just going to run the same control launch file that we've been using on the robot in previous videos. So I've launched that here, and once that's up and running, we should see our Odom in RVIZ. There we go. Then in another tab, we'll run the RP LIDAR driver, and then once that's up and going, we should see our LIDAR data as well. So hopefully we can get a bit of a sense of the room around the robot. So in our views, I've got the fixed frame set to

Odom at the moment, and now I'm going to swap to the dev machine and run slam toolbox. Now, this is exactly the same as we were running it for gazebo, but this time we've got Sim time set to false. So, with that running, we can enable our map in our views. Just give it a second to make the map. There we go. And now we can change the fixed frame back to map so that our map stays still while the robot moves around. One problem that we can run into if we're running slam toolbox on the dev machine but the lidar driver on the pi itself is issues with transmitting that lidar data over the Wi-Fi. So, in this case, I'm going to be getting packet drops and latency issues. And you can see in our views that the lidar data seems to kind of freeze up and jump around. And slam toolbox is going to be having to deal with those same issues. But you can see there the map actually looks pretty good. Slam toolbox is quite robust, and it's able to

deal with that jumping around. If that is a problem, though, we can, of course, run Slam toolbox on the robot itself. If you're going to do that, you want to make sure that the processor on the robot is capable of handling it. So it's probably going to be pushing the limits for the pie. For a small room like this, it might be all right, but you wouldn't want to push it too hard. What we're seeing here is really only the very tip of the iceberg when it comes to slam and mapping and localization. There's so much more we can do with different sensors like 3D lighters and cameras and Imus and different algorithms. So if that's something that you want to know more about, then let us know in the comments and maybe we can do more videos in the future covering different algorithms and deep dive into some of the crazy maths behind it all. So I want to give a big shout out to Steve and to everybody else involved in the creation of Slam toolbox. It's so great having a tool that just makes it

so easy to get up and going with SLAM and mapping, and localization, and that sort of thing. So have a go at playing around with some of the different parameters. Maybe start by changing the grid size. And then in the next video, we're going to see how we can use our map to navigate using Nav2. As always, thanks so much to the patrons over at Patreon who make these videos possible. If you've got any questions or comments about the things that happen in this video, you can check out the link to the discussion thread down in the description. And you'll also find links to the Patreon page and other good stuff down there. Alright, I'll catch you later. [Music]

Easy SLAM with ROS using slam_toolbox

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

Articulated Robotics

로봇 매핑 및 내비게이션에 ROS SLAM 툴박스 사용

이 동영상은 로봇 매핑 및 위치 파악을 위해 2D 라이더와 함께 ROS SLAM 툴박스를 사용하는 방법을 보여줍니다.

또한 생성된 지도를 Nav2 스택을 사용하여 자율 주행에 사용하는 방법도 보여줍니다.

동시 측위 및 매핑의 약자인 SLAM은 주변 환경과 알려진 랜드마크를 기반으로 로봇의 위치를 지속적으로 업데이트하여 GPS에 의존하지 않고 지도를 만들고 로봇의 위치를 정확히 파악하는 데 필수적입니다.

로봇 공학에서 SLAM, 그리드 매핑 및 좌표 프레임 이해하기

SLAM은 랜드마크를 사용하여 탐색하는 반면, 그리드 슬램은 세계를 셀로 나눕니다.

Odom을 기준으로 한 로봇의 움직임은 오차계 드리프트로 인해 작은 오차가 있을 수 있으며, 이는 GPS 또는 SLAM을 사용하여 보정할 수 있습니다.

지도 프레임을 도입하면 로봇이 Odom과 지도를 기준으로 부드러운 동작을 할 수 있어 ROS에서 부모가 하나만 있는 프레임의 문제를 해결할 수 있습니다.

지도 및 Odom 주제에는 주행 거리 측정 및 지도에 대한 데이터가 포함되어 있어 내비게이션 프로세스를 지원합니다.

ROS의 좌표 프레임과 SLAM 툴박스 이해하기

주행 거리 측정에서 기준 링크 변환에는 위치 정보와 현재 속도가 포함되며, 지도 주제는 그리드 맵의 점유 데이터를 공유합니다.

일부 SLAM 시스템에는 3D 이동을 위한 베이스 풋프린트 프레임이 필요하지만 이 튜토리얼에서는 2D SLAM에 중점을 둡니다.

ROS의 SLAM 툴박스는 다양한 모드를 제공하며, 이 튜토리얼에서는 옵션 설정에 유용한 실행 및 매개변수 파일과 함께 온라인 비동기 모드를 사용합니다.

로봇 매핑을 위한 SLAM 툴박스 구성 및 실행

SLAM 도구 상자의 매개변수는 워크스페이스의 구성 디렉터리에서 찾을 수 있습니다.

SLAM 도구 상자는 '온라인 비동기' 실행 파일과 '매퍼 매개변수 온라인 비동기' 파일을 사용하여 매핑 모드에서 실행됩니다.

RViz에서 "/map" 항목으로 맵을 추가하고 고정 프레임을 맵 프레임으로 변경하여 맵을 시각화하면 로봇이 맵을 안정적으로 유지하면서 움직일 수 있습니다.

맵 파라미터 조정 및 ROS2에 저장하기

맵 매개변수를 변경하면 영역이 확장됨에 따라 맵이 커지면서 로봇의 위치를 정확하게 유지할 수 있습니다.

ROS2의 SLAM 도구 상자는 지도를 이전 형식과 직렬화된 형식으로 저장하는 옵션을 제공하여 외부 사용 또는 향후 수정에 유연성을 제공합니다.

매핑에서 로컬라이제이션으로 전환하고 파일 경로를 지정하면 ROS2에서 로컬라이제이션을 위해 저장된 맵을 재사용할 수 있습니다.

로봇 공학에서 현지화를 위한 SLAM 툴박스 및 AMCL 사용

포즈 그래프의 첫 번째 노드는 지도가 처음 생성된 동일한 위치에서 시작하는 데 중요하며, 특정 공간을 지정하는 데 시작 포즈를 사용할 수 있습니다.

SLAM 툴박스로 지도를 생성한 후 이전 지도를 다시 불러와서 현지화할 수 있습니다.

Nav2 스택의 일부인 AMCL의 표준 ROS2 구현은 다른 현지화 시스템과 함께 지도를 사용하는 데 널리 사용되며 특정 명령을 사용하여 설치할 수 있습니다.

로봇 현지화를 위한 맵 서버 및 AMCL 실행

맵 서버를 실행하여 맵 주제를 게시하고 RViz 및 Gazebo를 다시 실행하여 맵을 로드합니다.

그런 다음 AMCL을 실행하여 맵에 대해 로봇을 로컬라이즈하고 초기 포즈 제안이 필요합니다.

잠재적인 초기 포즈 문제에도 불구하고 AMCL은 일반적으로 안정적이고 정확한 로봇 측위를 제공하며, 성능 향상을 위해 설정을 조정할 수 있는 기능을 제공합니다.

로봇 매핑 및 현지화를 위한 SLAM 툴박스 실행하기

이 프로세스에는 제어 실행 파일, RP 라이더 드라이버, SLAM 툴박스를 실행하는 동시에 Wi-Fi 전송의 잠재적인 문제를 처리하는 과정이 포함됩니다.

SLAM 툴박스는 처리 능력을 고려하여 로봇 자체에서 실행할 수 있는 가능성을 통해 라이더 데이터 문제를 처리하는 데 있어 견고함을 보여줍니다.

이 영상은 또한 SLAM의 이면에 있는 다양한 센서, 알고리즘 및 수학을 다루는 향후 영상에 대한 잠재력을 암시하는 동시에 SLAM Toolbox의 제작자를 인정하고 다양한 매개변수를 사용한 실험을 장려합니다.