We have gone to the module form. If any of our pods fail or are suspect of not performing properly, they are immediately swapped out. Our pit crew can swap a module in < 5 minutes. Repair later. 4 bolts and 3 wire connectors and it’s out. How fast can a mech, West coast drive or any other drive be repaired? I have watched teams struggle with repairs to other drives and like the repair ability of the swerve Modules. For us the goal of our team is not to win but, to mentor and teach our students to work together and accomplish hard technology tasks. 4 driven wheel, independently steered swerve is a good one to teach this. Yes the kids are pushed hard to do this each year. The pay back in their growth is great. Have to say we started to win more after the switch to swerve. To do swerve forced us to develop processes and a mindset to do it. The same processes have help with other aspects of the team. Swerve is hard but for us the pay back has been great.
The swapping is a great point. Have you ever had a module fail in a match? How does yours drive with 1 dead module?
I agree that a swerve is a good way to teach many important skills. I have never been willing to take the risk of doing swerve during the season (if it fails then you’re really in trouble if you can’t drive forward!). What was it like the first year you tried swerve? Did you do a trial run during the off season?
Love where this conversation has gone. Here’s my design thus far.
Before everyone piles on…the prototype will use stuff we have laying around, like the Andymark wheels with the plastic pulleys, and mini cims for steering. It’s just the start.
You could do gears instead of belt or chain.
Check out 973’s iteration of the West Coast Swerve, “Emperor Swerve” & “Encore”. 1717 uses a very similar and much more refined West Coast Swerve.
Thinking about it…but afraid. Trying to keep as much of this in the “comfort zone” as possible. The real goal is to get something that works so we can start figuring out how to program it all - that is frightening!
Teams are always focusing on the mechanical and programming aspect of swerve. You can design and create a perfect swerve and nail the programming.
Guess what, your only half way there. Teams forget the human part of this system. Control presentation and driver training are just as critical. You also have to be prepared to devote as many resources to your drivers.
In our case, it is not that we are neglecting the importance of driver training…but this project is a sequential endeavor…we can’t program until we have something built mechanically, and we can’t train until it is built and programmed. Right now we’re trying to get something built - everything else comes afterward. Knowing my team’s strengths and weaknesses, though, the programming is going to be our most difficult part by far.
For programming start with Ether’s paper on the kinematics of swerve. Several teams have published their code. You have to understand the mechanical and sensors to follow the code. Big choice is incremental with indexing or absolute encoders. Big difference in the steering algorithm. Also, your programmers must understand and embrace the principles of real time-- data flow methods. You will have a good bit of code running just for the swerve. For other mechanisms on the robot the the efficient execution of those blocks of code is critical. Your team should master a fundamental knowledge of state machines. We had problems our first year. Our swerve worked OK at home. Went to the finger lakes regional and had bad FMS lag. Our robot several times did what our team calls the happy dance. Steering goes wild. To me it looked like a grand mal seizure. We did not give up and have been driving forward ever since. Make sure your team is ready for problems and are ready to not hit a home run the first time. Are you willing and ready to make a long term commitment to perfect it? If not then basic tank drive what ever the wheel configuration can take you far.
I would be extremely cautious about that drive belt ratcheting given the small amount of wrap on the tiny top pulley.
Also 9 mm pullys may not handle the thrust at that end of the gear redction. Belts like high speed over high tourqe.
Our swerve design is somewhat similar to this. We use gears, though, and it’s been working nicely.
For my team, even with one programmer (myself), the code was quite manageable with the assistance of some papers/presentations.
But I must admit, debugging errors in the code got pretty annoying.
Thanks everyone for the great responses:
I am a bit worried about this.
That’s the kind of information I was looking for. I may make the module a bit wider and use a 15 mm belt here - at least for the prototype.
Gears between the bevel and the wheel is something I had not even considered…I like that idea.
I’m heartened that the programming was manageable. It is my biggest fear.
Definitely use 15mm rather than 9mm belt, and if possible make the top pulley larger and change the ratio from the CIM to the coaxial drive shaft to account for it. Or, as mentioned, use gears; they’re heavier, but have fewer failure modes. Switching to VexPro VersaWheels would make gear-mounting a breeze (in fact, they now even have gears with 9/8’’ bearing holes so you can keep it dead-axle).
We did a project in 2008-2009 and created a paper and did a presentation at the CHP. Some of the technology has changed and improved, but the basics are the same.
We use purchased modules. For our competition robot, we paired the front wheels together and the rear wheels together for rotation. Even with this “simpler” design we worked the entire fall season before deciding to use the design on a competition robot.
These documents might help.
How are you attaching the vertical tube with the hex bearing to the U structure that holds the wheel? A cross section view might help. Also, if you are using a MiniCIM for turning you are going to need something like a 50:1 reduction, thats pretty hard to get with 1 stage of belt or chain.