Most Graceful Mecanum Robots?

We’re building a mecanum drive train robot this year. I’m curious what the best examples of skilled mecanum driving in the past are, and how those robots have mapped xbox controller inputs into robot outputs.

What are some of the most graceful examples of mecanum robot driving in the past? I’m looking in particular for videos that highlight mecanum robots where the driver and the robot seem to be of one mind, demonstrating really great control of the robot.


1519 was dominant with mecanum wheels in New England for Recycle Rush.

Here’s a video from the NEDCMP:

Here is a thread where they posted their code - take a close look at the subsystem called Drive.

One of the best Mecanum drivers I have ever seen was from 2052 back in 2013. Check out any matches for 2052 on TBA in 2013.

It also helped that the robot was well designed for that game.

Now, I may have a slight bias here, but team 2053 has used mechanum in almost every game, last year even combining mechanum and tank drive.

Sent from my SAMSUNG-SM-J320A using Tapatalk


And here is a video

As far as controls, I’ve seen three main schools of thought:
1-joystick: front, back, left, right for translations, twist for turning
2-joystick: A front, back, left, right translations B turn (side-side)
2-joystick: A front, back, CW, CCW B left, right translations

We’ve found that if you are using an Xbox 360 like controller, then it’s easiest to do.

Left joystick: forward backwards, left, right

Right joystick: rotate CW and CCW.

We also use field oriented drive and have buttons on the driver’s controller to rotate to different angles.

You can find the rotate to angle code in the Tigerdrive folder and the actual drive command in /Commands/Drive

The standardized way to do mecanum drive comes from remote control aircraft, particularly helicopters. 2 sticks: A_y is y movement, A_x is x movement, and B_x is rotation. This leaves B_y open for a “throttle” typically, in this case a climber would make the most sense.

Also, if you square your inputs while maintaining the sign of the initial value, your driving becomes much more graceful. Cubing your inputs is often too much.

Typically, in mecanum years, I train my team’s drivers to:
1: Rotate around a point while facing it, this is a very common task in-game when aligning the robot to anything.
2: Travel in a straight line while rotating half speed. Requires very good orientation.

That way, you never need to use field-oriented drive, and you never need to worry about gyro drift killing your endgame.

If you are going to do mecanum, please try and program it Field-Centric as you will get the greatest benefit from it that way.

I don’t want to see another team make a tank drive with expensive fancy wheels. make strong use of them every time you move on the field.

Field-centric and a quality gyro do wonders to make a mecanum drive feel intuitive and accurate. It’s just much harder if not impossible to get that kind of fluid driving + strafing with robot centric controls - that’s when you get into “crappy tank drive” style driving.

Other than that, Halo controls - lateral movement on the left stick and rotation either on the right stick or on the shoulder buttons if you’re feeling adventurous.

Check out 2052 from MN; their 2013 robot in particular had an excellent mecanum drive. I believe they were field centric and used these sort of controls. 2791’s 2015 robot was a dream to drive with these controls, but it was pretty bad at everything else it did that year, so I don’t have great video of it being dominant or anything.

Here is a control scheme for omnidirectional robots that I developed earlier that, in my opinion, gives the driver the most useful control over the robot’s position and orientation:

I’d be happy to answer any questions about it.

I train my drivers to use mecanum effectively without field orientation. Running mecanum wheels like tank drive uses far less current, depending on the wheels.

In 2015 when I was mentoring team 4561 in Durham NC, we used two joysticks and field relative drive (could switch to robot relative if desired).

As with many such designs, one stick was for movement. We would move, relative to the field, in the direction the stick was pushed and at a speed relative to the deflection of the stick.

While we used the second stick for rotation, I think we did it a bit differently than most. We would use PID control to rotate the robot to the field relative direction that the stick was pushed. It was not just rotate CW or CCW. It would rotate CW or CCW depending on which way was the smaller angle (always less than or equal to 180 degrees) to the desired field relative angle.

This made it easy to move toward a location on the field and by the time you were there, be pointing in the direction you wanted. For example, to move somewhere straight up the field and be pointing to the right, push the movement stick forward and the rotation stick straight right.

I would not say we quite got it perfect, for example the drivers tended to have to push the rotation stick to an angle a bit past where they wanted the rotation to stop, but it was pretty slick.


BLUF (bottom line up front): For mecanum drive, it’s real easy to code up field-centric drive as an option after getting robot-centric drive to work, and then use the one that works best for the combination of your driver, your robot, and your anticipated gameplay.

Thanks for the kudos. The 2015 game, Recycle Rush, with no defense, was a great opportunity for teams to explore mecanum drive. We thought our mecanum drivetrain worked very well for our 2015 game strategy.

It’s practically trivial to have field-centric controls on a mecanum drive robot. After determining the commanded direction vector from the operator’s controls (that’s the hard part, which has to be done already), one simply rotates the vector by the robot’s current field-centric heading (the gyro value). For the actual code, see our mecanum code from 2015, as linked above.

In 2015 with our mecanum drive, we had an OI button that could switch between the sets of controls to allow drivers to experiment with either.

The above pair of comments are important to consider together. The first one faults mecanum drivers for not making sufficient use of mecanum capabilities. That’s a readily-apparent common issue, especially for drivers that are accustomed to driving a tank-drive robot.

However, the second post is just as important, and it’s not just about saving current – it’s about the **speed **of getting from point A to point B! flemdogmillion’s point is particularly important to remember for drivers for whom the mecanum robot is the first one they’ve driven (and thus doesn’t have to unlearn “tank drive habits”) - there are times that it is better to drive the mecanum robot like a tank drive robot!

In particular, mecanum robots strafe much slower than they drive forwards and backwards.

What the speed difference means to the driver is that if the robot is currently pointed perpendicular to the field, and wants to move nearly all the way down the field, the fastest way to get to the other end of the field is not to just strafe 40 feet sideways (which would make “strong use” of the mecanum capability). The critic from the stands, seeing the mecanum bot driven like “a tank drive with expensive wheels” in this circumstance in order to get downfield as quickly as possible, might think the driver was wasting their mecanum capability, without realizing that the driver just executed the fastest maneuver possible for their drivetrain.

For short sideways movements, mecanum strafing is clearly much faster and a big win for mecanum. For long-distance field traversal, driving straight forwards is the fastest way to get there, whether the robot is mecanum or tank.

The crossover point will vary from situation to situation. We found in 2015 that for our mecanum robot that year, there were definitely parts of our routine for which it was faster to get our mecanum robot from point A to point B by “driving like a tank” instead of making “strong use of the [mecanum wheels] every time we move.” There were also short strafing movements that were a key part of our approach to harvesting the landfill and fundamental to our robot design.

But, what does this have to do with field-centric drive? Well, the use of field-centric drive insulates the driver from some of the awareness of whether the robot is strafing and/or going forwards or backwards, making it difficult to drive the mecanum robot in such a way that takes advantage of the strafing capabilities when it matters, yet minimizes the disadvantage of the slow strafing speed when traveling long distances.

For what it’s worth, in the 2015 game with our robot, our drivers found that field-centric drive enabled a novice driver to become a reasonable driver pretty quickly and easily. However, to get to the level of “excellent driver”, the robot-centric drive mechanism was better. Having the field-centric drive abstract away the knowledge of whether the robot needed to move sideways or forwards (but just know that it needed to move laterally across the field) enabled the driver to progress to a reasonable level very quickly, but that knowledge needed to be taken into consideration by the driver in order to decide when to “drive like a mecanum” and when to “drive like a tank.” Using robot-centric drive all the time built that awareness & skill in the driver more easily than that same awareness and skill was developed with field-centric drive, at least in our limited usage.

Your mileage may vary and a lot of the determination of robot-centric vs. field-centric is related to driver preference and prior learned styles.

Bottom line: for mecanum drive, it’s real easy to code up field-centric drive as an option after getting robot-centric drive to work, and then use the one that works best for the combination of your driver, your robot, and your anticipated gameplay.

You can also train your drivers to operate a field centric controls in the “tank drive direction” when going on long sprints. It’s just a matter of remembering to turn and pointing in the right direction.

For a game like this one, I like having the option to switch between the two mid-match - dip into field centric for fine adjustments and robot centric for long sprints. But this of course requires even more training to be good.

What is the “Moon Maneuver”???

We are doing omni this year and are considering adding a button for a pre-programmed evasive maneuver. Is this one of those?

We used a flight simulator type of joystick for our recycle rush Mecanum Drive. This enables you to control both direction, and rotation (via twist) simultaneously and intuitively. You could use this method for either field centric or robot centric control.

Logitech 963290-0403 is a very reasonably priced PC USB option.

Or have one driver trained with field centric and one trained with robot centric and switch control between the two as needed.

A moon maneuver is a move in which you “orbit” around a fixed point, often an opposing robot, while facing that point at all times, much like the moon orbiting the Earth.

I’m not sure if you’re joking, but this is a completely ridiculous idea. This is almost guaranteed to give you worse performance than giving the same driver double the stick time, and the speed lost in switching drivers mid-match completely negates the relatively minor speed advantage of switching between the styles of drive. Don’t do this.