Giters

adler-1994 / gmcl

gmcl, which stands for general monte carlo localization,is a probabilistic-based localization technique for mobile robots in 2D-known map. It integrates the adaptive monte carlo localization - amcl - approach with 3 particle filter algorithms (Optimal, Intelligent,Self-adaptive) to improve the performance of amcl while working in real time........Main node structure and amcl-algorithms’s code was derived, with thanks, from Brian Gerkey's amcl package.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

gmcl node crashes when after increase the update rate

Alcatrazee opened this issue · comments

commented

I was using gmcl to localize my robot to replace the amcl, it works fine in the beginning, and it feels much better than amcl, however, when I decrease the parameter: update_min_d to be 0.001, and update_min_a to be 0.001( for I wish the pose to converge quickly) as I did to my amcl parameters, it crashes when I run the amcl_omni.launch, after multiple times of updating, I tried the combination of those algorithms but it all just got the same crashes, and also, I've set all the odom_alphax parameters 10 times lower. P.S. I was using a differential robot with two lidar, I cannot use the motion model of diff because my robot will move backward, and when it did moving backward in a low speed, the gmcl( so does amcl) doesn't update, only the omni model works in slow speed and fast speed. So what is the problem of this crashes? I really wish to use this new techneq to improve my robot's localization ability and relocalization ability. Thanks

commented

Hello Alcatrazee, Thanks for your feedback.. I have tried the "update_min_d := 0.001, and update_min_a := 0.001" in a simulation and they worked just fine... The crash might be because of buffering overflow due to lack of processing power, since you also use 2 Lidars. As advice I would recommend either decreasing the ”laser_max_beams” parameter or decreasing ”max_particles” parameter.

Instead of decreasing odom_alphax parameters try to set "odom_model_type" to "diff-corrected" or "omni-corrected" this might also fix your problem.

As a standard, differential drive mobile robots cannot move backward. When they want to go the opposite way they do a 180° degree turn and move forward. That's the reason you are not receiving any motion update.

I hope my comment was helpful and wish you a nice day.

commented

Hi, thanks for your comment, I'm not pretty sure the reason of the crashes is lack of processing power, I've checked the cpu use with command "htop", and it never reached 100% for all cores, so does the memory( my on-board computer is using a i5 6th processor and 32GB of memory, 512GB of SSD).

I've rolled back the odom_alphax back the the default value , they also works fine, so I will leave this parameters in default value.

I've realized that I don't really need such a high update rate, so now I've set the update_min_d to be 0.1 and update_min_a to be 0.1, the crashes never happen again, so I guess the crashes might be due to the buffering overflow. I think it's ok to use the default value of "laser_max_beams" and "max_particles".

I understand a differential drive robot is unable to move backward, the strange thing is that when I go backward in a fast speed, the motion updates, but when I move backward in a low speed (<0.1m/s), it won't update, which is weird.

Anyway, your comments helps a lot, thanks.

commented

I am glad that everything worked fine with you… Do not hesitate to open another issue when you encounter any problem.