pic: Team 2220's Swerve Drive Chasis

[Jedward45]

[cdm-description=photo]36030[/cdm-description]

[JVN]

Hey,
Good start! Just a friendly word of warning: a swerve drive takes a LOT of effort to get right, especially on the first try. You WILL spend most of the season fighting this design to get it running right, and to keep it running right. You'll spend so much time fighting with it, your driver won't get to use any of the advantages a swerve drive would provide... I promise you this.

I BEG you to not try to use this design without building it in the pre-season and testing it. If you're putting lots of resources (effort) into your drivetrain you're not going to have as much effort available for your mechanism -- the mechanism is where the magic is, and what makes you successful on the field.

Build a simple, reliable, drivetrain, and spend your engineering on the rest of your robot. You'll be much happier. If the summer comes along and you still want to build a swerve drive, try it then.

If you don't have the resources to prototype it in the summer, you might not want to be attempting it anyways. Again, we all have limited resources during the build season -- spend the ones you have on things that will have the biggest payoff...

$0.02
-John

[Justin Montois]

^^ That. Just that.

[Jedward45]

Thanks for the feedback! We have already prototyped the module and found really no problems with it. The big question mark will be attaching the lateral drive and rotational chains. However, we have the resources to build multiple chassis, so we have some room for error. We also built a failsafe into the design. If we cant drive the modules w/swerve, we can lock their positions and drive standard tank.

[Al Skierkiewicz]

From the inspector in me, in looking at the base construction, I think 'what a great place for bumpers'. However, if you use this as a design basis, please double and triple check the bumper rules and FRAME PERIMETER definition if it returns this year. If in doubt, please ask the Q&A after kickoff.

[JesseK]

I too like the I beams as use for a frame -- very creative!

From a maintenance standpoint I would make some strategic holes in the I-beams so you can see what's going on inside the modules in the very likely event of a problem.

To solve the frame perimeter issues (based upon previous years' rules), some stiff foam or lightweight plywood would fit nicely into the I-beam rails.

I'll also echo John's sentiments, yet also add to it that programming a crab drive is just as difficult as building it. Hopefully you have very, very talented programmers since they've probably only seen un-optimized or theoretical code.

[imac256]

That does appear to be a very nice system you guys have designed, but my question is have you guys figured out how you are going to control it and place the sensors on the wheels? A swerve drive needs the sensors to operate and their positioning can be somewhat tricky and has to be designed for.

As for coding a swerve drive, it took my team about a week straight to perfect our swerve drive code, and at least another week of testing before it was stable enough for the drivers to really use, and during that time the frustrations were high. Be sure to give the base to the programmers at least half way through the build time, because trying to program this with people breathing down your necks is not fun. I speak from personal experience there, our 2009 and then our prototype 2010 robot were both swerve drive.

If you guys would like some examples of swerve code, it isn't very nicely structured, our old code is here:
http://coolhub.imsa.edu/cybercollab/web/robotics-documentation/programming-documents
If you have any questions regarding that code send me a PM and I'll try to help

- Ian McInerney
Lead Programmer, Team 2022

[Ether]

I'll also echo John's sentiments, yet also add to it that programming a crab drive is just as difficult as building it. Hopefully you have very, very talented programmers since they've probably only seen un-optimized or theoretical code.

@Jedward45: Are you planning to rig this up as a crab, or do you plan to have independent drive and steering for all 4 wheels?

[Jedward45]

@Jedward45: Are you planning to rig this up as a crab, or do you plan to have independent drive and steering for all 4 wheels?




Yeah, were chaining together via three links the outer rotational sprockets... We still haven't decided on which motors to use for this as our CIMS are all tied up... Were planning on building two drives trains, one to keep behind for programmers.....

[Chris is me]

Thanks for the feedback! We have already prototyped the module and found really no problems with it. The big question mark will be attaching the lateral drive and rotational chains. However, we have the resources to build multiple chassis, so we have some room for error. We also built a failsafe into the design. If we cant drive the modules w/swerve, we can lock their positions and drive standard tank.

Just remember - mechanical is half the battle. More like a third.

A third is control. Swerve is by no means intuitive to control.

A third is driving practice - swerve is not intuitive to drive no matter how you code it, so your driver needs a lot of time to get used to it for it to really show its advantages.

(Also, the biggest mechanical challenges of swerve come once the module is attached to a full chassis)

[Ether]

swerve is not intuitive to drive no matter how you code it

I'm not convinced this is true. It seems to me that, with smart enough software, swerve (of the Unicorn variety anyway) should be almost as seamless in its motions as a well-designed mecanum... and without the traction disadvantages of mecanum.

[Jedward45]

Just remember - mechanical is half the battle. More like a third.

A third is control. Swerve is by no means intuitive to control.

A third is driving practice - swerve is not intuitive to drive no matter how you code it, so your driver needs a lot of time to get used to it for it to really show its advantages.

(Also, the biggest mechanical challenges of swerve come once the module is attached to a full chassis)

Respectfully disagree, we are planing on using gyros to allow absolute direction, so theoretically you could point the joystick to you right, and the robot will go that directions regardless of current orientation.... While this is still just an idea, remember we have a month after the build season to tweak our programming and give drivers practice

[Chris is me]

I'm not convinced this is true. It seems to me that, with smart enough software, swerve (of the Unicorn variety anyway) should be almost as seamless in its motions as a well-designed mecanum... and without the traction disadvantages of mecanum.




This is based on my experience driving a non-Unicorn chassis, yeah. Moving a tank drive robot with robot-centric controls is trivial. A swerve, absolutely not, especially if you are responsible for module rotation.

My "ideal" swerve would have a field centric "point the modules this way" stick and a robot centric everything else... I think.

[artdutra04]

A third is driving practice - swerve is not intuitive to drive no matter how you code it, so your driver needs a lot of time to get used to it for it to really show its advantages.Field centric controls on an independent swerve or mecanum drive are probably the most intuitive form of joystick-based driver control there is, especially if you use a three-axis joystick.

[Superllama12]

That is quite impressive! :yikes: (hoohoohoo emoticons!!!) From what I understand, Swerve is very difficult to build and use! I hope it works well for you guys!

[Ether]

My "ideal" swerve would have a field centric "point the modules this way" stick and a robot centric everything else... I think.

My ideal swerve would have field-centric Halo-style interface (http://www.chiefdelphi.com/media/papers/download/2855) with a pushbutton to align the bot in the direction of motion a la item #4 of this post (http://www.chiefdelphi.com/forums/showpost.php?p=987373&postcount=25).

[indubitably]

My ideal swerve would have field-centric Halo-style interface (http://www.chiefdelphi.com/media/papers/download/2855) with a pushbutton to align the bot in the direction of motion a la item #4 of this post (http://www.chiefdelphi.com/forums/showpost.php?p=987373&postcount=25).




We had this last year as well and ended up switching back to a robot centric control because it was easier to drive directly toward the ball collector that way.

[gren737]

Hey,
Good start! Just a friendly word of warning: a swerve drive takes a LOT of effort to get right, especially on the first try. You WILL spend most of the season fighting this design to get it running right, and to keep it running right. You'll spend so much time fighting with it, your driver won't get to use any of the advantages a swerve drive would provide... I promise you this.

I BEG you to not try to use this design without building it in the pre-season and testing it. If you're putting lots of resources (effort) into your drivetrain you're not going to have as much effort available for your mechanism -- the mechanism is where the magic is, and what makes you successful on the field.

Build a simple, reliable, drivetrain, and spend your engineering on the rest of your robot. You'll be much happier. If the summer comes along and you still want to build a swerve drive, try it then.

If you don't have the resources to prototype it in the summer, you might not want to be attempting it anyways. Again, we all have limited resources during the build season -- spend the ones you have on things that will have the biggest payoff...

$0.02
-John


^^^ Take it from another mentor this is very good advice! ^^^

[Jedward45]

^^^ Take it from another mentor this is very good advice! ^^^

Indeed, but I disagree with the idea that the manipulator is where the magic is. Our team has had bad experiences with an immobile tank drive and a subsequently useless manipulator. Furthermore, the manipulator becomes obsolete after a year. The development of a swerve drive can out your entire team on another tier. But only time will tell!

[Gdeaver]

Swerve or six wheel drive? That is the question that our team battled tonight. Swerve won. I notified my wife tonight that she may not see me much for the next 6 weeks. This is going to be a very stressful and crazy build. If we pull off our design goals we will have one awesome robot. If we fail we will fail horribly. The programmers have go fever. We'll see how the are in week six and seven and eight...

[jethrow]

swerve drive is harder then you think do not rely on chains.::rtm::

[Racer26]

1075 did a 2+2 swerve configuration for the last two years (for the 2010 FRC season we designed and built DSSwerve, AFAIK to date the ONLY FRC bot with invertable swerve drive)

Swerve is hard to do well. Our 2010 incarnation of swerve worked fairly well, but we had a driver with 4 years of FRC experience, and our 2010 DSSwerve was derived from our 2009 Swerve.

2010 DSSwerve suffered from throwing chains, bending swerve modules via side-loading when being pushed, and more. The worst part about building a swerve system is that the mechanical complexity of the system makes repairing failed parts significantly more difficult, and can often result in needing to disassemble large portions of the robot, depending on which part has failed.