Re: Penalizing mecanum wheeled robots durring alliance selection.
 

The issue I see with mecanums is that a lot of teams don't drive them like mecanums. They drive them like tank and don't take advantage of the omni-directional capabilities of the wheels. If mecanums were driven correctly (like Team 126 and 58. They know how to drive!), then I think we would be having a different discussion.

It's the same for all configurations. Omnis should be driven like Team 33 did. Swerve. Well if you made a swerve then you know how to drive it correctly because your that smart!

The key to a well driven drivebase is taking advantage of your drives strengths and weaknesses. Tanks shouldn't get t-boned because they can't get out of it. Mecanums shouldn't stay in corners to long because they can't push their way out if they get defense.

In my book, go tank! Only use mecanum if you drive it right and don't waste your time. Unless you want to try something new. Then go for it with gusto and lots of patience!

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Yes, they can.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

This year in particular, Mecanyms = DNP for the simple reason that most of the game is spent in contact with other machines - either playing defense or under defense.
In another year where 6 machine pile-ups aren't common and defense isn't as critical, mecanum bots will be back on the table.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

I gotta ask, why did your team say yes to 2152 in South Florida then? The competition wasn't that deep I admit but you were next up in the pick order so the difference would have been negligible.

EDIT: Also 21 your other alliance partner ran mecanum this year, did your team try to talk 2152 out of it or no?

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

I agree with that point, I just don't agree that we should completely ignore what a mecanum wheeled robot did just because they did it at an off season event.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Our first pick and our second pick(1533 and 2068) at Virginia had mechanum wheels as well as our number one robot on our list at Chesapeake(1629) picked us and our second pick also had mechanums(623)

I'm personally not the biggest fan of them, but at both our regionals we were the only bot on our alliance to not have mechanums, so I'd say as long as you can use them they don't affect anything haha.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

I've seen one exceptional implementation of Mecanum wheels in all of FRC ever- and that is Team 2052, KnightKrawler, as has already been mentioned in this thread.

I've also seen a few robots where the ability to strafe gives them a marginal benefit over a traction drive- 126 2013, 58 2012- where the ability to strafe gives them an ability they wouldn't have had otherwise.

I think all of these robots, barring perhaps 2052, would have been just as good or in some cases better with a traction drivetrain. However, it depends on the strategy and role your robot intends to play on an alliance.

If you were a cycler in 2013, a Mecanum drivetrain can be fine, sometimes even a good thing.

If you were a full-court shooter in 2013, where your entire strategy revolves around reaching a location and staying there for the match in order to score points, you should have a drivetrain that allows that.

In 2014, any robot that could get easily pushed across the field moved down the picklist, purely because that makes it more difficult for them to score. If you drove that same robot like 33, you move back up the picklist because your driving is fantastic and makes up for that to a degree.

If your robot exhibits negative qualities in a match, it will get penalized- not because it specifically has a certain mechanism on the robot, but because the robot doesn't do what needs to be done, and that could cost my team the regional.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Quoted for truth

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

At crossroads this year, my team picked 2 mecanum drives (2358, 4085) as the 8th seed. These robots were very strong as defenders because they were maneuverable and tall enough to block the other alliance's shooter. It's about picking a good alliance, not good robots.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

I can't go into specifics, but there was a lot going on in regards to Alliance Selection at SFL that we (I especially) left to chance and the gamble didn't pay out in the brackets. I learned a lot and will be making adjustments for next year.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Yup. In 2010 our robot had mecanum wheels and we definitely used them to our advantage. It was a great season for us winning 1 Regional, finalist at the other, and we made it to the semi-finals at Championships.

Although I agree that New England has some of the heaviest defense, I believe it is still possible to use mecanum to your advantage. We won the WPI regional and were finalist at the Connecticut regional (both in New England) in 2010 because we used the mecanum as a specific feature... and also because we had a very sturdy and well implemented control system.

I also agree that using it just for the perceived maneuverability and without gyro stabilization and other optimized control software can be a recipe for poor performance.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

At least in the Capitol Region, many of the teams who did Mecanum drives 2010-2013 had magnificent and beautiful looking drive trains, followed by piecemeal and somewhat functional mechanisms. This tells me that while the Mecanum drive probably works well, the drive team probably had very little practice with using the drive train and mechanisms together. 623 was typically a good example of this, yet in 2014 they pulled it together and found a very lucrative role they could reliably fill, winning them Chesapeake.

It's tough to write off a Mecanum drive just by itself, IMO. It's far better to see how a team uses the Mecanum and how well the robot performs a role relative to other robots that perform the same role.

BTW, to me this wording is as hilarious and ironic as a license plate that says "Epic Fai" - I just may have to change wording in some of my drive train presentations:

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Originally Posted by DanBrowne
Tanks shouldn't get t-boned because they can't get out of it.

Source? We all know there are little tricks like deployable omnis or ball casters, choice of bumper fabric, etc., but if it was as simple as "yes they can," then RUSH would not have won MSC this year.

*Yes, there are methods of escaping a pin faster than others, but "yes they can," implies that T-bones are no more an issue for tank drives that other drive systems.*

*Edit: Rudeness + accuracy

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

I am reasonably confident that 1678 probably knows a thing or two about handling defense... He isn't saying that T-bones are easily beatable, he's saying it is physically possible for a tank drive robot to escape a T-bone pin. This happens all the time, just not quickly or reliably enough to satisfy many teams.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

I'm pretty sure they got to see some high level in play after back to back Einstein appearances as the #1 seed.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

There was no indication on the information visible in the post that he(she?) had been a part of 1678. I am very aware of how highly they perform, so I am actually pretty surprised that he/she would simplify friction pins as "yes, you can drive out of them."

When you consider that they play on the same field as 254 and 971, this comment is even more surprising, because if it was as easy as driving out of them, then 254 would not bother with their extensive testing of bumper materials, and 971(unless it is for envelope reasons) would not bother with an octagonal drivetrain. At some level you must know you cant just drive out of them either, as you too are updating your 2014 robot with a different bumper shape.

In the bulk of situations, the premise is wrong, regardless of who says it or what team they are from.

Edit: Although I will admit, my comment was unnecessarily rude. I am sure I am not the only one who gets tired of misinformation on CD.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

With our new bumpers we can literally just drive straight out of a t-bone. No special maneuvers necessary. We did extensive tests using 971's practice bot, which is t-bone machine (Austin used that robot to t-bone our robot with the old bumpers until the batteries died), and we were able to escape t-bones in under 5 seconds every time.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Was this using the sailcloth covers? I bought some to do some testing with but have yet to get the chance to actually try it.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Yes. We also had new pool noodles that were significantly harder than our old ones. A "downside" is that is also became really hard to play defense with the new bumpers. Our driver could no longer rely on friction pins and had to learn how to stay in front of robots better since it became really easy for other robots to "slide" past the bumpers.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Tank drives such as 254's, 971's, or 1678's can get out of pins precisely due to clever use of bumper shape and material selection. One may even go so far as to say, as others in this thread have done, that the ease-of-use of such drivetrains allows teams to funnel more resources into other aspects of the robot, such as the aforementioned bumpers. Then again, even though I was part of team 1678 for the past two years, I didn't see a single one of our division qualification matches, so what do I know?

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Did you guys try leaving the front and back noodles "squishy" and the side noodles "firm"? Seems like the best of both worlds there; obviously most T-bones don't involve the front of the robot.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

We did not have time to test different set ups for front/back and the sides. The bumpers were barely finished before SVR because Colin tested several different fabrics after Waterloo so we had little time to make the new set of bumpers. We also havent had time to revisit bumper testing this offseason because of Chezy Champs.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

So according to the poll as it is right now, ~40% of teams would either move you lower on their list or not pick you at all for having mecanum wheels.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

I am very aware that some of the best teams in the world are able to get out of friction pins pretty quickly (which is a relative term, meaning the average time to get out of friction pins is anything but quick), this is not what I was addressing. I was addressing the other 2700+ teams that have to decide every year what drive train they want to use. Most of them will not do extensive research, and many will be making their bumpers on practice day. Accounting for this, if for some reason not getting T-boned is their number 1 priority, then tank with traction wheels is undeniably the worst decision they can make.

Tank drives are great and I would probably never willingly field anything else, but relative to other drive trains they are the most susceptible to friction pins. Outlier cases can be misleading, but perhaps my statement was too. Of course the teams that can get out of t-bones the best are some of the highest level teams, but just because something is possible doesn't make it likely.

I will concede however, that I should not have been so rude, and I apologize.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Fixed it for you.

Going to quote myself to save some effort
[in response to "mecanum wheels have never made it to eEinstein"]

In my humble opinion, the game this year did not lend itself to a strictly mecanum drivetrain. The field was wide open, the position of your robot mattered (favoring high traction drives), and quickness and speed mattered (in both short distances and cross field - something that benefits multiple speed transmissions).

If next year's game saw upwards of 30% of teams choosing mecanum drivetrains, and still none of those teams make it to Einstein, there might be something to that statement.


Excluding robots based solely on their style of drivetrain isn't too intelligent; one would do better to look at the complete package as well as how the robot's functionality and performance could fit into a prospective alliance.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

That's a good point. I would be interested in knowing the total number of teams that chose each drivetrain. I don't think a CD poll would ever be a good way of finding this out, as more advanced drive trains would be over represented. (new teams that don't follow CD and used the kit bot would be under represented, where great teams that pick swerve may have 5 members following CD and all select that option in the poll). We would need to look at real scouting data for the answer to that. For example in my division at Champs, Galileo had 10 mecanum bots that I know of based on my scouting. They went 8-2, 8-2, 8-2, 3-7, 6-4, 2-8, 4-6, 6-4, 5-5, and 3-7 in qualifications, for an overall 53-47 record. In Galileo at least, it looks like mecanum drive performed more or less on par with the rest of the field based on that overall record.

Knowing the overall percent of teams that choose each drivetrain, their percentage of making it to champs, and their winning records, would all be pretty interesting information. That probably isn't pertinent to this discussion though as I think you need to judge the robot on individual performance. The difference between a good swerve and bad swerve may be the difference between moving in a match or not, so you obviously can only take these generalizations so far. Assuming you have a functioning drive train I still feel driver practice is the single most important aspect with any drive train.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Sorry I was not specific enough for your liking. I will try to be much more descriptive next time I make a simple observation so as not to be criticized for the lack of detail.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Statistically it doesn't really matter what percentage of teams run a certain drive, it's what percentage of competitive teams are running a certain drive.

I don't really care what n% of teams run, as it's reasonable to state that for whatever reason n% aren't a top team.

However, the decision making process of the proven competitive teams provides much more insight. The top teams, far more than any other, are constantly assessing things for competitiveness. They are also generally the most willing to COMPLETELY contradict historical beliefs (of the public, or their own) because something has value to them.

To me it speaks volumes that more top teams don't run them. I'd wager a fair number of top teams have tested mecanums in private, and chose to not use them. I won't say that we are or aren't a top team, but we tested mecanums (this is the first time it's public knowledge) and were not happy with them versus a fast and well tuned Nwd.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Top teams don't run mecanum drives because they don't have to. When they choose to use a holonomic drivetrain, they have the resources and can afford the added complexity of swerve or butterfly - they engineer out the known deficiencies.

To me, the beauty of AM's mecanum wheel is that it makes easy holonomic drivetrains available to low resource teams.

IF we see more field layouts like 2010 (with tight areas to maneuver and precision driving required), I suspect we'll see more teams chose holonomic drivetrains, which will mean more mecanum drives.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

I'm going to disagree with this notion because, as it's written, it's missing a key point.

(Keep reading after it, I do clarify it significantly.)

You know, I can go out and buy a swerve module too? I'd make the exact same statement about a drive with them. Why? Because the hard part about holonomic/omni directional drive systems is they are hard to control. The mechanical aspects of things are hard (yes, even mecanum wheels) but building a reliable, tuned, and intuitive method of controlling them is HARD.

So, let's take team number 4xxx. They are your average semi experienced team. Some resources but not enough to build a second bot. Enough resources to build a solid manipulator and put it on a KOP drive train. Maybe even get a couple hours of driver practice.

Now imagine they put mecanum wheels on that KoP drive (because it's not hard. Costs about as much as adding shifters which is another system this logic CAN apply to). So, I've added some extra work beyond implementing simple skid steer drive. I guess I can use the WPILib's Mecanum implementation. But my robot turns as it strafes because my CG isn't perfect, what do I do? It's either something the driver has to get used to or it's something I have to invest more of my most limited resource (manpower) into fixing. So, now my manipulator has lost an iteration or small tweaks? For what gain?

Most teams don't think of problems this way. But they should.


Mecanum wheels are a solution to a problem. But they aren't as simple as slapping them on and using the WPILib Mecanum Drive class. That's a great way to build a crappy omni directional drivetrain. If you want it to be world class you need to develop and test a reliable and intuitive user interface. And you need to understand how it changes how you can interact with game objects and the field. It needs to be built into your greater strategy. And your driver needs to understand the limitations and benefits of your drive system.


Omni Directional drivetrains ARE inherently difficult. Nothing is ever going to make them easy to do. COTS parts simplify the mechanical issues with them. But the hard part is always going to be the UX.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

I agree that a team needs to build their robot for a strategy. In recent years, the ability to strafe hasn't been high on my priority list.

But if a low resource team were to come to me, and tell me that they must have a holonomic drivetrain for their strategy, and they wanted a recommendation, I would recommend mecanum 9 / 10 times.

In my experience, mecanum drive trains are simple to implement, can be robust with just a gyro for field centric control, and when all else fails you can swap out 4 wheel chair wheels.

I agree though, strategy trumps drivetrain.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

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

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

So true. There has yet to be a game that really requires holonomic drive to win.
(WildStang 2003 may be an exception)

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Well, I'd buy the argument that in some games holonomic makes sense in some ways.

However, for a team with presumably not the same resources as a top team, when you factor resources into strategy, mecanum in my opinion is never the option.

If you're at that level, there are likely other areas of the robot that would have a greater payout for the same resource investment.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

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.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

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.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

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.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

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.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

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.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

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.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

QFT

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

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.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

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.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

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

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

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.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

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.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

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

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

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.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

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?

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

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

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

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?

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

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.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

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.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

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.

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

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.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

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

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

I agree with this assessment. We always throw out the WPI library and do our own bias calculation and integration. Our method is simple: big moving average for the bias calculation up until the instant the FMS switches from disabled to auto - then we freeze the bias and start integrating.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Interesting. with the KOP gyro my setup would accelerate up to 20 degrees per second in some cases while in others would only move 1-2 degrees per minute. The drift would also change direction so I do not think it was a calibration issue. I even tried it on a spare CRIO and got similar results to one encased inside a driving competition robot.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

My team had mecanum drive train for Ultimate Ascent and that was the season that our team actually performed the best. We were alliance captains and made it to semi-finals at our regional. We also won the quality award. In my opinion mecanum is a valid choice for a drive chain and when used on the right robot, can be very effective.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Allot of post on this subject. My take on it is that going forward any team that is considering a omnidirectional drive system should evaluate the performance of that system compared to the six cim tank drive. The new standard. The power of 2 additional cims changes the game. Low resource teams can purchase Cots 3 cim gear boxes and have a very good powerful drive train easy now. This year with swerve we found that when we went up against the best we were too slow and at the same time did not have enough traction. We as a team realize that our current 4 cim swerve is not enough going forward. We as a team are working on taking swerve to the next level by adding more power and easier driver control. We've built a tribot and have been testing it. We have a 6 cim swerve module designed but not built for it . There are allot of positives on the drive ability of it but also negatives for the shape. For a 4 swerve module we have built a quasi cvt 1 cim module and are designing a 4 cim 4 mini cim drive. At the same time we're working on methods to make an omni directional robot easier to drive. Yes, there is a drive train arms race. Keep up or get nuked next year. Mecanums may have been relevant in the past . There utility in the future is very questionable. In my opinion.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

About the gyros:
In our swerve drive, sometimes I'll turn on the robot and the gyro might start drifting at 3 deg/sec at times. Even when it doesn't drift this bad, it accumulated quite a bit of error in a match. This seems inevitable; we've replaced the gyro many times.

We have a gyro reset button, and I end up calibrating the gyro many times in match. Even with the reset, I sometimes find myself driving with 25+ degrees of error.
Somebody above said that this was impossibly disorienting, but I find it manageable.
I got used to gyro inaccuracies after some practice.

Nevertheless, we're determined to improve the system. We are going to try using two gyros, one mounted upside down. 1717 does this and says it helps a lot.

Even if I had to deal with gyro drift forever, if still greatly prefer field centric over robot centric

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

I don't think you need two gyros or non-kit gyros. We have seen similar problems with the WPI gyro code, which is why we do our own bias calculation and integration - see my above post. If you need more details, let me know.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Hmm, that's interesting.
Yeah, I'd love to know the details of how you guys calculate that.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

This is going to be a long post. I'm trying to target this post at relative newbies, so if any of this is old news feel free to skip to the good parts.

(Since this got long, I'll break it into two posts: the first will be explanation (the "why), and the second will be the "how" part.)

The vast majority of gyro "drift" is usually due to a poor voltage bias calculation.

What is this "bias" that you speak of? The sensor outputs a voltage relative to the angular rate (these devices are angular rate (speed) sensors, not heading sensors). The voltage when still (angular rate = 0) is typically around 2.5V for a 5V sensor, but in reality that can vary for many reasons. Therefore, the software always needs to calculate the voltage bias before using the angular rate to compute a heading. The bias is used by subtracting it from each sample before computing the heading. Thus, after the "bias subtraction", the sensor output is transformed from 0 - 5V to approximately -2.5 - +2.5V.

How is the bias typically calculated? The bias is calculated by averaging a number of samples when the software thinks the gyro is still. The WPI gyro software performs this calculation as soon as the software begins to run. Any movement of the robot just after power-on until the bias calculation is finished will cause your bias to be bad, and you will get a large gyro drift. "When is the WPI code finished calculating it's bias so we know it's safe to move the robot?" you ask. Good question. I don't really know, which is one of the reasons we don't use it. Another reason we don't use it is because we find it nearly impossible to keep the robot perfectly still immediately after power on.

Can the bias of the gyro drift? The short answer is yes. If you calculate a good bias, and then the bias changes, your heading will drift over time. That's not good.

What causes the bias to drift I don't want to repeat a good post: see Jared Russell's post above. One important I'll repeat: the bias is likely to drift as the gyro warms up. Therefore, in an ideal world you would like gyro to be at its steady-state before calculating the bias. The WPI code does this immediately after power-on so the likelihood of bias drift is much higher than if you could wait.

Ok, then in your opinion when should the bias be calculated There are 3 main criteria for me: 1) The robot MUST be PERFECTLY STILL; 2) The gyro should be at steady state; and 3) The bias calculation should be performed as close as possible to the time your are going to start using it (in other words, a bias calculation from 5 minutes ago is much less likely to be accurate than a bias calculated 1 second ago).

So when do YOU calculate the bias? Simple answer: the instant before the match begins. This ensures it satisfies all three criteria: 1) the robot will be perfectly still since all humans have to be off the field or someone is getting DQ'd; 2) The gyro should be at steady state since it has been a few minutes since power-on; and 3) the instant before the match starts is as close as you can get to when you start using the bias.

What are the disadvantages of your method? The WPI gyro code can't be used, and you have to write all of your own software.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

So, how do you actually do it?

First, we throw out the WPI gyro library and just use the analog input library. You'll need to know the sensitivity of your gyro (in deg/s/V), but if you don't know that you can make a guess and figure it out with some testing. We always do the tests anyway to characterize the sensor we're using.

You need a few things in your code:

1) An array of gyro voltage readings so you can calculate a moving average. This moving average will be stopped once the match begins and this average will become your gyro bias.

2) A variable to indicate that your robot has become enabled once during this power cycle. Why is this important? Because you don't want to resume calculating the bias in that short disabled period between auto and teleop. You may say, "but you said a bias calculated as close to the the current time possible is better, so wouldn't it be good to calculate it again just before teleop?" The answer is no, because then you have a good chance of violating the most important criteria: the robot MUST be still. There is a decent chance that either your robot was still in motion as power was cut to end autonomous, or some other robot runs into you at the end of autonomous. Either way, the safe bet is to just use the bias from just before auto mode starts.

3) An integral to calculate the heading from the angular rate samples. (If you don't know what that is, it's a fancy term for area under a curve, which is a big sum. Look it up on wikipedia.)

So here it goes with the code:

(note: caveats apply. a) I'm doing this by the seat of my pants, so there may be a bug or two; b) this is more intended to be pseudo-code rather than copy-and-paste C code; c) this is intended to provide a general idea - not a final solution - see (a) and (b))

(note 2: I'm going to assume you have a typedef.h file and use descriptive types. f32 = 32-bit float, u8 = unsigned 8-bit integer, s16 = signed 16-bit integer, etc.)

defines and global variables
In your "init" function
In your fastest periodic loop
And there you have it.

I would highly recommend characterizing the sensor you're using rather than just using the sensitivity from the data sheet. Not only can the sensitivity vary from part to part, but the sensitivity can be reduced if the gyro isn't mounted perfectly flat. Here's how we do it:

1) make your best guess at the gyro sensitivity (use the nominal sensitivity in the data sheet if you have it).

2) Place the robot flat up against a wall and start your code.

3) After sufficient time to allow a good bias calculation, enable your robot into teleop mode.

4) Rotate your robot 180 degrees and place the robot flat against the wall again (so you ensure your robot rotated as close to exactly 180 degrees as possible).

5) Write down the computed heading.

6) adjust your gyro sensitivity in your code using the following calculation: NewGyroSensitivity = OldGyroSensitivity * ActualRecordedHeading / 180

7) Repeat the procedure until your recorded heading is VERY close to 180 deg.

Last note: we actually use LabVIEW. I can post that as well if you don't do textual programming.

If there are any questions, let me know.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Wow, thanks for posting this!
I'll share this it my team.

What exactly do you mean by the "init function"? Do you mean to put that in Begin.vi? (We use LabVIEW too)
How fast do you run that periodic loop?
And you just reference the gyro heading in tele/auto by using a global variable, right?

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Correct. However, for LabVIEW it's much easier than the C version I posted. You don't need much in Begin.vi other than wire a FALSE into the visitedEnabled global (if you choose to make it a global - we make it global because we use it in a few places).

Download "The Secret Book of Labview v1.0" here and go to page 25 (page numbered 20, page 25 of the PDF) and try to implement the "boxcar filter" - that will be your moving average that you need for your bias calculation.

I don't have the code in front of me, but it's either 5 or 10 ms. We've been doing most of our control code in a 25 ms loop, but we have one really fast loop just for this.

Correct

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Although I have never done this before, I would imagine this only holds true for LabVIEW users. One of the benefits of Java and C++ is that you can change pretty much any of the high level code in the WPILIB. In this case, just extend the gyro class and rewrite whichever part of it calculates the bias.

Edit: There is a convenient int in the Gyro class (Java) called m_center. All you would have to set that variable to voltage of the analog channel at the start of the match. Unfortunately it is set at the default access level without a modifier method, so you would have to extend the gyro class (or just make a slight modification to your version of the WPILIB).

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

It's not quite so easy (in Java at least). The method that calculates the gyro bias is private, so it can't be extended. You have to patch WPILib.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

As I said in my edit, you don't have to modify that code. Just overwrite the m_center variable at the start of the match. Good catch though.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Kind of, but that's not really how the gyro works under the hood. The FPGA onboard the cRIO has a hardware accumulator which can integrate a signal coming from the ADC at a specific sample rate. This is used for the gyro as the timing is really precise and fast. In software, there is a memory mapped interface to the FPGA used to configure and view state on the various subsystems (accumulators, counters, etc.). The code in initGyro does the following:
1) Reset and init an accumulator on the channel the gyro is plugged in to.
2) Wait 1 second
3) Turn on the accumulator
4) Wait 5 seconds
5) View the 'value' of the accumulator (a 64b long) and the count of samples taken to get there.
6) Find the average voltage per sample, set that as the new 'center' for the accumulator.
7) Reset the accumulator

When you ask for an angle reading, it just reads the current 'value' out of the accumulator and scales it to a human understandable value.

m_center holds a local copy of what got written into the FPGA's accumulator as the 'center'. It is just a cached value used to convert the last few average samples on the ADC to a measurement with correct units in getRate. (Remember, the accumulator is doing the heavy lifting for measuring position). Writing to m_center won't really help here.

I don't know why WPILib chose to wait for 5 seconds to denoise the sensor. It seems like this can be done in WAY less samples (like, 10ms).

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

So long as you put your subclass in the edu.wpi.first.wpilibj package you should be able to poke around at the accumulator object, so you can just build a new init method. Which is dumb.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

I don't think drift is all of the problem. This year we used the KOP gyro for autonomous. Drift is no problem for this short period. Back in 2012 we never got an acceptable field centric working. 2 weeks ago the programming team developed field centric code again. Put it on the robot with the kop gyro and with some adjustments in code it works fairly well. Most of the testing was done at low velocity checking rotations and stuff. Yes, there was drift but, not excessive. Would be fine for a 2 minute match. Last wed. The drivers tried the field centric code and when the robot is driven hard the the way swerve should be, The gyro goes nuts. Large 10 15 20 30 40 degree swings in 10 to 15 seconds in both rotational directions. The drivers where practicing figure eights. Had to put robo centric back on for the rest of the night. This has to be some thing other than drift. Acceleration affecting the gyro rate? We have some other digital gyros to test. Just have to figure out and program them into the c-rio. We need a rock solid orientation to use field centric in competition. Is this a swerve issue, how do other teams do it.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Could the gyro have been saturated?

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Just to pile onto a thread that was once about mecanum robots.

The LabVIEW WPILib code is just as open as C++ and Java, and is in fact even easier to modify or use as a template to write your own stuff.

By the way, it is highly likely that the WPILib code will be modified to incorporate better calibration for 2015. The implementation in WPILib is simple, but not entirely incorrect. If your team relies heavily on the gyro, you can better characterize your sensor and customize the calibration to your setup.

Greg McKaskle

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Yes, that's a real thing. I remember seeing a value of 0.2 degrees per second per g of acceleration. That doesn't sound like much, and a properly mounted yaw rate sensor with good mechanical isolation shouldn't give you significant problems. But remember that vibration is also detected as acceleration, and it's possible that having the sensor rigidly mounted to the robot frame can yield false readings when the robot is in motion.

Consider also the possibility that you have an electrical issue. Signal noise picked up from motor wiring on the gyro analog signal will be accumulated as errors in the gyro angle. Make sure your sensor wiring is not running alongside power wiring.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Is there an easy way to do this in LabVIEW?
Or do I have to put something in auto and tele that wires true to the visitedEnabled global?

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Like this:

Actually, we usually just wire a TRUE constant into visitedEnabled in Teleop and our Auto code. That makes it much easier.

(EDIT: Sorry for the issues. The site is having attachment problems. I should be able to post it in the morning unless the site problems persist.)

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Here we go: