pic: Team 2220's Swerve Drive Chasis

[Jedward45]

loading photo ...

[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/...ming-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]

Originally Posted by JesseK

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]

Originally Posted by Ether

@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]

Originally Posted by 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.

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]

Originally Posted by Chris is me

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]

Originally Posted by Chris is me

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]

Originally Posted by Ether

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]

Originally Posted by Chris is me

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! (hoohoohoo emoticons!!!) From what I understand, Swerve is very difficult to build and use! I hope it works well for you guys!