Can I fix my odometry given my current encoder precision?

asked 2018-09-19 05:41:10 -0500

fourchette
41 ●4 ●6 ●6

hello, I made a simple 2WD mobile platform to evaluate ROS navigation stack. it is made of

the main chassis = lasercut acrylics
wheel / motors / encoders => dfrobot double wheel kit ( https://www.dfrobot.com/product-1203.... )
arduino uno to read encoder values (hardware interrupts) + implement PID of the motor (speed control)
raspberry pi 3b+ to run ROS kinetics

After struggling a lot trying to tune move_base, then ACML.I stumbled upon the navigation tuning guide => http://wiki.ros.org/navigation/Tutori...

Here the author suggests to make two sanity checks on odometry. the test about linear precision/drift is OK (running towards a wall). However, the angular drift fails. see rviz screenshot below. It's obvious there's something wrong: ~30 degrees of drift is unacceptable.

Now the question is: Can i fix it with my current hardware or should I upgrade my hardware? (for instance use higher encoder resolution)

some additionnal info - wheel diameter 136mm (width 24mm) - distance between the two wheels 328mm (from the center of their 24mm thickness) - encoder resolution: specs claims 663 ticks per wheel revolution. but i measured ~653 and used that value for odom calculation - i dont need the robot to move fast. slower than walking speed is ok (my goal is to test ROS nagivation stack here)

136*math.pi=427.2566008882119 mm per rev 427.25/653=0.63mm per encoder tick... dunno if it is precise enough

My worry is that the motors and encoder seems tightly integrated together. I just don't know how to "just increase the encoder resolution by changing the encoder". So I would end up buying another motor/encoder/wheel... adjust the chassis... maybe upgrade the arduino as well since a basic Uno might not cope with additionnal data... well I could end up with an entirely robot. Besides, dfrobot sells this kits precisely for what i intend to do, so it should be more a problem of my code than hardware not precise enough...

for now, i'm betting on my own code to be broken (= i dont need to change the hardware) :D

image description

edit retag flag offensive close merge delete

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2018-09-19 06:23:58 -0500

john.j.oneill

flag of United Kingdom of Great Britain and Northern Ireland

136 ●2 ●5

My guess is that you should have sufficient encoder resolution for much better accuracy than you are seeing. I've gotten passable results with ~100 counts/rev so you should be in the correct ballpark. The tests you are running are going in the correct direction, but you can continue more tests to try to determine the issue.

Check for missing counts: Using the arduino with hardware interrupts you shouldn't be missing counts. But then again, if the spec says 663 counts/rev, you should probably not be seeing 650. One way to check for this is to write a quick position controller, put a mark somewhere on the wheel and have it go exactly 100 turns. The marker should be more or less exactly where it was when you started. If it doesn't, and especially if the place it lands changes every time you run the test, you are probably missing encoder counts, in which case you want to investigate what's going on with the arduino.
Check for different wheel sizes: Most odom documentation assumes the wheels are the same size. In reality, they could be different by even a few percent, which could throw things off. Make sure you are getting your wheel diameters separately for the two wheels.
Are you using the centre of the wheels to measure the wheel to wheel distance? You should measure centre of wheel to centre of wheel. Also keep in mind that using wide flat wheels is the worst for odometry.
Are your wheels slipping? Make certain that you do these tests on a hard grippy surface, and go slow enough that the wheel controllers are well within their achievable range.

This isn't meant to be an exhaustive list, but hopefully you can get this working without throwing out your hardware, and yes, those encoders that come attached to the motors are usually not meant to be user-replaceable, so you may have to replace the motors too.

edit flag offensive delete link

add a comment

answered 2018-09-19 10:16:49 -0500

fourchette
41 ●4 ●6 ●6

updated 2018-09-19 10:17:10 -0500

thanks for the detailed answer. In particular regarding the fact that distance between wheels should be measured from the center of its width (i wasn't sure).

and yes my wheels do slip, but only when i suddently stop the robot without carrying load. (i need to better handle sudden decelaration it seems)

In fact, it turns out that the base_width parameter was declared outside the <node> in the launch file and the node code was using '~base_width':

self.base_width = float(rospy.get_param('~base_width', 0.3)) # The wheel base width in meters

However, that tiny '~' made that the value given in the launch file (0.328) was not used, therefore the base_width was using the default 0.3. That 300 vs 328 mm discrepency in turned explained why the linear odometry was somehow ok-ish but the angular odometry was clearly broken.

now i'm getting this:

image description

there is drift, but it's clearly much better.

Does it look ok? I really have no clue if it's acceptable or not.

edit flag offensive delete link

Comments

It's certainly better. There's no "acceptable" because the Nav stack can compensate for poor odometry with more/better features, so it depends where you are. You can try to tweak your numbers to get a better result, but at some point you will reach the limits of your wheel thickness anyways.

john.j.oneill ( 2018-09-19 11:42:24 -0500 )edit

add a comment

Can I fix my odometry given my current encoder precision?

2 Answers

Comments

Question Tools

Stats

Related questions

Can I fix my odometry given my current encoder precision? edit

2 Answers

Comments

Question Tools

Stats

Related questions

Can I fix my odometry given my current encoder precision?