Swerve Drive vs Mecanum Wheel drive?

[BBray_T1296]

Originally Posted by efoote868

similarly with 2012 ("can't balance on the bridge!").

Though this is the practice ramp (only pic I have on me) we could quite easily

Also 2012 bump? no problem

I loved our mecanum robots, they worked really well.

They work an unbelievably better when controlled by encoders and PID as well, the only reason we stopped using them is because we hate getting ruled off scouting lists for no reason but them, even though in 2011/2012 we pushed so many robots you would not even imagine.

And mecanum is really light. in 2012 and 2011 we used ToughBox nanos with the output direct driving the AM 6" wheel. Any 4 CIM chain tank drive is going to weigh just as much. Also they take up almost no space (note our 4 sided intake!)

[RoboChair]

Originally Posted by BBray_T1296

the only reason we stopped using them is because we hate getting ruled off scouting lists for no reason but them

This is another reason mecanum can suck, because of the number of teams that don't utilize the full benefits of the drive most competitive teams will cross you right off of pick lists. You have to SHOW that you can rock it well with some epic driving to avoid that fate(this is one of the things 1678 looks for when scouting).

[efoote868]

Originally Posted by BBray_T1296

Though this is the practice ramp (only pic I have on me) we could quite easily

Also 2012 bump? no problem

Popular belief was wrong, and there weren't many teams to challenge assumptions.

Even the belief that swerve drive done correctly is always better than mecanum drive done correctly is misguided. The teams that use swerve drive year in and year out effectively tend to have great organizations along with better than average resources. I'm not convinced these team's competitiveness entirely derives from their drive train. Likely they'd be just as successful with a 4/6/8 wheel tank drive, a mecanum drive train, or some other drive train.

[blaze8902]

Personally, I like both Mecanum and Swerve. However, my team decided that we weren't really looking to make a swerve drive due to the resource and experience concerns. Instead, we went with a modified octanum drive. With butterfly modules comprised of mecanum and colson, we feel as if we have achieved a similar performance to Swerve, but without several of the sacrifices.

When considering drive trains, you must consider everything. Do not make a hasty decision whilst either scouting or building. I suggest looking up 1114's drive train documentation. Implementing a system that allows for decisions based off of quantitative data enables a team to make intelligent choices.

[Johnnybukkel]

Team 174 Arctic Warriors do belt driven swerve drives every year. It's honestly ridiculous if you get a chance to see it but it works well and it's really cool.

[zinthorne]

I have never personally seen a swerve drive in person, but only in videos. This is the first year that my team has used mecanems. We decided that we also wanted to develop a new drivetrain to go with it. It is sort of an octanum drive base. We used 4 4" mecanem wheels and 2 six inch traction wheels. We have gone through 2 district events and gotten second in one. The first event we got pushed around a decent amount, but in the second, we got pushed around less as we got better driving. The traction wheels also allow us to play some pretty good defense too. The choice that teams make between tank, mechanems, and swerve should be based on their desired strategy that year. I have found mechanems to be the greatest wheels i have seen when lining up for the one point goal. Since they can "drift" it makes it easy to drive up quickly, and then move side to side to put the ball in quickly. I have seen numerous teams have to line up multiple times when they try to get the ball in.

[ratdude747]

Originally Posted by efoote868

2008 didn't lend itself to mecanum drive trains (successful robots were geared 18fps+ with 2 stage transmissions).

To be fair, one of the finalists on curie in 2008, 2171, was running mecanums. And IIRC they were actually using them as well (to weave through traffic).

[Ben Wolsieffer]

Originally Posted by efoote868

2010 a large segment of the teams automatically ruled them out ("can't traverse the bump!"), similarly with 2012 ("can't balance on the bridge!").

As a mecanum lover, it really annoys me when people automatically rule out mecanums when the really don't know what they are capable of. Our robots in 2010 (http://youtu.be/rdAKiuimaY4?t=58s) and 2012 (http://youtu.be/tdAncHeHOEQ?t=1m36s) had mecanums and they could traverse the bump and balance on the bridge.

Originally Posted by RoboChair

Mecanum if done well, geared for agility, and absolutely programmed FIELD CENTRIC and then practice the hell out of it can be a very competitive drive train. Anyone that does not put in the effort to code and set up a mecanum drive for field centric is wasting their time. I have seen many teams drive mecanum like a tank drive with only the occasional strafe/rotation and this is a waste of time. You can dance across the field dodging defense all day if you can just move the stick and your robot moves that way on the field no matter where it is pointed. But if defense catches up to you that's it, you must be faster! Mecanum shouldn't really even have a tank style drive mode.

I especially agree with this. In past years we have driven our mecanums mostly as arcade drive and with crabbing at the press of a button. You can see the ineffectiveness of this in our video from 2012. This year though, I implemented a really cool (in my and the judges' opinions [we won the Innovation in Control Award for it at two districts]) field oriented drive mode that we use exclusively. I read about the idea on CD and decided to implement it early in the build season, so we had a lot of time to practice with it. Even though we aren't extremely powerful, we are agile.

Originally Posted by Chadfrom308

On each wheel, we have a toughbiox mini with 1 big CIM and 1 min CIM. (Yes technically we have an 8 CIM drive)

This allows us to accelerate crazy fast, which helps with all the defense,

Programming wise, we have 5 PID loops on our drivetrain. I'm not a programmer, but how I think we set up the PIDs is the based on rpm from each wheel, us telling the PID how fast it should be going. We have 1 PID on each wheel, and one for rotation. It's cool because you can push our robot and it will push back with independent power on each wheel. And speaking of pushing, that's how we play defense (sometimes). We sit in front of a robot and step away from the controls and it does the work (mostly) by itself.

That sounds really cool. I was thinking of using PID loops and encoders this year but I decided it was just easier to use a gyro to maintain our orientation if we were pushed and to correct for traction or weight imbalance problems, mostly because we have had bad experiences with encoders failing in the past. I might try that along with extra miniCIMs in the offseason.

[Ether]

Originally Posted by lopsided98

This year though, I implemented a really cool (in my and the judges' opinions [we won the Innovation in Control Award for it at two districts]) field oriented drive mode that we use exclusively. I read about the idea on CD and decided to implement it early in the build season

Is there something unique about the way you did it?

Field oriented control has been around for a number of years. It's built-in to LabVIEW and WPILib for Java and C.

[Chadfrom308]

We have actually never had any problems with our encoders, even when one broke, the rest of the PIDs made up for it.

As for Field Centric, we never used it. It is way faster to do robot centric.

85% of the time, we don't use the strafing feature of the mecanums. But, the most important 15% we use them. (Like lining up the 1pt goal and lining up for inbounding)

And that has made it worth while

[Ben Wolsieffer]

Originally Posted by Ether

Is there something unique about the way you did it?

Field oriented control has been around for a number of years. It's built-in to LabVIEW and WPILib for Java and C.

It's most unique aspect is that it could automatically correct its orientation when we were pushed or lost traction on a wheel, which made our system much easier to control than it would have been without it and it allowed us to travel in an absolutely straight line, unlike it the past where going sideways often went in an arc instead. This prevented us from needing to be so obsessive about weight distribution, because we could just let software fix our problems.

[Ether]

Originally Posted by lopsided98

It's most unique aspect is that it could automatically correct its orientation when we were pushed or lost traction on a wheel, which made our system much easier to control than it would have been without it and it allowed us to travel in an absolutely straight line, unlike it the past where going sideways often went in an arc instead. This prevented us from needing to be so obsessive about weight distribution, because we could just let software fix our problems.

Share the technology: write a paper!

Originally Posted by lopsided98

I read about the idea on CD and decided to implement it...

... and give credit where credit is due

[Ben Wolsieffer]

Originally Posted by Ether

Share the technology: write a paper!



... and give credit where credit is due

I don't have time to write up about it at the moment but I probably will during the offseason. For now, here is the code for it if anyone is interested in looking at or adapting it for their own use: https://github.com/RobotsByTheC/CMonster2014.

I would tell where specifically I got the idea from on CD, but I don't really remember anymore.

[ekapalka]

Originally Posted by BBray_T1296

They work an unbelievably better when controlled by encoders and PID

I've heard that PID control begins acting unusually when you have a constantly moving setpoint because the tuning parameters were only set for one particular speed. Is that not so, or has your team found a way to work around this (such as a lookup table for different setpoints)? My team never really got around to putting encoders on our wheels, and as a result wound up tediously multiplying each wheel by a particular constant depending on its direction (because our motors have a 20-30% speed bias in a particular direction), which was a pain to figure out through trial and error.

Originally Posted by lopsided98

I don't have time to write up about it at the moment but I probably will during the offseason. For now, here is the code for it if anyone is interested in looking at or adapting it for their own use: https://github.com/RobotsByTheC/CMonster2014.

I've been tentatively skimming through this code for around half an hour and can't seem to find where the magic happens... I'm not particularly accustomed to the command based model :P Could someone point me in the right direction? Thanks!

[Joe Ross]

Originally Posted by ekapalka

I've been tentatively skimming through this code for around half an hour and can't seem to find where the magic happens... I'm not particularly accustomed to the command based model Could someone point me in the right direction? Thanks!

src/org/usfirst/frc2084/CMonster2014/commands/FieldCentricMecanumDriveCommand.java