Circling around a point on grass with Mecanum

Technical Control System
1

This might be a stretch, but I’m interested in getting our 2011 robot with AM Mecanum wheels to do the following, either autonomously or with reasonable driver control:

The robot needs to travel in a circle (10 revolutions) while always ‘facing’ the center of the circle. The center of the circle will be directly below our modified tube grabber. We have an elevator design, so our grabber point (and hence circle center) is roughly the center of a game piece which is touching the bumper.

Oh, did I mention this needs to be done on a baseball diamond grass? And be executed quickly (competing against humans doing the same thing nearby)

The idea is to compete in the ‘dizzy bat spin’ between innings at the local summer baseball league games. Players (all human so far!) stand a bat up in front of them, put their forehead on the bat, and spin around the bat 10 times, and then try to run to 3rd base (starting at the on deck circle)

We’d do this with the robot on the first base side to avoid any collision safety issues-- we don’t need dizzy people running into the robot…

So, we have a gyro already installed, and have field oriented drive (or bot oriented) but I’m wondering if anyone has ideas on how to make this work well. We haven’t tested anything yet… just collecting ideas right now.

An easy way would be to actually slightly ‘pick up’ the bat, and not worry about drifting while circling, but it would be much better if we could keep the center point fixed.

I’m thinking custom programming that makes the robot travel in the circle, with gyro+joystick that simply translates the center point, so the driver can compensate for drift only, using a baseball-field oriented system.

Should be a simple matter of having the circle movement be ‘automatic’ but adjusted with a drift compensation vector coming from the joystick.

Or is there a better way?

Thoughts?

2

one issue you may run into is that mecanums have issues on non flat/hard surfaces as they will not have balanced vectors. That being said it is certainly possible, however I don’t know if a gyro will be able to do it itself. you may want to consider incorporating a compass too as the shaking that will occur may cause an inordinate amount of drift.

Another alternative is to create a spine, this tend to help quite a bit with mecs, and wpi has always integrated spines into their mec drives.

it is certainly possible, but you will find that strafing on grass creates some interesting issues.

Good luck!

3

That was my first thought too, that those wheels on infield grass will prove challenging. As will picking the bits of grass from the wheels. It will perform FAR better if you can get to do it on infield dirt.

I think the hardest problem is detecting drift from center. Once you set the 4 wheel speeds such that the robot moves as desired, you can just leave it exactly like that for the 10 revolutions. But the imperfect surface will cause drift - grass quite a bit, dirt not so much - and detecting (and correcting for) that is a huge challenge.

Perhaps an unpowered omni wheel mounted parallel to ‘normal forward’ at the back of the bot. If the bot moves exactly circularly, the small wheels on the omni will turn, but the big wheel won’t rotate. When the bot moves towards or away from center, the big wheel will move, and you can detect and compensate for that. (Like the sensor wheels some teams used in Lunacy)

4

*In theory, the open-loop robot commands to do this are simple, but I wonder if it would execute acceptably over 10 revolutions even on a “perfect” surface.

So, you might try whipping out some quick code and trying it on some nice flat carpet and see what happens.

The open-loop commands for the vehicle motion you described (revolve around a fixed point with the robot always facing the point) are very simple kinematically with a mecanum vehicle. Just use a fixed robot-centric “strafe right” (or strafe left) command to establish the desired tangential velocity, and use a fixed rotate counter-clockwise (or clockwise) command to establish the radius of revolution.

Using sensors to provide feedback for closed-loop control could get very interesting. Even if you had a perfect gyro and a perfect fore/aft translation sensor, the robot could drift because the strafe behavior is still open-loop.

See the attached sketch.

The robot starts at Point A facing Point C (the center of the green circle), and the intent is to follow the green circle clockwise while always facing Point C.

This is exaggerated for illustration purposes, but it is possible for the robot to follow the red path instead of the green path, even if the robot rotation rate is perfectly controlled at the desired rate, and the fore-aft motion is perfectly zero.

This will occur if the actual strafe rate is slower than the open-loop strafe command.

**

revolve around fixed point.png


revolve around fixed point.png

5

Thanks for all the input…

Now I’m thinking maybe we should put the bat holder off to the left or right side of the bot and then the bot can drive forward (with a turn radius) rather than strafing… Strafing would look neater since the humans contestants are all ‘strafing’ as well. We could even replace the mecs with regular wheels and just tank drive in a circle.

If we proceed with this, I’ll probably try to start on the infield dirt between 1st and 2nd and avoid the grass or something similar. The problem with that is this is all happening while the home team is ‘warming up’ in the field, so using the dirt would disrupt that… but maybe for a one time shot they’d give up the real estate.

6