Mecanum or Swerve?

This year we built both drive systems.

During the build season we manufactured a coaxial swerve very similar to our drivetrain in 2009. This took most of the build season, and used up a significant amount of weight. (final robot weight of 120.0lbs) We had many problems with this drive at midwest due to major design flaws that would have been caught with preseason testing.

After Midwest, we took a step back to look at the options we had for 10000 lakes. Turns out, since the withholding allowance was upped to 65 pounds, we built an entirely new robot in 5 days. In those 5 days, we managed to build a fully functioning mecanum robot that had more functionality that out build season robot. We were actually able to get the entire robot built and wired in 3.5 days, with the rest devoted to driver practice and programming. With this 5 day build season we managed to built the most reliable robot our team has ever built.

So, now onto the pro’s and con’s
SWERVE
PRO:
Able to direct 100% of the force into the direction of travel
Not able to be pushed sideways

CON:
Very difficult to design
Multiple points of failure
Requires high quality sensor feedback
Heavy
Time intensive

MECANUM
PRO:
Very simple build
Reliable
Easy to program
Doesn’t require sensors

CON:
Can be pushed easily
Not able to put 100% of force into any direction.

For an offseason project, I would say go ahead and try to build a functional swerve. It will be a great learning opportunity.

For build season though, I would recommend against doing a swerve without fairly successful offseason prototyping.

If you have any questions about either system, or about the specific failures we discovered, go ahead and ask.

EDIT: Woah this post got long quickly

Well, I’ve been doing some research, and from the looks of it, I think what you use is really dependent on what you’re trying to do with the drive. As Jeffy said before, Metal Mustang Robotics are using mecanums this year and they’re working like a boss for us up in offensive. The only (slight) problem is probably just getting “bullied” by other robots. We got some faster sprockets for them and we can normally out-maneuver the defending robot. So far, we don’t have a swerve yet, but it’s definitely an off-season project our build team, or at least the build team captain, is looking in to.

Now I am curious…you said sensors for swerve, but I’m not sure how we would implement said sensors (ie what types and where would we need them)

As far as programming, would you reccomend a joystick devoted to moving the robot in any direction and another axis (x axis on a 2nd stick comes to mind) devoted to rotating the robot around its CoG?

the typical minimum sensors needed for a swerve is at least one form or rotary position sensor to alert you as to the direction of your wheels.

You absolutely need to have a position sensor for each rotating wheel. The sensors are necessary so that your program knows what direction the wheels are pointing. We used these

As for control, it is really up to your driver. Last year our driver wanted to have one 3axis joystick to point the wheels, and another joystick to power the wheels. This year our driver wanted everything on one three axis joystick for the swerve, while for the mecanum he wanted everything on the two joysticks of an Xbox 360 controller.

http://www.societyofrobots.com/robot_taurus2.shtml

Looks pretty cool, but is it really worth it?

Unless you are balanced on those two wheels with no other part of the robot touching the playing surface, it’s a bad idea. Any non-driven wheel or robot component that touches the carpet is robbing you of potential traction.

If a team builds a four-wheel drive robot, but with only two powered wheels, (assuming that weight is distributed evenly across all four wheels) you only have half the traction possible compared to if all four wheels were driven.

There are two goals, and hopefully more than one ball in your zone, so I don’t think that you would be needing to push another robot our of the way.
However, there is one situation that I see you needing to push another robot while in your home zone: If they have hearded all of the balls in the zone into one corner and are guarding them. In which case, the only way to really push them would be into the wall. And it leaves the rest of the zone open to the offensive robot.

I would love to hear why you think what you do. Our team had a large discussion about the need for an omni drive vs. a tank drive at the beggining of the year.

I admit that I have never programmed a mecanum drive, but I dont see it being easy to program. Sure, maybe the basic movements are simple, however I have seen few mechanum drive robots that are controlled effectively. This tells me that either the drivers dont know how to reap the benefits of a mecanum drive, or that the drive code is not up to par.

I programmed an omni drive robot in 08, and by no means was it easy, and it was nowhere near as controllable as I hoped.

I am not a programmer, so this is based off of what I have heard from the rest of my team.

Easy to program is relative to swerve drive programming. But still, programming a successful mecanum drive is fairly simple with a few modifications to the default code.

I’m not so much saying that an offensive robot needs to push other robots, just that a slippery bot is more susceptible to being pushed into a corner or into an unfavorable position. Anyways, I think our ideas of offense are different. We play mostly from the middle zone, and that means competing for the space under the ball return and fighting for individual balls and clear shots. We’re a 10:1 plaction wheel swerve drive, btw.

Easy answer. We knew from our testing and from past experience that a robot defending you was going to try to push you all over the place.

Exactly that happened in the Michigan State Championships to us. Thunderchickens tried to play defense on us. They have traction when they want to, and can push very well. We out-pushed them somewhat and managed to wedge them in the goal for a short time, but they still kept our robot down to scoring only 5 balls.

Their drivers understood that to keep the other guy from scoring, you simply push his back corner so he can’t aim. Or push him into the wall so he can’t turn. Or pull in front of the goal if he can’t push at all, then he’s done.

Mechanum and omni look great as concepts, but when the rubber hits the road all it takes is one good traction bot to completely shut them down.

It’s easy to program “relative” absolute mecanum/holonomic code, as in you push the joystick left and the robot moves to the left relative to the robot. This method does not need any math functions other than elementary operators (like ±*/).

Programming “absolute” mecanum/swerve, as in you push the joystick left and no matter what way the robot is oriented it moves left relative to how the drivers are facing, is more difficult. This latter case involves the use of a gyro to track current robot heading, and a lot of trig functions for each of the wheel outputs.

Control wise, swerve drive is extremely intuitive to me having play a LOT of FPS video games. The past 2 years we have had 2 2-axis joysticks for the driver (2 more for the co-driver), left hand controls all x/y translational movement, right hand controls rotation. Anyone who has played Halo before should be able to drive our robot.

Having done swerve 2 years in a row I might be a little biased, but the programming for a swerve drive seems quite simple to me if you approach position control the right way. We encapsulate a potentiometer and a motor into an object called a “steering motor”, which is completely self contained with all of its own control and PID code; you have a goToAngle(angle) function that you call, and then the steering motor object takes care of everything else. We used 2 steering motor objects for our drive train this year and last, only changing port and PID constants for the most part.

The great advantage about encapsulating a motor and potentiometer for position control is that its usable in many places on robots(turrets, swerve modules, kickers, arms, etc) and the code is completely plug-n-play (aside from tuning PID constants and maybe limiting the possible angles). We used the exact same code to control the angle of our turret and drive train last year, with the desired angle for the PID code coming from the camera(or joystick under manual control) and joystick respectively.

The is the main reason why I made this post is to encourage teams who might be afraid of complicated PID implementations everywhere. If you do it once correctly, you won’t have to do it again. Simplifying a few things slightly, you can always change the steering motor object around a little bit, and abstract out its desired angle so you can give it desired encoder ticks instead and use a driving motor instead of turning, and now you have PID distance control.

Mecanum drives are overrated, heavily. Often, people decide that they need the ability to strafe, or they decide “maneuverability” is important, so they jump to the conclusion that they should build a mecanum drive. Mecanum drive is a very specific tradeoff. You exchange drive efficiency, resistance to defense, and a bit of speed for strafing.

After our experience this year, I fully agree - our mechanums were not that reliable (the 6" andymarks weren’t strong enough to get bashed sideways against the ramp repeatedly), we didn’t strafe that often, and we were easy to push around.

Also, we had 1114/2056’s 8WD tank drives at both our regionals demonstrating that maneuverability is more about a well-controlled high speed drivetrain and less about how many directions you can move.

Maybe our is too over-the-top but we use a few trig functions and things as well in our algorithm. In 08 on the old control system we even had to develop our own angular unit (b-rads!) and define trig lookup tables to provide a semblance of efficiency :slight_smile:

It’s all how you look at it, I think. I was the student developing our first ever algorithm in 07 that split the joystick area into 16 “control zones” with hardcoded values that just got scaled based on how hard the joystick was pushed. Our current algorithm is completely dynamic based on the positions of our translation and rotation sticks.

1675 has used mecanum in 07, 08, and now this year. We are happy with our home-brewed algorithm except for the fact that we never quite get the chance to slap encoders on. (And yes, our drivers do strafe :slight_smile: )

I would like to try a dropped 6-wheel one year though…

TANK DRIVE MECANUM SEPARATION OF VARIABLES
http://www.chiefdelphi.com/forums/showpost.php?p=939894&postcount=1

3-AXIS JOYSTICK MECANUM ALGORITHM
http://www.chiefdelphi.com/forums/showthread.php?p=916383#post916383

~

More difficult, but not all that much so for a mecanum/holonomic. 2077’s field-relative stick code looks like:

double x = stick3.getX();
double y = stick3.getY();
double angle = (gyro_.getAngle()+180)/180.*Math.PI;
stick3.setX(x * Math.cos(angle) - y * Math.sin(angle));
stick3.setY(x * Math.sin(angle) + y * Math.cos(angle));
driveTrain_.drive(stick3, stick2.getX());

It’s interesting to listen to the emerging consensus (with which I don’t disagree) that a swerve drive wins virtually all the pure physics comparisons, but comes off worst or near-worst in:

  • Hardware Complexity
  • Weight
  • Cost
  • Reliability
  • Development Time
  • Software Complexity

In other words, practically every engineering factor other than pure physics. Don’t forget making a robot is engineering, of which theoretical physics is a part, but only a part.

Well, if you make a simple numeric list of upsides and downsides, swerve will look bad. I think it’s unanimous that the “physics” advantages are HUGE, not just theoretical. All of those other difficulties can be worked through, but it’s rather difficult to “work through” mecanum’s on field tradeoffs versus a swerve’s.

I thought a bit more on this Subject last night, and came to the realization that Swerve Drives are going to become more and more common in FRC. One of the biggest issues with Swerve Drives is that they’re difficult to design and manufacture, and many teams could spend a whole build season doing this and not get it right. But, now that two types of swerve module are available as COTS items these two issues are almost non-existent, or no more so prevalent than in a Mecanum or Holonomic Drive.

If a team were to use the Commercially Available Team 221 Swerve Modules, then they’d really only have to build a frame in which to house them, and a system to steer them. From there, it’s pretty much just a control issue, and I bet most teams could figure out how to get them working relatively easily. We’ve already seen a handful of teams use the Team 221 “Wildswerve” modules with some degree of success (11, 20, 234) and I’ve yet to hear of any failures.

The only downfall to using an off the shelf Swerve Solution like the Team 221 Modules is cost. A set of 4 Swerve Modules will set you back about $1k, whereas a set of Mecanum Wheels and 4 Transmissions should run you in the ball park of $700 or so. IMO, the cost premium is worth it, especially if you’re a team that plans on using an Omni-Directional Drive to it’s fullest potential.

Strangely enough, all of this thinking is leading me towards possibly pursuing a swerve drive for the 2011 season, should the game call for it, and I was always one of those “Why not just use a skid steer” kind of guys.

In conclusion, building a reliable and effective swerve drive, seems to be getting easier by the year.
(Sorry for the long post, I had a lot of thoughts to get out.)