Team 4206 Pre-Season Drive Module (In Progress)

This is Team 4206’s preseason drive module (or at least part of it). The rest of the model is a little messy right now. Any comments, thoughts or suggestions would be much appreciated… The large arms on the side will be actuated by a pneumatic piston

Just wondering where exactly the module is attached to the robot; on the mechanum wheel, or the traction wheel? If I were designing it, i’d put the traction wheel being attached to the robot, so it’s more solid when playing the pushing game. (however, I’ve never made one of these, so this is just an opinion)

Otherwise, it looks quite nice, and more importantly: simple. It would be cool to see this in action!

You would really want the pivot on the mecanum wheel because the mecanum wheel is always applying force to the side. This is the reason you use thrust bearings with mecanum wheels. You should also look at the strength of your module, even though the design looks cool, you should really make it stronger.

Deep groove ball bearings, well lubticated, should also be able handle the thrust loads that a 120 pound robot can generate.

Our FRC team (3135 Robotic Colonels) will likely be doing a mechanum drive year.
Our team also does the FTC program (3507 Robotheosis), and we recently qualified for the Illinois state competition, winning tour first regional as the 1st seed team and alliance captains using the mechanum drive scheme pictures below.
In our 2nd regional we won the Rockwell Innovation award.
Note how the slotted framing allows for fine tuning the robot’s wheel base length and quick/easy chain tightening. Wheels & axles free spin in the double nested channel sleeve bearing blocks. The hardened 10-32 socket head bolts with polished unthreaded zones engaging the sleeve bearings, make SOOOOO much better axles than the Tetrix bendy D-shafts.](](](

-Dick Ledford

-Dick Ledford

You’re saying I need some of these on here, and to switch from pivoting on the mecanum wheel, to pivoting on the traction wheels I choose? Or would I be able to just use ball bearings as the person above said

And how should I strengthen it? Should I make the actuators thicker? I realize I need a support between the two wheels, and I have yet to the shaft size on the traction wheel to 1/2", but how would you recommend strengthening it?

And also, I never mentioned that this will be encompassed in a module, so it will have a casing around it so that the CIM and pneumatic cylinder can be mounted on it, and the module would then be mounted with springs so as to make the mecanums sit level.

The traction wheels are also not meant for “constant use” I have them geared down to 5 fps, so that they are for pushing, whereas I can have the mecanums at 15 fps for cruising

I got the idea for using a thrust bearing from the 4th page of this thread

In terms of strength I was referring to the support between the two wheels.

Also, one thing to remember is that you will want to build and test this before the season starts if you want to use it this season. You do not want to try to do an untested drive during the season. Trust me, my team did that this year and we did not have the best time, but after the season we tweaked it and it works great.


The drive is the most important thing on the robot. If it does not work, you have a bad day at your event. We spent all season, including champs, fighting that drive train. We finally figured it out in July and it is wicked. But, it took 7 months of working to get it right.

We have materials ordered for 6 modules, and were planning on making a right and left for now (machining side, as the rest of the materials are VEX/AM) so that everything works okay and that we can either be confident or do a tank. Would this be acceptable, or do we need to build the full thing in person?

And also, our team has run mecanum and traction wheels both, so concepts and necessary items we have plans for (gyros, encoders, etc)

I wouldn’t run a new drivetrain in season I haven’t designed, iterated, built, tested, iterated more, and practiced with a ton in the offseason. It’s too risky, and the drivetrain is never something you want to make too complex. 99.99999999999% of FRC games give no advantage to omnidirectional movement over a simple and reliable tank drive.

The first part I agree with. The last sentence is entirely up for debate at another place and time :slight_smile:

I’d modify the above statement to something more like “I wouldn’t try a new/unusual drivetrain type (octanum, mecanums, swerve, WCD) unless you’d iterated it before the build season.” The drivetrain is very important to have high reliability - and quite honestly - omni-directional ability is more often wasted or used less efficiently than it is used excellently. So, unless you’re making the drivetrain 70% of your focus and will have a first iteration done Week 3 so you can test it and re-iterate it during the build season, don’t use this octanum for next year’s game. (and, as a side-note, I can almost guarantee now that the game won’t be one for which the drivetrain should consume 70% of your effort… I don’t think there ever has been such a game).

Regardless, I want to make some comments directly on your design…

I’ve never built an octanum, but I have to say they are one of the coolest drivetrains out there. They’re heavy, but they’re a very cool drive style that really brings the best of omnis and traction wheels together. I would think that they have an advantage of having less devestating failure modes than a swerve… basically, they would be more likely to only limit your capability in a match rather than leave you dead-in-the-water.

Your module is very slick-looking, but I am concerned about it’s ability to parallelogram/rack… (i.e. the plates remain parallel to each other, but translate with respect to each other). Adding some standoffs that hold it together is the easiest way to help this.

I’m not familiar with mecanum gear ratios, but designing for a free surface speed of 15fps is probably good… I know mecanums have a surface speed loss due to the competing velocity vectors that are derived from their geometry. Your effective speed would probably be around 10-11fps after efficiency losses and “mecanum losses,” which I’m guessing is a good speed for mecanums, but others should chime in on that…

I’d recommend using less of a reduction from your mecanum to your traction wheel… I’d probably gear for 6-7 fps on your traction wheel so you have a bit more speed but should still be traction-limited. If you want to know more about gearing drivetrains to be traction-limited, optimize distances traveled, etc. there are many great threads already around…

I don’t know how your piston will mount to actuate, but if you’re putting it somewhere in the middle (which seems likely to help minimize bending forces) it looks like it’d be interfering with the mecanum.

Looks good, but I would strongly recommend using something simpler this next year! It’s always hard to not go with the flashier system, but in both short- and long-term sticking to a more reliable drivetrain next season that gives you 80-95% of the performance is the right choice*.

I would actually say that unless you have a very highly practiced drive team with your omni-directional system, the tank drive will give you better on-field performance.

2008, I’d argue that any team that just focused on the drivetrain could have been quite successful. See 148 and the “Roadrunner” configurable robot.

And yes, even if it meant a non standard drivetrain. Roadrunner was Ackerman steering, and Tumbleweed was swerve.

Funny you should mention that… :slight_smile: 1519 also built a successful lap-bot, Speed Racer… pretty much 100% drivetrain! It weighed about 40 pounds, was powered by two CIMs, had ackermann steering and could do 8 or 9 lines in auto. It would’ve been successful if our team had the foresight to use it instead of our hurdling robot (which also did pretty well)… regardless it had a successful off-season.

I’ll dig up some video and links of it…

At any rate, I do agree that 2008 was a game in which some successful robot strategies would be more than 70% drivetrain.

Couple things I can think of while looking at the design. Our team has done a jump drive/octo drive the past 2 years. Last year was all 4 corners had traction that actuated. And in 2012 we had a mechanum system with a 3rd set of wheels in the center with traction to actuate up and down for the bridge.

-We have found that the mech should be the natural position, then actuate the traction down from. In a sense the mech. is static and then the traction moves up and down.

  • We used the same axel that the mech. rotated on to also rotate our traction wheel around.

-In between the two side plates I would recommend some kind of bracing or reinforcement. In a side collision I could see this flexing quite a bit.

-Be very careful with your Vex mech. wheels. For ultimate ascent they were fine through 3 rigorous events but they didn’t last too long after that. Spares are a must.

-Our team prefers hex shaft over keyed. This is for 2 reasons, cant loose a hex as opposed to the key stock in the shaft. And hex has better engagement and less slop from what we have experienced. Downside to hex is the bearings can be touchy on tolerances, quality, and availability

But like all things in FIRST, there is no right way to do one thing and you can always improve on your design. So far you have a solid base it seems, and with some tweaking you should have a real nice system. I will try to snag some pictures of the systems if I have a chance to give you a better idea.

Hi jbsmithtx,

We’re working on a similar design using VEX 4" Mecanums. We built a prototype to test performance of wheels, motor controller, and gearmotor/encoder combination. We used the Matrix system for cost and availability reasons; the Matrix gearmotor has the encoder built in and the Matrix controller handles up to 4 motors. We really like the VEX Mecanum wheels; they roll smoothly and the price is very reasonable.

Our competition design is currently:

For the testing prototype we built:

We want to fold the motor tighter to the side using a miter gearbox; at least on the front. This will provide more room for the collection mechanism.

Things we like about the prototype:

  • Motor controller built in PID speed control worked well (RobotC code)
  • Teleop control is very nice for omni-directional control
  • Speed vs. power is good (quantitative date to come)
  • Fabrication was fairly straight forward (see cons)
  • Square shaft for wheel eliminates hub


  • Couldn’t get encoder position control to work with the built in Matrix RobotC code
  • Square shaft VEX to 4mm motor shaft coupling was tricky. We had to learn how to broach a square hole and weld 2 pieces of the coupler together.

Can you provide some more detail on why you found this to be the better configuration?