pic: Revolution Swerve Demo Robot

d35429500a08da6a631dfd87ebd7f6f6_l.jpg

Our newest demonstration robot.

The bot features our Revolution swerve module, a custom frame and high quality Andymark.biz components throughout.

The unit is powered by two 2.5" CIM motors. Steering is handled by a Globe motor on each end. US Digital MA3 encoders provide steering feedback.

The controls are handled by a custom open source wifi system with Arduino boards on both the robot and operator interface.

I like the update eliminating the inability of the coaxial swerve to rotate.
Do you have multi-speed transmissions now too? It’s hard to tell whats going on inside that frame member where the transmission is buried.
One more question which side is front? I’m trying to tell which way you tied the wheels together, left/right or front/rear.

Maybe thats the point…
The fact that its square allows kind of allows for it to not have a “front” per say.

Very nice swerve! I looked at the module down in Atlanta and it looked great then. A very nice adaptation of 118’s classic style. Very impressed with the look of this one. Good job!

-Brando

The last (IRI) iteration could rotate too; it could skid in place or use “monster truck steering” (there’s got to be a more technical term for that) to turn.

I really like the integrated transmissions; very smart.

I think 4-wheel steering is what many people know it as.

I guess dual Ackermann is another term you may be able to use.

-Brando

Details please!!

Edit: Corrected by Anthony, teach me to go off memory.

Details please!!

There is an Arduino with Ethernet shield on the bot, connected to an Asus Wireless Router. It reads the MA3 encoders as analog inputs and handles PWM signals to the 4 Jaguars.

We plan to do some testing with CAN soon so we can access the closed loop feedback of each Jag. We may get on the bus using serial from the Arduino, or via ethernet with a 2CAN.

The operator side has an Arduino with Ethernet shield connected to a cheapo wireless bridge. We have interfaced a PS2 controller directly to the Arduino. The Arduino conveniently spits out 3.3v for the PS2 controller. We have mapped a few buttons and the analog sticks.

We have a fairly simple comms protocol running that is more or less completely open-source using wifi libraries available online.

This setup does not need an operator interface, as the commands can be sent via wifi directly from a netbook, but the customer wanted a stand-alone solution for this version.

All said the control system is pretty slick and relatively cheap. All the components combined are about $300.

The new Vex system was an attractive option, as was the RCS from Cross The Road, but we liked the simplicity of the Arduino as well as the completely open nature of the wifi connection.

The only issue is that the arduino components are not well-suited for a mobile robot…we have had robustness issues. We are working on a more substantial case for the electronics now.

Do you have multi-speed transmissions now too? It’s hard to tell whats going on inside that frame member where the transmission is buried.

There is a single speed reduction inside the tube, 12t pinion on CIM to a 40t AM gear.

Impressive! How well do the MA3 encoders work? We did a 2-2 swerve drive this past year and ended up using pots for feedback because the encoders we had (idk the model but they were magnetic) were not reliable enough to get the two sets of wheels pointed in the same direction. Clearly that isn’t an issue with all four wheels chained together in this fashion, but I’m wondering if there are any noticeable issues with the angular accuracy with these encoders (I know they claim to be <.5 degrees, but that’s what the ones we had said as well and there wound up being a difference of at least 15 degrees.)

Was this 15 degree difference consistently repeatable?

**

Both sides would be off a bit pretty much all the time. When we tried debugging it in java we saw that the encoders would read equal values at angles that were visibly unequal. At times the wheels would seem fine and at other times they clearly were not our drive train would sometimes look like this (top view where “|” indicates the wheel direction):
| |
| | and other times be like this:

\ |
\ |
and when we switched them with the pots it worked fine. We were just interested in using encoders because pots are notorious for blowing out at the least convenient time possible:ahh: .

So to answer the question…not repeatable.

You said in an earlier post you don’t remember the model number of the encoders you tried. Is there anyone on your team who might remember?

**

How well do the MA3 encoders work?

We have used them for competition and on these dome bots with no issues. We were very pleased with their repeatability.

How do you connect the sensor to your mechanical component? Could you be slipping? That’s what it sounds like to me.

We always use these.

Clearly that isn’t an issue with all four wheels chained together in this fashion

This bot has two wheels at each end linked for steering and two wheels on opposite sides linked for drive.

We have one MA3 encoder on each steering axis…the encoder is linked via helical beam coupling to a 1/4" shaft that is keyed to an idler sprocket.

good luck with than macanum is easyer.

And we all know that because something is “easyer” it is better, right?
You’ve clearly put a lot of thought into the debate between a “macanum” drive and a coaxial swerve – right?

Perhaps you’d like to show us your pro/con list for each? Of course, this list includes only quantitative engineering based arguments, right?

This is an engineering competition. Do some.

-John

I like these little systems. FIRST should take note of their flexibility and performance for the price.

Nice robot