LaserScan is shifting and dancing as the robot moves
My laser scan is shifting / dancing as the robot moves. I don't know what might be causing this... It stabilizes sometimes but most of the time the behavior is similar to this .
What should I look at to fix it?
I dont hve amcl running with my navigation stack, could that be it? I didnt judge that I would need it since the localization is happening in a different framework and I don't seem to have any problem with that.
(more)Basically what I am trying to accomplish is use ROS's navigation stack for my Isaac SDK application. So what happens is that I am sending raw scan data from Isaac, odom data from Isaac, the start pose and the goal pose from there and I am letting ROS plan out and move the robot around. ROS sends cmd_vel commands to my Isaac app which converts it accordingly to move the robot. In isaac, there is a particle filter localizer that takes the raw scan, adds some noise to it and works like any particle filter localizer would (I assume). And I can say it works fine since with Isaac applications no problems were seen at this level.
On ROS side, nothing... as I said, everything is being sent from Isaac for the navigation stack to do its job. I thought amcl would help the nav stack on ros side ...
Are you merging the 2 scans before going into a single particle filter, or do you run a particle filter for each scan frame? Have you verified that only 1 source is generating the robot pose?
Both scans are being merged inside the particle filter component. The component by itself works fine in all apps I worked with
On a side note, would you be able to give me some input on this issue as well? I would appreciate it a lot!
So does the output from the particle filter jump around, as @janindu speculated?
Did you figure out what the problem is? If so, please post an answer to help others in the future.
I did not yet! I am planning on trying soon... For now I am stuck with this problem if you don't mind taking a look at it. I will definitely post an answer as soon as I manage to get my hands on that
It seemed that it was a computational power problem. I am not sure of it, but I ran my simulation on a more powerful computer and this problem occurred less often. I unfortunately didn't manage to try implementing amcl to see if it would fix the problem.