[Dprglist] Odometry on Mecanum-wheeled robots?
Patrick R. Michaud
pmichaud at pobox.com
Tue Apr 14 09:07:44 PDT 2020
Hello Murray and Carl,
This may not be directly relevant to the original query, but this season my FTC 7172 team did odometry on their competition robot with mecanum wheels. In addition to using encoders on the wheels themselves (for motion profiling similar to what Carl is doing), they also have a separate set of "tracking" omni-wheels which are passive and serve only to keep track of robot position and orientation.
This ended up working extremely well -- in at least one match, the robot ended up in a spot other than the one it was programmed to be in, but was able to self-correct to avoid obstacles and continue scoring points. You can really see it about 11 seconds into this video: https://photos.app.goo.gl/vuDCL7kFBaw8j6Gz8
At t=11, the 7172 robot is grabbing the red platform and attempting to turn it 90 degrees. But the platform gets caught on the field wall, and it's unable to complete the turn/motion. When the robot lets go of the platform (t=14) the robot is completely in the wrong orientation/position -- it's supposed to be directly facing the camera, and about a foot to the right of where it ended up. But with the tracking odometry the robot self-corrects and is able to correctly navigate under the bars and back to pick up the remaining blocks.
Here's a video of a complete (and higher-scoring) match from the regional championship: https://drive.google.com/file/d/1RY8RPWrEfyWJZ2GvFSIuuGkY4KMUXLAS/view?usp=sharing
I'll be happy to forward any questions to the team if anyone is curious about other items.
Pm
On Tue, Apr 14, 2020 at 09:16:47AM -0500, Carl Ott via DPRGlist wrote:
> Hi Murray,
>
> Yes that video you saw was mine.
>
> 'HoverSim' has odometers on all 4 mecanum wheels.
>
> Currently, I only use a velocity loop for speed control. So far, I make no
> attempt to close any loop around position.
> Hence, the video you saw was simply time and speed.
>
> My next step for HoverSim will be to calibrate encoder ticks to distance
> traveled for
> - forward
> - sideways
> - 45 degree diagonal
> - rotate in place
>
> and to try that on different surfaces. Empirical observation hints that
> distance traveled might vary by surface.
> Also, I suspect that floor flatness could have a significant impact. You'll
> recall my video was on a tiled floor, which is anything but 'ultra-flat'.
> HoverSim has a flat aluminum plate as base. And we've found spots in the
> Dallas Makerspace Interactive Classroom where two wheels do not have enough
> grab to overcome the third and fourth when they're adding drag.
> To overcome that, I've seen at least one suspension design which has the
> front wheels and rear wheels on separate beams, connected by a
> front-to-back pivot, to ensure that all 4 wheels touch on uneven surfaces.
>
> At quick glance, the motors on HoverSim themselves seem well matched and
> pretty repeatable. They accumulate pretty similar values after running one
> of those timed velocity loop patterns...
>
> It seems that repeatability varies the most for 45 degree diagonal. That
> may not be surprising, considering that in such case, only two wheels are
> active and the other two just drag...
> In contrast, forward and sideways travel seems to have remarkable
> consistency - those seem to return to start pretty well, even with timed
> velocity loops, even on an uneven tiled surface.
> Amusingly, we also discovered what happens when a wheel falls off. Yes -
> that was an unexpected experiment. Remarkably, the robot still responded to
> controls quite well -it was almost as if the 4th wheel didn't matter. I'm
> still trying to wrap my brain around that one - but...
>
> The fun will really start after calibrating encoder ticks to distance, to
> see how well simple encoders can work.
> However, no matter how good simple encoders work, I fully expect to get a
> pair or triplet of optical flow sensors, and dabble with pointing at floor
> or ceiling...
> And then there's another even more fun branch to explore - adding an
> adapter layer that makes control response mimic hovercraft motion ;-)
>
> - Carl
>
>
>
>
> On Tue, Apr 14, 2020 at 3:42 AM Murray Altheim via DPRGlist <
> dprglist at lists.dprg.org> wrote:
>
> > Hi everyone,
> >
> > I've just been corresponding with Gareth over at 4Tronix and discussing
> > the firmware changes necessary to run a second Picon Zero motor controller,
> > which is not trivial but doable. Not that I need another project (!) but
> > I've been thinking about adding a second pair of motors and a controller
> > to my tiny KRZ01 robot and using Pimoroni's tiny Mecanum wheels that fit
> > onto the micro gear motors. It'd certainly be one of the smaller four-
> > wheeled Mecanum robots.
> >
> > The big question is: does anyone bother to do odometry on a Mecanum-wheeled
> > robot? There's so much slippage it seems I could get away with not using
> > encoders on the motors, which would simplify at least one part of the
> > programming. I did remember seeing the video somebody in the group showed
> > recently where his robot was navigating the kitchen floor (Carl or Doug?)
> > and coming back to the same location after a complicated maneuver. Which
> > I *think* requires odometry...
> >
> > Any advice welcome.
> >
> > Cheers,
> >
> > Murray
> >
> > ...........................................................................
> > Murray Altheim <murray18 at altheim dot com> = = ===
> > http://www.altheim.com/murray/ ===
> > ===
> > = =
> > ===
> > In the evening
> > The rice leaves in the garden
> > Rustle in the autumn wind
> > That blows through my reed hut.
> > -- Minamoto no Tsunenobu
> >
> > _______________________________________________
> > DPRGlist mailing list
> > DPRGlist at lists.dprg.org
> > http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
> >
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at lists.dprg.org
> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
More information about the DPRGlist
mailing list