Penalizing mecanum wheeled robots durring alliance selection.

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

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

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

[efoote868]

Originally Posted by Jared Russell

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

If you observed drifting of more than 10 degrees per minute and the robot wasn't saturating or shaking the gyro, what would you think? Would that be typical of the FRC gyro, or would that indicate a bad sensor?

[Tom Bottiglieri]

Originally Posted by efoote868

If you observed drifting of more than 10 degrees per minute and the robot wasn't saturating or shaking the gyro, what would you think? Would that be typical of the FRC gyro, or would that indicate a bad sensor?

We have not seen any of the recent kit provided gyros net that bad of a drift. I think bullet point #1 in Jared's list is the biggest culprit to gyro drift in a typical FRC match. Competitions are usually held in cold arenas and your robot won't start moving until a minute or two after you turn it on. We map a button on our operator console to reset the gyro calibration, and print out the current integrated angle so the driver can assess if they need to reset it. Ideally this is something we do automatically next year.

[efoote868]

One thing I would like to test is driving a field centric drive with a very large gyro drift (say +/-10 degrees).

If the driver can see the robot, I don't think a drift that large will matter (in tele-op). An interesting question would be, "How long can someone drive a field centric drive before performance suffers from gyro drift?"

I'd hypothesize that you wouldn't see a big difference in performance until drift reached ~15 degrees.


Coming back around to my questions, if performance doesn't suffer with 10 degrees of drift, I don't think gyro drift should be a concern preventing teams from using field centric drives.

[Max Boord]

Originally Posted by efoote868

One thing I would like to test is driving a field centric drive with a very large gyro drift (say +/-10 degrees).

I tried. Its impossible. Also, its not even the problem of a set drift. Its when it starts to drift several degrees per second. then, when robot not moving (to inbound, shoot, whatever) and you try to drive again you can not tell where is forward.

Once you realize the problem exists things don't get much better. Your robot will start driving in ever shrinking circles when you press forward.

Originally Posted by efoote868

If the driver can see the robot, I don't think a drift that large will matter (in tele-op). An interesting question would be, "How long can someone drive a field centric drive before performance suffers from gyro drift?"

2 degrees fixed is noticeable. 10 feels very weird. 2 degrees per second is enough to make a robot impossible to drive.

Originally Posted by efoote868

Coming back around to my questions, if performance doesn't suffer with 10 degrees of drift, I don't think gyro drift should be a concern preventing teams from using field-centric drives.

The main reason I think field-centric control it is not used more is fear of a delicate piece electronics being trusted to control a drive train. In addition, robot-centric is not that hard to understand.

[efoote868]

Originally Posted by Max Boord

I tried. Its impossible. Also, its not even the problem of a set drift. Its when it starts to drift several degrees per second. then, when robot not moving (to inbound, shoot, whatever) and you try to drive again you can not tell where is forward.

Gyro drift occurs when the gyro has very small errors in the rotation value it is reading (turning at 1 degree / second versus reading 1.001 degree / second).

When you integrate the error of rotation, you get an error in position.

What was discussed was that after the gyro runs for sixty seconds, the cumulative error is about 2-3 degrees, not 120 to 180 degrees.


Yes, a field centric robot that is off by 2-3 degrees per second is going to be difficult to drive, but I'd say something is fundamentally wrong with the system you're referencing (gyro not calibrated, pin out is wrong, code is wrong).