Penalizing mecanum wheeled robots durring alliance selection.

[AdamHeard]

Originally Posted by efoote868

If they wanted to be a lap runner in 2008, or they wanted to quickly clear soccer balls from a zone in 2010, or they wanted to strafe in front of the racks in 2011, or they wanted to strafe sideways to quickly catch a truss shot and release a ball in 2014, or they want to move in an L shaped fashion without changing orientation in 2015 then a holonomic drivetrain might be the correct fit for them.

You cannot know the best implementation to a strategy without knowing the strategy, and you cannot know the strategy without knowing the game rules.

You're not reading what I'm saying.

I agree those features are cool, and all have some arguable utility...

My argument is that if the same amount of resources put into that were put into something else, the net competitiveness of the team would be higher.

[MARS_James]

Originally Posted by efoote868

If they wanted to be a lap runner in 2008, or they wanted to quickly clear soccer balls from a zone in 2010, or they wanted to strafe in front of the racks in 2011, or they wanted to strafe sideways to quickly catch a truss shot and release a ball in 2014, or they want to move in an L shaped fashion without changing orientation in 2015 then a holonomic drivetrain might be the correct fit for them.

You cannot know the best implementation to a strategy without knowing the strategy, and you cannot know the strategy without knowing the game rules.

Speaking from experience in those games, in 2008 unless you were small (like 148) lap running would not give you a significant advantage for it to be a reliable strategey since the field got very cramped. 2010 was a horrible year for mecanum bots in florida because the cramped quarters actually made for viscous defense so clearing soccer balls would have been a challenge. 2011 as a team that ran mecanum for the exact reason you listed I wish my team would have gone another way, sure we were an alliance captain but the draw backs it gave us were not worth it especially come eliminations. 2014 from my observation the best catchers did not have mecanums this year, the 2 best catchers in our state, my own robot and its twin 1251, ran 8 wheel drive.

There will be a day when the best solution for a game is a well designed holonomic drive, unfortunately for most teams that will mean upper level teams running swerve, mid level teams running octanum, and mid-low level teams with pure mecanum. That game will have a mecanum wheel make it to Einstein, and touch the carpet, but swerves will rule.

[efoote868]

Originally Posted by AdamHeard

You're not reading what I'm saying.

I agree those features are cool, and all have some arguable utility...

My argument is that if the same amount of resources put into that were put into something else, the net competitiveness of the team would be higher.

I'd maintain that the amount of man hours required to build a decent mecanum drive are not that much more than the amount of man hours required to build a decent tank drive, and the difference in man hours is minimized compared with any other holonomic drive.

[EricH]

Originally Posted by efoote868

I'd maintain that the amount of man hours required to build a decent mecanum drive are not that much more than the amount of man hours required to build a decent tank drive, and the difference in man hours is minimized compared with any other holonomic drive.

Mechanically, yes. The amount of man-hours required to build a tank drive and a mecanum drive will be very similar from a mechanical standpoint. 2 more gearboxes, possibly wheel assembly, that's probably under a typical meeting for 1-2 people.

HOWEVER, to truly calculate the time, you need to factor in programming. A tank drive can be as simple as mapping two joystick axes to two PWM (or CAN) outputs (in teleop, anyway). A mecanum drive requires three joystick axes mapped to four PWM/CAN outputs, and the outputs can all be different (in theory at least, in practice it'll more likely be two and two, but which two changes a bit...). Sure you can use the pre-done stuff and adapt it--but you are going to want to tweak it to match your system, which may or may not be more trouble than it's worth.

That extra time may be the difference between a so-so vision code or so-so automode and a good or great vision or automode.

[Kevin Sheridan]

Originally Posted by EricH

Mechanically, yes. The amount of man-hours required to build a tank drive and a mecanum drive will be very similar from a mechanical standpoint. 2 more gearboxes, possibly wheel assembly, that's probably under a typical meeting for 1-2 people.

HOWEVER, to truly calculate the time, you need to factor in programming. A tank drive can be as simple as mapping two joystick axes to two PWM (or CAN) outputs (in teleop, anyway). A mecanum drive requires three joystick axes mapped to four PWM/CAN outputs, and the outputs can all be different (in theory at least, in practice it'll more likely be two and two, but which two changes a bit...). Sure you can use the pre-done stuff and adapt it--but you are going to want to tweak it to match your system, which may or may not be more trouble than it's worth.

That extra time may be the difference between a so-so vision code or so-so automode and a good or great vision or automode.

I would even argue that mechanically there is a pretty big difference too. The tolerances are a lot tighter when machining and assembling the frame for mecanum, otherwise you could end up with only 3 wheels on the ground and a really bad drivetrain. 6WD tank is much more forgiving in regards to bad machining.

[donkehote]

Originally Posted by AdamHeard

I would tell them their strategy is likely flawed and they don't need holonomic movement.

QFT

[Andrew Schreiber]

Originally Posted by Kevin Sheridan

I would even argue that mechanically there is a pretty big difference too. The tolerances are a lot tighter when machining and assembling the frame for mecanum, otherwise you could end up with only 3 wheels on the ground and a really bad drivetrain. 6WD tank is much more forgiving in regards to bad machining.

Oddly, for mecanum you want a floppy chassis. Rigidity is your enemy. It's one of those small things most teams miss when building mecanum and then get confused when they lift a corner on a mounting plate under the carpet and their bot gets all squirrelly.

But I wouldn't know this unless I've built a handful of omni directional drives (kiwi and a handful of mecanums) and fielded them. It's NOT as simple as people think.

[Max Boord]

Originally Posted by Kevin Sheridan

I would even argue that mechanically there is a pretty big difference too. The tolerances are a lot tighter when machining and assembling the frame for mecanum, otherwise you could end up with only 3 wheels on the ground and a really bad drivetrain. 6WD tank is much more forgiving in regards to bad machining.

My team has run varying degrees of "floppiness" and pretty conclusively showed a rock solid chasis with properly tuned PID loops preforms about the same or worse than a floppy frame running the default WPI holonomic code. The difference also increases as the robot goes through more and more events.

EDIT:
CG has far more of an effect than frame rigidity. Even 2 metal pneumatic tanks on one side caused strafing to deteriorate noticeably.

[jwfoss]

After further thought, I believe my first post was not blunt enough.

In reality, if mecanum wheels are the answer, I have found that I have asked my self the wrong question. There has not been a single game in my opinion where mecanum drive (or any omni-directional drive for that matter) has presented a significant enough advantage to justify the development of such a drivetrain. It goes against a fundamental rule that anything new in a drivetrain must be tested in the offseason.

Remember the three most important parts of a robot...

[Nemo]

Originally Posted by EricH

That extra time may be the difference between a so-so vision code or so-so automode and a good or great vision or automode.

Maybe our team is just "challenged," but we have repeatedly failed to get vision processing to work, whereas adding gyro feedback to a mecanum drive was not a big deal.

We can get vision processing code to work in the shop, but we haven't ever gotten it to work on a field with venue lighting and bandwidth limitations. We've also had communications issues with the camera and program lag with the camera turned on. These are solvable problems, but we have run out of time in the years when we tried to make it work.

[Max Boord]

Originally Posted by Nemo

We can get vision processing code to work in the shop, but we haven't ever gotten it to work on a field with venue lighting and bandwidth limitations.

Have you ever tried going out to the field on thursday durring lunch/ after matches end and tuning it then? I know orlando lets teams do this if for some reason practice matches are not being run.

Also, adding gyro feedback for field orriented drive is incredably simple until it starts to drift.

[efoote868]

Originally Posted by Max Boord

Also, adding gyro feedback for field orriented drive is incredably simple until it starts to drift.

In my experience, this isn't a problem in the 2 minutes required to run a match.

[Monochron]

Originally Posted by efoote868

In my experience, this isn't a problem in the 2 minutes required to run a match.

You may want to qualify that with "in my experience with very low drift". I have seen large amounts of drift absolutely ruin a robot's ability to move reliably. Like always, strict tolerances are needed for a control system like this.

[efoote868]

Originally Posted by Monochron

You may want to qualify that with "in my experience with very low drift". I have seen large amounts of drift absolutely ruin a robot's ability to move reliably. Like always, strict tolerances are needed for a control system like this.

Both years using field-centric drive utilized the kit gyro, and as far as I know the drivers never needed to reset the orientation.

I do recall a problem one time shortly after installation, but that was because we'd accidentally hooked to the temperature output.




Does anyone know off hand what expected drift is over time?

[Jared Russell]

Originally Posted by efoote868

Does anyone know off hand what expected drift is over time?

It's...complicated. Drift happens because you are taking an angular velocity measurement and integrating it over time. Small errors in velocity measurements add up to big errors in position given sufficient time. There are many sources of errors, some of which are random and others of which are systemic:

1) Bias drift. MEMS gyros are sensitive to temperature...and they self-heat when powered. Several minutes after booting your cold robot, the gyro will think it is spinning because the null voltage when it was calibrated with has changed. Leaving your robot on for several minutes prior to match start (and recalibrating the gyro soon before the match starts) helps somewhat.

2) Axial misalignment. If your gyro is not perfectly level with the field, you will accumulate small errors over time. Aligning the gyro to your frame is one thing; going over a bump or doing a wheelie on the field is another.

3) Saturation. If your gyro measures up to 250 deg/s rotation and you spin faster than that, you will underestimate your rate of turn and drift will accumulate quickly.

4) ADC discretization and conversion noise. Your analog measurements lose some precision during the conversion to a digital measurement. Carefully selecting the bandwidth to use during sampling helps somewhat, though narrower bandwidth may limit your ability to sense rapid turns.

5) Cross axis sensitivity. Unfortunately, it turns out that gyros only MOSTLY measure angular velocity...they also pick up linear accelerations (typically <1% of cross axis sensitivity, but every little bit counts when integrating).

6) Thermomechanical noise. Unfortunately, even if you perfectly compensate for all of the other factors, Brownian motion occurs within the gyro and will add up over time. There is nothing you can do about this one other than to buy a more expensive gyro.

Various specs for all of these factors are available for most gyros. Turning this into a "degrees per minutes" position drift estimate is possible using complex math; for the KOP gyro from a few years back (which I believe is still the gyro available through FIRST Choice as of last season), about 200 degrees per hour is the quoted drift rate. Drift in position occurs exponentially, so in about a minute you would expect ~.05 degrees of drift...IF you perfectly account for the accountable factors above (which is almost never the case in FRC). In my experience, a degree or two of position drift per minute is more achievable (as long as you don't spin too fast and stay on a flat and level field).