[Dprglist] DPRGlist Digest, Vol 43, Issue 8

steve . steve at txtulip.com
Tue Apr 14 17:37:18 PDT 2020 

  Re: Odometry on Mecanum-wheeled robots My Experiences (Steve Alaniz)
Doug,
        I  would love to know if you have tried the computer mouse method of navigation. I worked with FRC team 1884 back in 2007 and tried to do exactly what you described. I first tried an optical mouse but after a few feet in a simple out and back test I got unacceptable errors. I decided it was lost counts from the optics either not seeing the correct pattern or that they did not detect movement because the surface material. So I tried an old mechanical ball mouse. Same problem happened. I think errors in a computer mouse are not seen because humans don't care about the count, they care about the position and use their own vision and correct for any errors without ever knowing they occurred. 
   In the end I settled on attaching encoders on two 6" omni wheels that would be positioned at 90 degrees to each other; one for the X direction and one for the Y. (I believe this is exactly what Pm used with his FTC robot team.) The wheels needed to be spring loaded to ensure reliable contact with the ground. I only got as far as testing forwards and backwards and had really good results with that. However, that project was shelved because of the fear that Mecanums can't push well in a competition; A very common myth I have since determined to be a co-efficient issue.
   As you may remember, I still have my base Mecanum platform and I had decided to restart my projects, that's when the tornado hit.... and now this virus thing. Anyway, at some point I will be adding real navigation, at least, that's the plan.
Steve

    On Tuesday, April 14, 2020, 3:45:53 PM CDT, dprglist-request at lists.dprg.org <dprglist-request at lists.dprg.org> wrote:  
 
 Send DPRGlist mailing list submissions to
    dprglist at lists.dprg.org

To subscribe or unsubscribe via the World Wide Web, visit
    http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
or, via email, send a message with subject or body 'help' to
    dprglist-request at lists.dprg.org

You can reach the person managing the list at
    dprglist-owner at lists.dprg.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of DPRGlist digest..."


Today's Topics:

  1. Re: Odometry on Mecanum-wheeled robots? (Doug Paradis)


----------------------------------------------------------------------

Message: 1
Date: Tue, 14 Apr 2020 11:41:50 -0500
From: Doug Paradis <paradug at gmail.com>
To: "Patrick R. Michaud" <pmichaud at pobox.com>
Cc: Carl Ott <carl.ott.jr at gmail.com>, DPRG <dprglist at lists.dprg.org>
Subject: Re: [Dprglist] Odometry on Mecanum-wheeled robots?
Message-ID:
    <CAOdUW+ZPZ7YOhkTo26OnnwL4nei7_K8KCBBhKRG95oBZE8km6Q at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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-0001.html>

------------------------------

Subject: Digest Footer

_______________________________________________
DPRGlist mailing list
DPRGlist at lists.dprg.org
http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org


------------------------------

End of DPRGlist Digest, Vol 43, Issue 8
***************************************
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20200415/4181ce09/attachment-0001.html>

More information about the DPRGlist mailing list