[Dprglist] Odometry on Mecanum-wheeled robots?

Doug Paradis paradug at gmail.com
Tue Apr 14 09:41:50 PDT 2020 

Murray,
     Another approach of using an external sensor to get position is
optical flow. When used with small hobby robots, the robot usually uses one
or more re-purposed optical mouse camera/DSP chips. These are getting
harder to source as, newer mouse incorporate the USB bus functions into the
same chip. Older optical mice had a separate chip which contained the
camera and DSP and another chip that did the USB. You could tap into the
serial output of the DSP. A web search will uncover chips that you can
use.
Regards,
Doug P.

On Tue, Apr 14, 2020 at 11:21 AM Doug Paradis <paradug at gmail.com> wrote:

> 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/7158e2f5/attachment.html>

More information about the DPRGlist mailing list