-
Notifications
You must be signed in to change notification settings - Fork 2
Localization on Map/Loop Closure in sim_autocross_track.launch #18
Comments
I have figured out the cause of this issue. However, it might not be worth our time to solve it. SituationThere are two localization nodes which currently change the robot's position (which is stored as a TF coordinate).
IssueWhen the robot returns to the starting point, there is a slight drift in its perceived position, so the two ends of the explored track do not align perfectly. Thus laser_scan_matcher does not find a satisfactory solution for the translation of the robot. Instead, it finds a halfway solution for the displacement which results in the slipping behavior we see. Simple fixes
Why fixing this is a Bad IdeaIn investigating this issue, I found some key shortcomings in our current localization method.
Long Term SolutionI suggest we switch to a more fully featured localization method, such as the position tracking available out-of-the-box from the ZED camera SDK, or one of many 3D lidar odometry libraries. |
@Reschivon very nice job on finding that and giving a detailed analysis of the issue! This is another great example showing that the original design was quite incomplete with large holes. Eventually leading to problems like these that require ugly band-aids or a near-complete re-design. With that, I totally agree that this is not a long-term solution, and trying to fix this issue will probably be a waste of our time. Instead, we should focus our efforts on designing v2. |
@Reschivon I created the node to clear the map created by I looked at the parameters for hector_mapping too and couldn't find anything related to launching these services. I looked into the implementation and it looks like they are creating the services right here so I am not sure why none of them are showing up. |
See here for more details: #18 (comment)
@zghera That is indeed strange. I don't think it's likely to be a bug in Are services available for other nodes? Would it be okay to use a modified version of Hector like we do for |
@Reschivon I had the same thoughts as you for each of your points/questions. We could try mucking around with Hector like I did for stage_ros and laser_scan_matcher but I am not sure how time intensive that would be. And here are the services that I get with |
I am going to close this issue as we have split off into a few smaller sub-issues based on the two approaches to fix loop closing based on discussions:
|
Current/Incorrect Behavior
https://user-images.githubusercontent.com/39711376/103718929-e378d380-4f95-11eb-806f-ed28c6e52c6f.mp4
This video was recorded after the first successful run of the
sim_autocross_track.launch
when substituting teb_local_planner's config for move base in place of our own in #11.As in the video above, the abnormal behavior starts once the kart completes a full lap around the track. More specifically, the issue occurs at the "loop closure" on the simulation: connecting the most recently mapped part of the track to the first segment of the track generated.
At the moment the map of the track is nearly complete, it looks like the mapping module tries to re-adjust the walls it has already (recently) mapped. This adjustment seems to propagate as the robot tries to navigate through the track composed of walls from the 1st pass of mapping and the adjusted map. At some point, the robot will run into the walls from the 1st pass because they span the width of the newly adjusted map.
Target Behavior
Upon the connection of the map edges, recognize the loop closure to use the current map and update it as we do more passes.
Potential Approaches to Fix
The text was updated successfully, but these errors were encountered: