Navigation Issues: Local Costmap doesnt match the Static Map after inital Navigation

asked 2020-05-07 00:28:33 -0500

femitof gravatar image

updated 2020-05-09 16:38:06 -0500

Hi All,

Please i need yall help

  1. My Local cost map always almost doesn't always match the static map, hence path planning fails and it fails to reach its destination.A good example is I start navigation trying to go from point A to B and then B to C. I successfully navigate to Point B from A, but when i try navigating to point C from B, the local cost map is slightly different from the static map and thus might drive into walls or something. Please see image below: https://drive.google.com/file/d/1Ovo4...

  2. I am currently using Rplidar A2M8 laser scanner with a range of about 15-18m. Navigation works perfectly for short distances. I am working on navigating in a long hall way of about 50 meters, but at some points in the hallway, the robot acts all confused, and cant get to its destination. Is this because of the range of the lidar? Please see image of my map: https://drive.google.com/file/d/18UFT...

Please how do i fix this issues? Look forward to your replies as always..

I am stuck pleasee

edit retag flag offensive close merge delete

Comments

Remind us what your system is. Using AMCL and move-base? Wheel encoders for ODOM?

AMCL will only run a localization update periodically based on settings and it gets those from ODOM IIUC. So when ODOM reports a certain linear distance traveled or a certain amount or rotation since the last localization update, AMCL will rerun localization and update the pose.

When it does update it will make only small corrections to the pose at each update. So if you're rotating quickly with a slow laser scanner, you may have a situation where an error is generated by the additional rotation of the robot while the laser scan message is getting updated and there ends up being a large angle between the cost map/laser scanner and the static map while rotating. When you're done rotating and the laser should resync with the static map, you find an offset ...(more)

billy gravatar image billy  ( 2020-05-09 18:45:48 -0500 )edit

Yes.. AMCL and move_base and wheel encoders for ODOM.. I should reduce the max rotation speed and max linear speed by 50% of the .. i am guessing that you mean the max velocity x and max veloxity theta of the wheelchair yes?

WHat about Question 2? any ideas?

Thanks alot Look forward to your reply. @billy

femitof gravatar image femitof  ( 2020-05-09 19:40:37 -0500 )edit

What is it I am supposed to see in that map?

I'm not aware of any reason that a long hallway should mess up anything in ROS using ODOM and AMCL. But on your Arduino are you maybe overflowing the encoder counters? Are the counters 32bit or 16bit?

Long hallways are known to cause issues for laser scan matcher as once there are no moving features in the laser scan, laser scan matcher can no longer detect any movement.

billy gravatar image billy  ( 2020-05-10 03:01:39 -0500 )edit

Thank you billy @billy

I tried what you said, but the real issue is that at particular positions (two positions discovered so far) in the hallway, the encoder fails with an exception count and the localization (pose array) jumps to some other point in the hall way, this navigation to destination fails too.

The wheelchair/robot navigates just fine asides this two positions in the hallway, what could be wrong? Looking forward to your response and advise as always.

Thanks again @billy

femitof gravatar image femitof  ( 2020-05-10 12:49:54 -0500 )edit

overflowing the encoder counters?

billy gravatar image billy  ( 2020-05-10 13:06:08 -0500 )edit

No its not.. I believe cause i am using hector slam for a very long hall way with similar points hence the confusion. Maybe gmapping might have been a better map for a long hall way, since it takes encoders into consideration. @billy

femitof gravatar image femitof  ( 2020-05-10 13:23:30 -0500 )edit

Now I'm confused. I guess I need more info.

You said "encoder fails with an exception count". You need to follow up on that before anything else. Please post the details. And just to be sure, how do you know you are not overflowing the encoder counters. Are they 32 or 16 bit?

Also, you mapped a long hallway with Hector mapping and now AMCL and ODOM on Navigation Stack are having trouble navigating that hallway. Did you compare the length of the hallway from the Hector map to the real life length of the hallway?

Lastly - please tell me what it is I am supposed to see in the map you posted. To me it just looks like a map. I see nothing obviously wrong, other than it looks like the building extends beyond the edge of the map.

billy gravatar image billy  ( 2020-05-10 13:38:26 -0500 )edit

To help out with the confusion.

  1. Navigation works alright, i can navigate to some rooms well.

  2. I brought up the hector mapping cause i read on some other questions that for hector mapping with long hallways or tunnels, each scan looks nearly the same with no big changes and so the scan matcher without odometry has some problems which would negatively affect localization with AMCL, since odometry and Laser are used to estimate the pose of the robot.

  3. Nothing is wrong with the map, i posted just to show the length of the hallway

Does this help @billy?

femitof gravatar image femitof  ( 2020-05-10 13:45:29 -0500 )edit