Mecanum or Swerve?

[sparrowkc]

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.

[Tom Line]

Originally Posted by Jeffy

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.

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.

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

[joek]

but, most tank drives use only 2 drive motors, whereas omni and mechanum ALWAYS use 4, so there is pore power being delivered, despite the 30% decrease, we have mechanum, and were able to push around tank drives like it was notheing

[Andrew Schreiber]

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.

Shedding some light on programming of mecanums. 2337's uses a simple version of linear interpolation. The 4 cardinal directions were declared in an array. We then look up which two to use based on which angle we want to move at and interpolate between the two. Pseudo-code below:

//Define the motors for the cardinal directions
cardDir = [[1,1,1,1],[1,-1,1,-1],[-1,-1,-1,-1],[-1,1,-1,1]];

//Angle is the angle we want to move at. 
a = angle/90;
b = a+1;
t = (angle-(a*90))/90;

//Lerp the thing
motors = cardDir[a] + t*cardDir(b); //Yes, I know b is completely unnecessary but it helped with readability imho 

//Scale it by the velocity

motors *= magitude

Turning is done by specifying a rate of turn and then multiplying the left motors by that percent and the right motors by the negative of the percent. (This part could be backwards, I can't recall)

This was written after we looked at the ugly mess of sines and cosines that did the same thing. We may have more than the 4 cardinal directions and may divide by less than 90 but I can't recall.

Not hard and allows for field centric controls given a good way of determining orientation.

EDIT: Yes, I left out the fact that you need to add the matrices but really it isn't hard.