Mecanum or Swerve?

[artdutra04]

Originally Posted by Laaba 80

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.

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.

[kwojcik]

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.

[Bongle]

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.

[BigJ]

Originally Posted by artdutra04

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 +-*/).

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

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 )

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

[Ether]

Originally Posted by artdutra04

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 +-*/).

TANK DRIVE MECANUM SEPARATION OF VARIABLES
http://www.chiefdelphi.com/forums/sh...94&postcount=1

3-AXIS JOYSTICK MECANUM ALGORITHM
http://www.chiefdelphi.com/forums/sh...383#post916383



~

[buchanan]

Originally Posted by artdutra04

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.

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.

[Chris is me]

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.

[thefro526]

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.)

[Chris is me]

Originally Posted by thefro526

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.

Both 11 and 20, despite building practice robots, had code glitches at their first regionals, and didn't really get their swerve drive code up to par until their second event. These are two teams with excellent programming teams as well. I'd be hesitant to extrapolate from there that "anyone" can do it; apparently control is harder than the build.

I'll let you know after I prototype something this summer

[ajlapp]

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.

This is the reason we wanted to introduce commercial swerve components to the market. There is always lots of discussion amongst the community about how to keep FIRST competitive....

I disagree with making the game easier or artificially leveling the playing field through other means.

I'd much rather see a large portion of teams building high quality robots by using off-the-shelf items when necessary to bolster an area of their team where they may not have the expertise.

That said, swerve is tough to pull off even if you start with pre-made transmissions. Cyber Blue is hosting a swerve discussion this week in Atlanta about the months they spent leading up to competition developing the technology.

[fritzdejongh]

I'd like to ask this question on swerve drives: From what I've read, they typically don't have completely independent control of all 4 wheels, and perhaps there are choices and trade-offs on how exactly to control them and how many motors to devote to steering. How smoothly do they end up turning in place or making a tight turn for example? Does this involve wheels slipping? What is the experience on what level of control is helpful?

My experience with Mecanum is that it can turn an average-resource team into a competent scorer and move them up to seeded range, at least for Breakaway. With the included holonomic, gyro, and PID VIs programming is easy, and implementing field-oriented steering and gyro stabilization is also easy.

[Tom Line]

Originally Posted by thefro526

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.

I would tend to disagree. Full mechanical designs for swerves (or the pictures to allow you to easily reverse engineer them) have been around for years. I believe 217 posted a cutaway of their serve from 5 or more years ago. Those teams are more than willing to lend help to anyone who needs it as well.

However, you still see a lot of teams who have already DONE swerve not using them going forward. Nearly every big name team has done swerve several times, yet most do not pick it as their drivetrain of choice.

Why?

1. Complexity. Both mechanical and programmatically.

2. Advantage gained. I would put forward that last year and this year are two of the biggest swerve-advantaged games so far. Yet if you look at the top tier of teams in OPR, the proportion of swerve teams comes no where near 50%. Swerve has a huge number of trade offs, and the advantages are actually questionable nearly every year. You'd have a hard time telling me that 67, 469, and 1114's lack of swerve this year is hurting them. I bet the choice not to do swerve HELPED them in a big way during the build season - it was that much more time to work on their ball handling systems.

3. Cost. Whether you purchase a turnkey system like the 221 one, or whether you build your own, there is no small cost in engineering, materials, and machining.

I keep pointing out and I will continue to point out that Swerve is cool, but most teams that build it realize they'd rather be spending their time solving the game rather than solving a drivetrain, and a 6-wheeled or 8-wheeled drivetrain will perform nearly as well in most applications, and better in many.

[Andrew Schreiber]

Originally Posted by Tom Line

I would tend to disagree. Full mechanical designs for swerves (or the pictures to allow you to easily reverse engineer them) have been around for years. I believe 217 posted a cutaway of their serve from 5 or more years ago. Those teams are more than willing to lend help to anyone who needs it as well.

However, you still see a lot of teams who have already DONE swerve not using them going forward. Nearly every big name team has done swerve several times, yet most do not pick it as their drivetrain of choice.

Why?

1. Complexity. Both mechanical and programmatically.

2. Advantage gained. I would put forward that last year and this year are two of the biggest swerve-advantaged games so far. Yet if you look at the top tier of teams in OPR, the proportion of swerve teams comes no where near 50%. Swerve has a huge number of trade offs, and the advantages are actually questionable nearly every year. You'd have a hard time telling me that 67, 469, and 1114's lack of swerve this year is hurting them. I bet the choice not to do swerve HELPED them in a big way during the build season - it was that much more time to work on their ball handling systems.

3. Cost. Whether you purchase a turnkey system like the 221 one, or whether you build your own, there is no small cost in engineering, materials, and machining.

I keep pointing out and I will continue to point out that Swerve is cool, but most teams that build it realize they'd rather be spending their time solving the game rather than solving a drivetrain, and a 6-wheeled or 8-wheeled drivetrain will perform nearly as well in most applications, and better in many.

What is of most interest to me:

217: Swerved in 2003. Hasn't done it again. (Nonadrive is the closest they've come)
67: Swerved in 2005. Hasn't gone back. (This was a cool flop bot swerve though)
1114: Swerved in 2004. Hasn't gone back.
33: Swerved in 2005, switched to different drive train halfway through the season. Again in 2009: Maybe?
71: has been using swerve since 2005. (Of particular interest: Hasn't won a Championship since 2004)
111: even I don't know how long.
68: 2008,2009,2010. This year their swerve drive was too much of a technical undertaking for them.
148: Swerved in 2008. Hasn't gone back since.

So many veteran teams have tried swerve and gone back to traditional 6wd/8wd machines. 2009 was not a FULL swerve, only 2 wheels actuated as far as I can recall.

67, 6wd the last couple years. 8wd this year.
1114, 6wd. 8wd this year
33, 6wd.
217, 6wd (excepting this year)

I know correlation does not imply causation but I have a hunch that there is a reason why none of these teams have gone swerving again. It may be a cool thing, and definitely a design every team should have in their arsenal, but in most cases it is not the most efficient design.

[Tom Line]

Originally Posted by Andrew Schreiber

What is of most interest to me:

217: Swerved in 2003. Hasn't done it again. (Nonadrive is the closest they've come)
67: Swerved in 2005. Hasn't gone back. (This was a cool flop bot swerve though)
1114: Swerved in 2004. Hasn't gone back.
33: Swerved in 2005, switched to different drive train halfway through the season. Again in 2009: Maybe?
71: has been using swerve since 2005. (Of particular interest: Hasn't won a Championship since 2004)
111: even I don't know how long.
68: 2008,2009,2010. This year their swerve drive was too much of a technical undertaking for them.
148: Swerved in 2008. Hasn't gone back since.

So many veteran teams have tried swerve and gone back to traditional 6wd/8wd machines. 2009 was not a FULL swerve, only 2 wheels actuated as far as I can recall.

67, 6wd the last couple years. 8wd this year.
1114, 6wd. 8wd this year
33, 6wd.
217, 6wd (excepting this year)

I know correlation does not imply causation but I have a hunch that there is a reason why none of these teams have gone swerving again. It may be a cool thing, and definitely a design every team should have in their arsenal, but in most cases it is not the most efficient design.

One very slight correction. 67's 2008 overdrive bot actually had rear-wheel-only pseudo swerve. If you watch their matches that year, it will suddenly dawn on your how they can turn their corners so quickly.

[Chris is me]

Originally Posted by Tom Line

One very slight correction. 67's 2008 overdrive bot actually had rear-wheel-only pseudo swerve. If you watch their matches that year, it will suddenly dawn on your how they can turn their corners so quickly.

IIRC from reading an old thread, the back wheels were unpowered, just turreted.