search

skasperski / navigation_2d

ROS nodes to navigate a mobile robot in a planar environment
GNU General Public License v3.0
123 stars 65 forks source link

Weird lines/edges in map generated by mapper in Tutorial 4 #61

Closed aditi741997 closed 1 year ago

aditi741997 commented 3 years ago

Hello

I have been running the code for Tutorial 4 with default parameters, [except for MinimumTravelHeading: 0.43, grid_resolution: 0.04 for mapper], but when i run the exploration code 10/20 times, in some runs, the mapper produces a bad map, i.e. with many extra edges where there is no wall in the simulation envt [using the same envt as in tutorials, just with extra robots]. I have added the simulation envt screenshot [blue robots move in a straight line and red robot is trying to explore the area], along with some bad maps on the following link - https://drive.google.com/drive/folders/1PJ43N7bd7816_hfljH2jfhVwR2T35Rj4?usp=sharing I was wondering if anyone knows possible reasons for this behavior. Thanks!

skasperski commented 3 years ago

The maps are really broken, so at least the robot seems to be very badly localized. Do the blue robots map as well?

Unfortunately it's hard to diagnose just from seeing the map. Especially if the issue occurs only in 50% of the runs. If the mapping robot is surrounded by many blue robots, it is possible that the scan matching fails, because there is not enough environment visible anymore.

aditi741997 commented 3 years ago

Thank you for the response!

The blue robots don't map, they are being controlled by a separate node which just moves them along a straight line. a. The robot will be surrounded by only one blue robot at any given time, can it still lead to scan matching failing?

b. Can the bad localization be caused due to the scan sometimes using latest odometry tf instead of the transform with the same timestamp? [https://github.com/skasperski/navigation_2d/blob/711a5609dcb9f47fc2ccec445762c9043bdf0d0e/nav2d_karto/src/MultiMapper.cpp#L315 ]

c. Also, What would the scan matching failing result in? Does it mean that the robot won't realise in its in a similar area and draw extra non-existent edges in the map?

skasperski commented 3 years ago

a) Good question. I don't think that one robot should be enough to make the matching algorithm fail that hard. But might be worth some research.

b) In a realtime-setup (e.g. not bagfile) this should also not make such a big difference. And when tf-lookup fails, you should see corresponding warn messages in rqt_console.

c) Mostly it will misjudge it's current position and draw the current scan in the wrong position. This is what happened a lot in your run1. The robot estimated some rotation, which wasn't real, resulting in many misaligned scan readings.

skasperski commented 3 years ago

Btw, did you make sure that the robots never collide? This would definitely explain the map in run1.

aditi741997 commented 3 years ago

For run 1 : actually yes, the robot collided with one of the blue robots after ~19s, and the exploration failed after a total of ~60s from when the StartExploration goal was published. Why does a collision lead to such a map? I mean, the odometry from stage simulator should still be a good estimate of the robot's position, right? [The reason I'm asking is that I've also seen exploration runs where the mapper's map is fine but exploration fails due to a collision]

Also, I added 2 more maps to the link above. The maps for run 4, 8, 17 also have such extra edges, and the robot did not collide with any of the blue robots during the exploration runs that generated these maps. What other factors could lead to scanMatching failing, other than collision?

skasperski commented 3 years ago

Why does a collision lead to such a map? I mean, the odometry from stage simulator should still be a good estimate of the robot's position, right?

No, Stage does not simulate an IMU and we are not using ground_truth information either, so when the mapping robot is pushed around by another one, then its odometry will be completely off and scan alignment will not be able to fix it.

aditi741997 commented 3 years ago
skasperski commented 3 years ago

No, unless the robot hits any obstacle the odometry in Stage should be quite accurate.

The offset transform is required for multi-robot mapping to relate the different start positions of each robot to each other. For the first robot it is always identity and can be safely ignored. For the sake of generality it should always be there though.

Always using the last available transform is generally a bad idea, because it does work badly when there is some delay in a real system and it does not work at all when working with bag-files. The normal case should always be to ask TF for a transformation that matches the time stamp of your sensor data.

aditi741997 commented 3 years ago

Okay makes sense. So, I was wondering what other reasons could explain the bad map scenario [I experimented with static robots as well. If there's just one stationary robot, the mapping works fine, but if all 8 robots are present & stationary, even then we get bad maps like the ones in the drive link above].

  1. At the mapper, there are thresholds related to openKarto, namely MinimumTravelDistance and MinimumTravelHeading. Is it possible that changing them (so that the mapper processes more/less scans) can help remove the bad map issue?

  2. The navigator asks the tf library for the latest transform from map to robot frame [https://github.com/skasperski/navigation_2d/blob/8e8366ce5440be0aca11d2d53ea1d1c33b3b9811/nav2d_navigator/src/RobotNavigator.cpp#L931 ]. This is a combination of map - odom published by mapper and odom - robot frame published by stage. If lets say the latest map - odom transform published had timestamp t1, then because the tf library returns the tf only if the timestamps match, the returned tf will be for time t1 (assuming there's a odom - robot tf for time t1), however old t1 may be. Do you think it might be better for the mapper to keep publishing the map - odom transform at a higher rate, even if its actually updated only when a scan is successfully processed?

It'd be great if you can help identify other possible reasons for the scan matching failing / bad maps in the mapper. Thanks!

skasperski commented 3 years ago
  1. Yes, decreasing the distances between adjacent nodes usually improves the mapping result. Just have a look at the computation load, because more scan alignments have do be performed as well.
  2. As far as I know tf updates the whole transform whenever one transform in the chain changes. So there should be no need to update a transform that hasn't changed over time.
aditi741997 commented 3 years ago
  1. I see, I will try reducing the two thresholds incrementally and see if there's a configuration which gets no bad maps.
  2. http://wiki.ros.org/Papers/TePRA2013_Foote?action=AttachFile&do=view&target=TePRA2013_Foote.pdf the paper mentions [in section IV, point E, last paragraph of sub point 1] that querying for the latest transform returns the transform with latest common time. Wouldnt this be applicable to the lookupTransform call in the navigator?
  3. Another question that I had was, do you think changing the robot's size in p3at.inc file can affect the odometry / mapper's performance in any way? [I was hoping to change the size to square 0.56*0.56]
  4. I also noticed that the evaluateAction function in robot operator has different logic in the kinetic and melodic branches [the melodic branch uses escape weight as well] - I was wondering what difference do the two versions make in terms of the robot's behavior?