|
[DPRG] Absolute reference for angular position
Subject: [DPRG] Absolute reference for angular position
From: dpa
dpa at io.isem.smu.edu
Date: Thu May 29 13:52:25 CDT 2008
Howdy,
Jeff wrote:
> I turn by knowing how many counts per degree it will take. So I
> immediately assumed that I had to have a calibrated counts per
> degree before I could make this work. Then I finally realized that
> a "square" or any other pattern is based on the same heading that
> is being extracted from the odometry.
Exactly right. And succinctly put.
> Therefore I don't actually need to have the "extra" counts per
> degree that I treated as sacred.
> So during calibration I need to have a routine that has new heading
> as the input. The routine compares current (calculated from the
> odometry) heading to the new requested heading and rotates the
> robot in the correct direction. And in reality I can use the same
> method all of the time, not just during calibration.
Yes, this is close to the "closed loop or 'servoing'" algorithm
posted in the run up to the DPRG ORC here:
<http://geology.heroy.smu.edu/~dpa-www/robo/challenge/navigation.html>
which effectively calculates a new heading (and distance)
and updates the motor control every 50ms.
> I was thinking about this over the weekend as I was driving. It
> occurred to me that I need to slew-rate limit my turns. So if I am
> heading 0 degrees and request 90 degrees, I need to be able to
> control the turn. So I was thinking of just adding to an
> intermediate heading that gets updated each servo cycle. So if the
> turn rate is 5 degrees per servo tick then I just add 5 degrees to
> the intermediate value until it matches the requested value.
One point not covered in the previous post on a "simple" navigation
algorithm is that final motor inputs on all my robots are slew rate
limited. I didn't want to include too many axillary functions in
the description less the main points get lost. But some sort of
rate limiting really helps the response of the physical plant, and
in some implementations, like the two wheel balancing robot, are
required to keep the "driver" from knocking the thing over.
> But it occurred that is getting close to the way my main drive
> motors work with the PID/velocity/trajectory control. So I may just
> make this work like my other motors. But instead of encoder input I
> will have heading input. And instead of creating a PWM for the
> motors it will output a rotation command that feeds into the main
> motor drive.
In the aforementioned simple navigation behavior post, the steering
implementation makes use of a dead-band around zero steering error
to prevent oscillations and overshoot. However, as noted in the
text:
"A better solution for this is to steer the robot with a separate
PID controller, which can then dampen out oscillations around the
set point without giving up precision. But the dead-band technique
works quite well to accomplish a similar result."
The dead-band technique worked well, but the PID steering really
does work better and generally steers more smoothly has more
accuracy.
>
> But to back up, it seems to me that to get good calibration that
> you would have to have the robot do the driving. But maybe I will
> believe differently after trying some experiments. :-)
Ultimately yes.
> BTW, here is an image of my odometry results without a lot of
> calibration:
> http://www.sampson-jeff.com/r3/firstlook.htm
Cool!
Any pictures of the robot?
best,
dpa
More information about the DPRG mailing list
|
