[Dprglist] Odometry on Mecanum-wheeled robots?
Doug Paradis
paradug at gmail.com
Tue Apr 14 09:21:15 PDT 2020
Patrick,
Really cool!
Regards,
Doug P.
On Tue, Apr 14, 2020 at 11:07 AM Patrick R. Michaud via DPRGlist <
dprglist at lists.dprg.org> wrote:
> 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
>
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at lists.dprg.org
> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20200414/e5de191d/attachment-0001.html>
More information about the DPRGlist
mailing list