Closed joeyzhu00 closed 5 years ago
Are we doing 2D mapping instead of 3D?
Me and Francisco are going to try to get AMCL working as a backup plan which uses laser scans rather than point clouds. Nelson expressed interest in doing 3D mapping, so I think we're going to go with that route after we get AMCL working.
Ok, any reason why you guys chose AMCL over Gmapping?
Ok, any reason why you guys chose AMCL over Gmapping?
Or do you guys plan to build a map with Hector Mapping and then run AMCL?
Gmapping seems to be pretty tempting because it is a SLAM based package and has the mapping component embedded. I'm not sure which package would be more accurate between AMCL and gmapping.
There is also cartographer from Google which is a 3D approach.
One thing that I am concerned with map building at the moment, specifically 2D maps, is the construction going on Campus right now. Since a lot of things are being moved around (LOL A.S. House), the lack of visual features provided by 2D maps might not work well for outdoors map-based localization. I think we should definitely try it with indoor though.
Gmapping seems to be pretty tempting because it is a SLAM based package and has the mapping component embedded. I'm not sure which package would be more accurate between AMCL and gmapping.
I did some googling around and seems like people have a better experience with AMCL than Gmapping. They said Gmapping's SLAM map isn't that stable and useable. I think AMCL might be the way to go, now just the matter of what to use to build that 2D map.
The Cartographer package looks well supported, but I am not sure how well it works/ accurate it is for self-driving localization purpose. Since you had your eyes on the 2D mapping already, maybe try out the 2D approach first? Even if we can build an indoor map that would be dope!
The ROS Navigation stack seems to endorse Gmapping http://wiki.ros.org/navigation/MapBuilding, but I think that we will be using AMCL + hector_mapping. I think that the performance outdoors may be hindered as you mentioned because of the lack of features but I think that this is still worth pursuing. We will be building a 3D map-based localization package as well, but the in-depth tutorials in these packages made it pretty tempting to get these working to at least have a comparison between our methods and the methods that are out there already.
So it looks like the lidar driver actually has a /scan output. I didn't notice that until I started trying to get pointcloud_to_laserscan working (didn't output anything in its respective topic when i fed it a bag of lidar data). The lidar driver's method is to just read off of a single scan line. Do you guys think that it would be appropriate to just use the built-in scan feature from the velodyne driver or should we look for something that accounts for all of the point cloud data to generate a scan message?
@joeyzhu00 the pointcloud_to_laserscan
might be looking for a specific topic name that isn't currently publishing.
I think it would be safer to try to get it to work to get a more accurate representation of the 3D data, rather than relying on a single scanline. If this takes more than a few hours, however, probably just put it on hold for now and use the builtin /scan
Hated trying to get cartographer to work when I started using ROS two years ago, but now that I've learned how to do message sync I wouldn't mind tackling this again
I ended up using hector mapping for localization, I used the odom it produced to fuse into robot_localization
Would be interesting to compare
the pointcloud from velodyne vs scan from velodyne vs pointcloud to laser scan
Point cloud to laser scan for 2D scan matching with pointcloud_to_laserscan.