DPRG
DPRG List  



[DPRG] Odometry and backlash

Subject: [DPRG] Odometry and backlash
From: Markus Lampert markus at bibi.ca
Date: Mon Jan 5 12:12:46 CST 2015

Hey Rud, Steve,
eventually I will want to incorporate visual processing. For now though I want to keep things as simple as possible and see how far they go.

Hi David,

those are good questions.

First off, I am currently not using UMBMark, mainly because I don't have access to a level and smooth 10' square - the virtues of living in an old house and our office building is all carpet.

What I did was I mounted a laser pointer on my robot and mark the spot on the wall where it hits. I then turn on a single wheel to the lowest PWM signal that still makes the robot move reliably. I count the encoder ticks until I should have completed a full circle and measure where the laser pointer ends up in relation to where it started off. The intent was to do that in both directions and thereby get the accurate ratios of right wheel radius to wheel base and left wheel radius to wheel base. Which I then can use to calculate theta (or phi)....

What happens though is that with the same settings I get differences of almost 3 degrees. The observed relation is that I should get about 4.7 encoder ticks per degree (if only one wheel is turning). In other words, with exactly the same number of encoder ticks the resulting turn is between 360 and 362.8 degrees.

I have repeated the tests with different turning angles. The number of turns doesn't seem to make a difference. If I turn 10 times around I end up with the same variance as I do for a single turn. So the steady state seems to be working OK and the error is solely introduced by starting and stopping.

By placing the robot on the floor, again turning on the laser pointer I can 'wiggle' the robot by ~1 degree before the gearbox engages and I get the first encoder tick (2cm laser pointer travel when the wall is 150cm away). Note that this is 1 degree in total, not 1 degree in each direction.

After sending my email yesterday I spent the rest of the day rebuilt my robot to get the battery pack (currently by far the heaviest piece of the robot) closer to the wheels. Will redo my tests tonight and see if it makes a difference. I also thought of repeating the tests without battery in order to eliminate slippage and inertia as much as possible (although that might help me understand what is going on it will not help the robot).

Any help appreciated, thanks,
Markus


On Mon, 5 Jan 2015 00:11:24 -0600
David Anderson <davida at smu.edu> wrote:

> Hi Markus,
> 
> It would be good to know exactly where the problem lies.   How have
> you determined the rather large variance in calibration runs?  Was
> this done using the UMBMark?   Large left-hand and right-hand squares?
> 
> Is the large variance observed in  the stopping point of a series of 
> similar, say, left-hand runs?   Or is it between the left-hand and 
> right-hand runs?  Those are different problems.
> 
> ~1 degree slop in the gear train is probably manageable, depending on 
> how you are doing the navigation.   If it is a single calculation at
> the start of a run or line segment, then ~1 degree theta error at the
> start will throw the robot way off in X,Y at the end.   If instead
> the odometry navigation is a continuously running calculation as the
> robot travels, then ~1 degree of error becomes less and less
> significant as the robot approaches its target, and basically
> insignificant when the robot is at the target.
> 
> 
> Don't give up on your drive-train yet. :)
> 
> dpa
> 
> 
> 
> 
> 
> On 01/04/2015 02:21 PM, Markus Lampert wrote:
> > Hi,
> >
> > I am adding odometry to one of my robots and found a rather large
> > variance in my calibration runs. As it turns out my gear motor has
> > some backlash resulting in ~1 degree of heading "wiggle room". The
> > quad encoder sits on the motor shaft, not on the wheel itself which
> > means they don't pick up on the backlash at all.
> >
> > I could not find any methods for backlash compensation other than
> > for CNC machines, which doesn't seem to translate to mobile robots.
> >
> > Is there a method to compensate for it or am I in the business of
> > finding a 'better' drive train for my robot?
> >
> > Thanks in advance,
> > Markus
> >
> > _______________________________________________
> > DPRGlist mailing list
> > DPRGlist at dprg.org
> > http://list.dprg.org/mailman/listinfo/dprglist
> 
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at dprg.org
> http://list.dprg.org/mailman/listinfo/dprglist

More information about the DPRG mailing list