can't make the good result using your rosbag(from#30)

[kintzhao]

@damonkohler ,thanks for your rosbag, but I do it as your commit at #30 twice and get different result, not fine. my rviz display as following picture:
could you give me some advise to achieve the result as your paper.

[SirVer]

tl;dr: The different results for multiple runs tell me that your machine is not fast enough to keep up with the replay.

The example you run works this way: It brings up a ROS system in which rosbag replays data in real-time. Cartographer processes this data in real-time as well - and if it is too slow, data gets dropped by ROS (buffers run full). Cartographer is 5.3x real-time on my Intel Xeon E5-1650 3.2 GHz, so it should be real-time on a less powerful machine as well if you keep enough CPU headroom by not running other heavy processes.

One solution that we consider implementing is a "offline" version of Cartographer that directly consumes a rosbag and just runs through it as fast as possible without giving ROS a chance to drop any data. We have something like that for our internal version.

@kintzhao What machine do you have? Are you doing something else CPU intensive while running the examples? look at top's output to know for sure.

[kintzhao]

asus K550J, intel i7-4710HQ , 8G memory. I don't think it is caused by machine. and i just run this , rosbag record -a , and video record.

[kintzhao]

@SirVer ， I stop rosbag record and try again. The end of processor is not fine, can not correct it.

rviz
top

the later part of terminator print :
cartograph_log.txt

[SirVer]

@kintzhao Your system is pretty loaded as top shows and the log output shows that the background processing falls behind (there is no "We caught up message"). The good news is that the local slam is processing all data in timely fashion (that is the "processing at 100% real time"), so no data is dropped. Did you change any settings? Are you compiling in release mode?

Also, did you pull after #44 was merged? If you do, just leave rviz and the process running and the background processing will eventually catch up and you should end up with a nice map - you will see the map still changing after the ROS bag has finished playing back as the background processing catches up. #45 is tracking the retuning to make background processing fast enough for real time.

[kintzhao]

I do not change it, and compile it using ctkin_make_isolate.

I update the repo to commit id (a2567ab), try it and get the result as this. the background processing need too much time to corretct it (may be 10+ minutes). The last pic is wait for finish optimizer(watching the output top to guess it)

could you tell me the type of your actual device of laser and imu ? and your laser message is not standard ros laser message in your rosbag?

[wohe]

As sensors we use two Hokuyo UTM-30LX-EW. This is a multi-echo laser scanner, so we use sensor_msgs/MultiEchoLaserScan messages instead of sensor_msgs/LaserScan.

[kintzhao]

@wohe Thanks for your answer. How about the accuracy of IMU ? Does it a general MEMS(Micro-electromechanical Systems) IMU, such as mpu6050? Is it necessary to specify particular IMU, if I want to test it on my actual platform?

[SirVer]

@kintzhao We use the 3DM GX4 25 for 3D - but other teams use less powerful IMUs, so that is not a requirement.

For 2D, you can completely turn of the usage of the IMU. The system then assumes that the laser is parallel to the floor at all times. This is what we used for the Neato laser map in the paper.

[wohe]

@kintzhao I could reproduce the bad loop closure performance: The issue is that function calls in ProbabilityGrid::GetProbability() are not properly inlined which severely harms performance by orders of magnitude. Interestingly, the unit test is compiled properly and fast. Likely an issue with how the build is set up. @SirVer is working on a fix.

[wohe]

Explanation of what happened: cartographer_node was built unoptimized and the linker had two versions of ProbabilityGrid::GetProbability(). It decided to use the unoptimized one from cartographer_node instead of the optimized one in the cartographer library.

@kintzhao On my system it seems fine now. Could you verify that this fixes the issue for you and reopen otherwise? Thanks.

[SirVer]

@kintzhao Also thanks for bringing this to our attention!