Navigation Issues: Local Costmap doesnt match the Static Map after inital Navigation
Hi All,
Please i need yall help
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...
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
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)
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
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.
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
overflowing the encoder counters?
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
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.
To help out with the confusion.
Navigation works alright, i can navigate to some rooms well.
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.
Nothing is wrong with the map, i posted just to show the length of the hallway
Does this help @billy?
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?
Yes, but I am saying the encoder counts only fails at that particular location in the hall way, and “encoder count exception” means investigating this means that ticks were not gotten at that point in time from the encoders
Hence my confusion, this only happens at that particular point in the hallway, and sometimes it doesn’t throw up that error but localization still fails at that particular point in the hallway
How do I check if the encoder is been overflowed? @billy
If its 32 bit in the arduino you don't need to worry about it overflowing in any reasonable time frame. If it's 16 bit then overflow needs to be anticipated and accounted for. By overflowing I mean wrapping around from most positive number to most negative number.
I use an Arduino Uno, so I guess it’s an 8 bit microcontroller @billy
I can think of only a few reasons for any particular location to create an ODOM error, first being that that location is far enough away from where you start the robot that the encoders overflow. I assume the encoders are optical (not magnetic) and that they are encased within the motor so that there isn't any environmental influence in that location that could create the issue. It's is conceivable that there is a high RF field in that location that is interfering with the electronics.
The arduino being an 8 bit uC doesn't mean that your encoder counters are 8 bit. They can still be 16 or 32 bit. I suggest you do a little research and make sure they are defined in the code as 32 bit. I am suggesting this because you are having encoder issues and this means you need to understand the ...(more)
The encoder is an incremental encoder.. I am also very confused on why it cant get past that particular location, and once that happens, the amcl pose array jumps to another position on the map, which brings me to ask if it could be that the Lidar scans of that particular location is similar to the Lidar scans of another location on the map look forward to your response @billy
You can differentiate if the issue is coming from an AMCL jump vs ODOM jump by watching ODOM.
If the ODOM message doesn't jump when localization with AMCL does jump, then you'l know it's AMCL. In my experience however, sudden jumps in position during navigation have been caused by errors in ODOM. I've never seen AMCL simply jump the robot to somewhere else, because it puts the pose estimates tightly packed around the current pose. It doesn't just through pose estimates far away in the map for fun. However if the ODOM message has an error, it will be perfectly happy to jump the robot all the way off the map. Focus on ODOM and start troubleshooting. Find the discontinuity in the data where it suddenly jumps. Put a trap in your code to catch an impossible change in encoder counts to help you find ...(more)
@billy you are a life saver The two locations in the hall way where the encoder gives errors and the robot acts up have an wires running directly across the hallway, so that jams the incremental encoder..(environmental influence)
Thanks so much I just noticed that today
Cut those wires!
Hi Billy, can you assist with this please?
https://answers.ros.org/question/3526...
@billy Look forward to your response. Thank you very much