Laser_scan_matcher with AMCL amd move_base

asked 2023-07-24 16:35:57 -0500

KevWal
11 ●6 ●9

updated 2023-07-28 11:19:06 -0500

Hi All

I have been playing with ROS1 for 6 weeks or so.

I have a robot built - 2 motors and a caster - differential drive, pi 4 (no arduinio etc), motor controllers, 2 x wheel encoders, ld19 lidar, ICM20948 IMU.

I have Ubuntu 20.04 on the Pi and on a virtual machine on the laptop, ROS Noetic installed on both, a driver node and odom node written, ld19 and imu drivers working into ROS.

My (I say my, mostly used from various tutorials) code is all here: https://github.com/KevWal/ROS-Bot-Wor...

I want to get it navigating from a Pose estimate to a Nav Goal, based on a pre built map, but I cant figure out the correct componets I need doing what transformations.

I have built the map ok using hector_mapping with no odometry from my encoders (launch file). (My odomery is rubbish for some reason).

Now I think I need laser_scan_matcher, AMCL and move_base, to give me odometry, alignment with a map and navigate to goal functionality - but I'm not having much luck.

Is that the right architecture?

What should laser_scan_matcher's fixed_frame and base_frame be set to?

What should amcl's odom_frame_id and base_frame_id be set to?

Thanks very much

Kevin

edit retag flag offensive close merge delete

add a comment

answered 2023-07-27 08:14:52 -0500

Mike Scheutzow
4918 ●2 ●430 ●45

The configuration that most people with a lidar start with has a Transform Tree that looks like this:

map -> odom -> base_link -> scan

map->odom TF is generated by amcl using map + scan input.
odom->base_link TF is generated by odometry using wheel_encoder input.
base_link->scan TF is a static (fixed) transform.
the base_link x,y pose must be at the center-of-rotation for the robot (i.e. midway between the drive wheels for differential drive).

You should really try to debug why your encoder odometry is bad. As long as your wheels are not slipping on the ground, the output should be pretty accurate over a few meters/turns. If you see a lot of drift, I expect that you probably have an odometry calculation error (a lot of people get the plus/minus sign for the axel direction of rotation wrong.)

Using my TF names from above, amcl's odom_frame_id is "odom" and base_frame_id is "base_link".

While I believe it is possible to use laser_scan_matcher to generate odometry, I've never tried to do that. Typically laser_scan_matcher would substitute for amcl and generate the map->odom TF (but laser_scan_matcher is less capable than amcl, so nobody does this without a real good reason.)

edit flag offensive delete link

Comments

Thanks for the details Mike. I did a video of my odom while rotating, you can see that sometimes it is fine, sometimes it is not very good: https://www.youtube.com/watch?v=JPdHX... I dont believe the wheels are slipping. Forwards and backwards is very acurate, I will do another video trying to clearly do a single step by single step.

KevWal ( 2023-07-27 09:51:40 -0500 )edit

Second video here - https://www.youtube.com/watch?v=fkxcI... - you can see the ahead and back I think is ok, the first 90 deg turn goes ok, but then the 2nd, 3rd and 4th 90 anti clockwise turns it goes wrong, all 4 clockwise turns are actually not bad - but of course all offset by the bad 2nd, 3rd and 4th anti clockwise turns.

KevWal ( 2023-07-27 10:28:41 -0500 )edit

Forward was accurate. Backwards was not. According to ODOM and the laser, the wall followed the robot as it moved back. Watch where the wall is on the grid during both motions. And of course you already know there is serious issue on rotating where small linear errors are magnified. There is not much use in trying to get AMCL working until you determine the cause of the ODOM errors. Could be mechanical (wheels slipping on axles), wheels slipping on floor, backlash, missing encoder data, math errors, etc. Start with calibration of the encoders. You'll find info in the ROS nav-stack tutorials. I think in another post you said you had poor resolution magnetic encoder? Do those have two channels so you know rotation direction or do you have to guess at rotation direction.

billy ( 2023-07-27 13:26:27 -0500 )edit

Im not sure what the done thing is re editing the original post vs coments and what causes notifications, but anyway I have added lots of encoder test data, any thoughts welcomed other than my plan about slightly different l vs r ticks per meter values...

KevWal ( 2023-07-28 09:32:11 -0500 )edit

This site tries to follow a (single) question & answer format. The question you asked on this post is "Laser_scan_matcher with AMCL amd move_base". That got an answer.

If you now want to change to a different subject to ask about debugging your robot's odometry, please open a new question. It's fine to include urls to prior questions if you think it provides useful background info, but each question should be understandable on its own.

Mike Scheutzow ( 2023-07-28 10:15:54 -0500 )edit

Thanks Mike, removed and posted as a new question. https://answers.ros.org/question/4178...

KevWal ( 2023-07-28 11:19:29 -0500 )edit

add a comment

Laser_scan_matcher with AMCL amd move_base

1 Answer

Comments

Question Tools

Stats

Related questions

Laser_scan_matcher with AMCL amd move_base edit

1 Answer

Comments

Question Tools

Stats

Related questions

Laser_scan_matcher with AMCL amd move_base