Mechanum Wheels?

[Mara]

They're expensive and our team doesn't have any experience with them. We always end up sticking with good ol' tank drive.

[xXD3sEcR8xX]

Originally Posted by the man

I dont get it. As long as your not going mock 5, ok ok at fast speed in terms of robotics competitions, the back wheels will continue to push as you some what gently push your self over the bump. But we will test this tomorrow.

Mach 5... just saying

[Ether]

Programming a mec for basic functionality is trivial, even without the WPI library function.

Just take your driver commands for forward, strafe right, and rotate clockwise, and compute the speed of each wheel as follows:

front_left  = forward + clockwise + right;
front_right = forward - clockwise - right;
rear_left   = forward + clockwise - right;
rear_right  = forward - clockwise + right;

... then normalize the wheel speeds as necessary before sending the commands to the motor controllers.

[theprgramerdude]

Plus, with the library functions, it's quite literally one line of code.

They also DO have the functionality built in for field oriented drive; the
MecanumDrive commands are overloaded, so it's either a robot oriented control or field oriented, gyro based control.

Programming issues for mecanum (It wants to auto correct to Mexican???) driving really isn't an issue.

Crab/Swerve is another ball game.

[apalrd]

As a driver who has driven plenty of tank style skid steers, halo style skid steers, swerves, and slide drives (in VRC), this is my opinion on driving:

The third degree of freedom(strafe) takes much longer to master than the first two (forward and rotation). This is true for mecanum as much as it is for swerve and slide drives.

My other opinion to mecanums, or any other omnidirectional drive system, is that the ability to go sideways should be taken with its advantages and disadvantages. Don't ever go with mecanums just because they look cool.

I have not yet seen a video of a mecanum drive sliding around a defender, as many people make mecanums out to be. I have seen a very well driven swerve do it, but I have not yet seen a mecanum gracefully fake out or otherwise evade a somewhat competent defender. If someone can show me this, maybe I'll stop looking so far down on mecanums.

[Ether]

Originally Posted by apalrd

halo style skid steers

Could you please explain what you mean by a halo style skid steer? It seems like an oxymoron*.


*I've never played Halo (so my knowledge of it is second-hand) but had been led to believe that the use of "Halo" in FRC context referring to driver interface was related to strafing.

[EricH]

Originally Posted by Ether

Could you please explain what you mean by a halo style skid steer? It seems like an oxymoron*.


*I've never played Halo (so my knowledge of it is second-hand) but had been led to believe that the use of "Halo" in FRC context referring to driver interface was related to strafing.

As I understand the Halo controls (not having played it), one stick is motion and the other is rotation. In an FRC application, it would work better on a mecanum or swerve. The other similar type is a throttle stick/steering wheel setup.

[Ether]

Originally Posted by EricH

As I understand the Halo controls (not having played it), one stick is motion and the other is rotation.

Yes, but the "one stick" which is motion commands Y and X translation, i.e., forward/reverse and strafing.

So I'm trying to imagine what a Halo-style skid-steer would be, since you can't strafe a skid-steer.

The only mental image I can conjure up is arcade drive with 2 joysticks; one of which uses only the Y-axis (for forward/reverse) and the other uses only the X-axis (for rotation). But I can't see how that's better than a one-stick arcade.

[apalrd]

The "Halo" HMI uses the left stick as translation and right as rotation (4 DOF - forward, strafe, look side, look up). We just don't use any of the DOF's that the robot can't drive in, so for a skid-steer we use the Y axis of the left stick as the "throttle" and X axis of the right stick as "wheel" in an arcade or cheesy style drive. We use a cheesy style drive but automate the "quick-turn" input based on wheel values (more later in the post).

We've also implemented Halo controls on slide robots (3 DOF), and find them very nice to drive. However, while facing yourself, it takes much longer to get used to the orientation and slide the opposite way, something some of our VRC drivers handled very well, and something one of our VRC drivers never really handled. This is by far the best HMI for a 3DOF robot.

The "Cheesy Drive" is 254's arcade drive which uses "quick turn" and "speed turn" algorithms to find a much better solution than a standard arcade drive:
-When in quick turn, the output is a standard arcade drive -> Left = throttle + wheel, right = throttle - wheel
-When in speed turn mode, left = throttle + (wheel * throttle * gain) and right = throttle + (wheel * throttle * gain), so it handles speed adjustments properly.
-Quick Turn is only used when throttle is at or near 0, so you can turn without applying forward power.

[Ether]

Originally Posted by apalrd

The "Cheesy Drive" is 254's arcade drive which uses "quick turn" and "speed turn" algorithms to find a much better solution than a standard arcade drive:
-When in quick turn, the output is a standard arcade drive -> Left = throttle + wheel, right = throttle - wheel
-When in speed turn mode, left = throttle + (wheel * throttle * gain) and right = throttle + (wheel * throttle * gain), so it handles speed adjustments properly.
-Quick Turn is only used when throttle is at or near 0, so you can turn without applying forward power.

This table might be of interest.

The first column is for the simple L=Y+X, R=Y-X with normalization. The second column is the same as the first except it uses clipping instead of normalization. The third column is a slightly (very slightly) more complicated algorithm which I believe gives the same results as what you get from the WPI library (and may indeed even be mathematically identical... I haven't checked).

[ThirteenOfTwo]

Originally Posted by SuperNerd256

I'm not saying no mecanums (or however you spell it), but these are some points made in previous threads:

-Less traction on the key
-As already said, loss in pushing power
-Heavy
-Forces you to use maximum number of motors for drivetrain (not usually an issue)
-While they may not affect your ability to go on the bridge, the ability to stay without being pushed off or falling off of the bridge tips your direction will be tough to deal with
-You won't be driving circles around other's bots unless you have a lot of practice.
-In order to work to their fullest extent, require a lot of thorough engineering
-More complicated to code, even at the minimum level


Like I said, I'm not telling you not to use them, but when you do, be careful and engineer it through (Not meant to sound like most interesting man in the world meme, though I'm tempted. )

Most of these are fairly situational arguments. We're going with mecanum this year and I'm fairly happy with the decision, though I suppose that requires some justification. A little history is in order. This is gonna be long...

We, like many other Hawaii teams, started in Overdrive. We built an 8-wheel tank drive and did fairly well, though our claw was too easily damaged and we didn't make it very far in the competition. We observed that some of the drives that were highly successful in Overdrive were omnidirectional drives that could abuse the "lap" rule and kept it in mind for later use.

Lunacy was Lunacy, of course. We didn't get a chance to try omnidirectional movement, though we actually ended up being a really solid defensive robot because of our uncommon three-wheel single-swerve drive. We misanalyzed the game and didn't build a floor collection device, so we didn't make it out of Hawaii. Our driver loved being more mobile and better at turning than all of the other robots at the competition.

In Breakaway we again misanalyzed the game and thought that crossing the bumps was going to be an important part of gameplay, which it really wasn't. But we didn't want to be able to be blocked coming off of the bump, so we figured we needed horizontal movement on top of the bump or right behind it. So we picked mecanum. We did fairly well that year, captaining a semifinalist alliance, but were knocked out by the eventual champions. However, or "ball magnet" was very substandard and we couldn't strafe while using it, so we ended up not using the strafing at all. It was pretty bad, honestly; we had no room to use mecanum's maneuvering and we couldn't even really strafe. However, our driver got some practice maneuvering outside of the competition and we got software for mecanum developed.

In Logomotion we analyzed the game perfectly well, but the design we set out to build was beyond our capabilities to achieve. We decided on mecanum because we had had experience with it the previous year, we thought that strafing in the zones would be useful, and we liked the added maneuverability. The drive was actually great, but our arm was finished too late and we were unable to use it at competition, rendering us a defensive/feeder robot. We used the newly-lightning-fast mecanum drive to great effect in feeding, but because we were a feeder and not a scorer, we once again failed to make it to Worlds. However, we improved our mecanum software, got used to how strategy plays with mecanum, and saw how useful it can be on a big field.

This year, we saw the field and immediately thought "mecanum". The wide-open spaces, no-pushing zones, and small game objects just scream for a robot that uses maneuverability rather than power to avoid opponents. We'd gotten used to the idea of the mecanum drive, we had a very good one from the previous year sitting in our shop to model off of, and our analysis showed that bump-crossing (sort of like in Breakaway) is nice but not necessary. Our driver, who had gotten very good with mecanum, has sadly graduated, but our new trainees have taken to it quickly. We're pretty happy with our decision.

So with regards to your points...
1) Precise motion on the key is fairly irrelevant if you turret your ball-scoring device.
2) The loss in pushing power actually isn't as severe as people make it out to be. We've never been pushed around by a tank drive and we've even pushed a few (sideways) ourselves.
3) It's possible to get an effective robot very light this year by consolidating mechanisms. We are estimating that we'll come in way light even with mecanums. We need the extra weight.
4) Not an issue because there are so many motors this year.
5) Refuted by our testing of the bridge balancing two mecanum robots. Sorry, we don't have video.
7) Already done in previous years.
8) Already done in previous years. (Breakaway was sort of a happy mistake...)

You may have noticed that I skipped 6. I did it because I wanted to add even more text to an already unnecessarily overlong post.

Too many people think of mecanum in ways that are fundamentally wrongheaded. Mecanum isn't going to "run circles around" a competent defensive robot. Honestly, if you're running circles around anyone, regardless of your drive, their drive is probably atrocious. Neither is pure horizontal strafing very useful. The actual value of mecanum is in the more complex maneuvers that few first-time-with-mecanum teams discover (we certainly didn't discover them in '10). The bootleg turn, circle strafing, and impact redirection are three examples of genuinely valuable things that mecanum enables you to do much more easily than tank drive does, but you hardly ever hear about them in mecanum discussion. Pro-mecanum people and anti-mecanum people alike often don't know what they're talking about.

Other assorted thoughts on mecanum drives, because apparently I don't feel like I've typed enough yet...

The pushing-power thing is blown way out of proportion. Unless your drive is stupidly weak or your opponent's is stupidly strong, you're not going to get shoved around, and mecanums can push tanks sideways (and occasionally head-to-head).

Mecanum can maneuver well on the bridge and the key alike, based on our tests. Super-precise maneuvers on the key don't seem all that useful anyways.

The fragility thing is blown way out of proportion, too. As long as you don't do anything stupid (like drive over the bump this year without wheel guards), you'll be fine.

Not everyone can drive a mecanum well. Some people who pick them up drive them like tank drives that can strafe horizontally, which is dumb, because that just makes them weaker tank drives with a bonus feature that your driver is likely to forget about. It does take practice, and it also takes a different way of thinking.

The no-mecanums-on-Einstein thing is a silly myth. FRC is fairly stratified and teams feel comfortable doing what they've done before; teams who have been around for a while (which tend to be the best teams) have been doing tank for a long time. Many teams who have the resources to get to Einstein have the resources to build a swerve instead of a mecanum. Which is better.

Even though we've used mecanums each of the last three years, I'd like to think we're not set in our ways. This year, we essentially knew going in that we wanted to use mecanum because it was the only thing that we've really refined. However, this was a good year to be forced to use mecanum. I've always had some doubts--a lot of very smart mentors from very good teams swear off mecanum, and I figure they can't all be wrong and we can't be the only ones who are right. We're planning to branch out next summer when we have the resources and the time to develop a good new drive.

In conclusion, mecanums are good when:
-there are wide-open spaces on the field
-game objects are fairly small
-your programmers have a modicum of experience
-the game is not pushing-heavy

Mecanums are bad when:
-your driver is entrenched into "tank-thinking"
-your programmers are very inexperienced
-the field contains many obstacles or small spaces
-you need to push to get access to a zone
-you have the resources to build a swerve

I hope that this post didn't bore anyone to tears and that it was informative, if only to help you see the (maybe misguided from your point of view) thought process of someone who's coached a mecanum robot for all of his time in FRC.

[pfreivald]

Originally Posted by EricH

As I understand the Halo controls (not having played it), one stick is motion and the other is rotation. In an FRC application, it would work better on a mecanum or swerve. The other similar type is a throttle stick/steering wheel setup.

This is why I chuckle (not out loud, due to an overbearing sanity) every time I read something about mecanum being hard to program or to use. Mecanum straight out of the box works very well (as long as your CG is in the center of the wheels), and -- this is the big part -- controls EXACTLY like a first-person shooter. This means that your average driver has a gazillion hours of practice controlling an out-of-the-box mecanum-type system, even if they've never done a minute of FRC. We love mecanum drive, and this will be our third year using it.

That said, IMNHO straight-up mecanum will have a much bigger problem this year than barriers and bridges, and those using it will find that other robots are a great impediment to success.