Odometry equation

I was working on a maze solver last night and came up with an equation that will let me choose the radius of the circle I want the bot to turn on for a differentially steered robot. I'm sure someone else has thought of this, but I haven't seen it on the web so I thought I'd post it...

X=1-(1/((r/b)+.5)) Where: r=radius of the turn at the center of the vehicle b=distance between the wheels X=ratio of speed of inside wheel to outside wheel

Therefore the radius of the turn at the wheels will be r+(b/2) and r-(b/2)

As long as X stays constant, the bot should stay on the same circle, albeit traveling at different speeds. To do a full speed turn, set the outside wheel at 100% and the inside wheel at X%. As an example for a maze with 11" wide corridors(r=11/2=5.5"), and a vehicle with b=4.225", X will be .445. So the outside wheel travels at 100% and the inside wheel travels at 44.5%.

I haven't tested this yet on a working bot, so acceleration effects may make it worthless if the motors aren't powerful enough to change speed rapidly.

For more odometry info check out G.W. Lucas' great paper "A Tutorial and Elementary Trajectory Model for the Differential Steering System of Robot Wheel Actuators" and the Rossum project at

formatting link
Anyone think this equation will be useful? Has anyone seen it somewhere before?

Jeff Kroll

formatting link

Reply to
protaganistus
Loading thread data ...

Jeff,

Thanks for the favorable review!

With regard to your equation, I note that you can write X=1-(1/((r/b)+.5)) as X = (2r-b)/(2r+b) The nice thing about the alternate form is that you can see from inspection that X is going to be a negative value when you try to execute a turn radius that is less than half the distance from tire to tire. You're also spot on in pointing out that you'll maintain the same circular path no matter how fast your tires turn as long as the ratio of their velocities remains the same.

If velocities remain constant, the equations for differential steering have a satisfying closed-form solution. If you add acceleration into the mix, they don't. The MotionApplet at

formatting link
does implement a solution for acceleration using Simpson's Rule. If it is of use to you, I encourage you to steal the code and adapt it for your needs (the computations, at least, should translate easily from Java to C or Basic). Of course, the motion applet assumes a constant acceleration... Naturally, in real life it's messier yet because acceleration is a linear function of torque and in a DC motor torgue varies as a function of speed.

For a long time now, I've thought that it would be interesting to write up code for trajectory planning... not path planning which is a challenging problem involving navigation and such, but simply the inverse kinematics part of the problem. If I am here, how do I get there? (based on certain initial conditions and other constraints). So let me offer an invitation to the good folks here on comp.robotics.misc. If you can give me some feedback on a) whether you think you could actually use it and b) a reasonable set of specifications for inputs into the model (based on what you would actually have and what problems you were trying to solve) I'll take a crack at writing some logic for trajectory planning. I'll probably write it in Java or C, but I'll stick to "generic" stuff that can be translated in a straightforward manner.

Gary

Reply to
G.W. Lucas

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.