pic: Team 2451 Pwnage

There was a prototype of this module in from of 2451’s pit last year, and I was impressed then. Seeing how it performs in competition is absolutely amazing!

These sure look compact. What is the weight per module? How big is the foot print it takes up in the frame?

I always assumed that a swerve like this would take more square inches, but would weigh less.

Do you guys press a ring into the Colson to reinforce it, or do the six rods that join the hub halves just go through rubber?

Do you have a cage for the nylon balls in the thrust bearing part of the module, or do you just let the balls go where they will? Can you tell me how many balls you use in the thrust bearing?

You will rarely, if ever notice the limited 330 degree motion of the swerves. After we got our drivers used to the fact that they were driving a swerve, we made them aware of the hard/dead stops as we call them (the “nubs” on the bottoms of the gearbox covers and the plates mounted to the outsides of the plates the modules turn on) and created a training program around the fact that the swerves do have that limitation.

While we have both the tooth counters and the absolute encoders on the modules, we currently only use the absolute encoders in the code.

I can’t give you an exact number, but we essentially dedicated a week to machining swerve parts. They were very labor intensive, but the rewards far outweigh the time we gave to create the swerves. Just as Nick said earlier, we would not survive without Genesis Automation, and one of the countless benefits of having them as a sponsor is being able to use their machine shop which consists of two ore more of almost every machine you could ever need including five Bridgeport 2-axis mills, two CNC machines, a manual lathe, and a CNC lathe to name a few.

Our next meeting is on Tuesday, so we’ll be able to get back to you on that then.

We haven’t done much of any kind of testing on those holes acting as a fan so I can’t really answer that accurately, but those holes are primarily there to take weight out of the modules.

However, the hubs do absorb some of the heat created by the CIMs, so they are cooled in a way (again, we haven’t done much testing on that other than ‘hey, these things do warm up’), which we kind of anticipated when the swerves were still in the design phase.

Right now each module weighs right around 7.5 pounds. If you were to put one of the modules in a box you’d need a 7.5 x 7.5 x 6 or 8 x 8 x 6 inch box (6" is the height). We can and do intrude on that theoretical box in our current chassis, so the foot print is really a dome of sorts from the plate the module revolves around up.

I’m not entirely sure what you’re asking so let me know if I need to clarify. There isn’t a ring pressed into the Colson, but the hubs do have a little lip on them that extends into the hole machined into the Colson that the CIM goes through. The threaded studs that form a hex pattern around that hole in the CIM are just pressed into a hole drilled into the Colson and they self-align as you start tightening the bolts that hold the hubs onto the Colson.

I’m not entirely sure what you’re asking, but I’ll try to answer as best I can. We do not trap each of the 80 individual balls, but we do have a groove cut into both the top side of the gear and the bottom side of the plate the module revolves around. So the balls are forced to move in a circular path in the grooves we call raises. Let me know if I need to clarify.

Just a little more about the durability of the modules them selves, on our practice bot they have seen well and above their competition lifespan. Somewhere in the ball park of 10 or 20 times that of the competition bot, and for all practical purposes they run the same as the ones on the competition bot. The modules have seen numerous high-speed impacts both in competition and in practice. As mentioned in the Midwest Regional Thread, the modules also withstood an entire day of 3-on-3 in game scenario practice that we participated in thanks to the generous folks at 1625 in which we had the alliance facing the 1625/2338/2451 practice bots dedicated to heavy, in-game style defense.

How do your drivers control it? Could you explain the code a bit? What did your team do to overcome the “180 degree problem” described in the first comment in this thread?

Just a forewarning I did not code our swerves, but I do understand (for the most part) how the code works. The majority of the code was written by a junior on the team who basically immersed himself in all things swerve once we actually started fabricating our first modules. With that said I’ll do my best to answer your question.

We have three joysticks on the control board, but only two joysticks (the main driver’s left and right stick) control the swerve. The left stick controls the direction the wheels are facing for translating as well as the speed the robot is moving at. The right stick causes the robot to pinwheel (turn in place) by both orienting the wheels to be tangent to the circular path it is moving about as well as controlling the speed of the wheels as the robot turns. When you manipulate the two joysticks in parallel one of the speeds (I believe the greater of the left and right stick) takes precedence, and depending on your manipulation of the joysticks, allows you to preform maneuvers such as sweep turns, pirouettes, etc. Any time you take your hands off the sticks or let the joysticks return to their “zeroed-out” position, the wheels return to their original orientation of facing straight forwards relative to the robot.

As far as the “180 degree problem,” I’m assuming you’re asking about the “dead zone” and minimizing “bad behavior”

We don’t really minimize the “bad behavior” of the swerves. We mainly just address the “dead zone” issue. The pseudo-code for overcoming the “180 degree problem” looks something like ‘if the module rotates too far towards the dead stops (or “dead zones” as Ether calls them), rotate the module 180 degrees away from the dead stop and reverse the driving direction of the wheel.’ Essentially if we were to try to make it preform a maneuver that required more than the 330 degrees provided, such as pirouetting continuously, every so often the robot would have a slight pause in its motion while the modules realigned themselves.

One thing that 2451 had at Midwest was a simulator / game that ran the swerve control on a laptop and allowed people to practice driving. I believe they even had a head to head “for fun game” set up that made practice competitive. Super cool and very nice to see the software-in-the-loop concept being taught to high school students! I wonder if they could release a hard-coded version of the game so people could try their hand at driving…!?

And I’ll toot their horn a little more for them, they won the Engineering Excellence award for this design at Midwest…!

Importing the step file currently at http://www.pwnagerobotics.com/index.php/doc-list/public/23-swerve-drive causes my installation of Solidworks 2013 to hang. It seems to be getting through the step solid import, but sits and spins after writing “step-in completed” to error out, which I guess is just before it puts together the assembly. Anyone have an idea what’s happening? Any suggestions?

I’m not entirely sure what’s happening on your system, but generally when I try to open a step file larger than 40 meg I restart my computer, set the performance settings to high, set SolidWorks as high priority in the task manager, and kill all non-essential processes before attempting to open the step file in an attempt to allocate as many resources to SolidWorks as I can. I’m not sure if this will help in your situation, but it should at least give you a starting point. If you’re getting an error message, try to take a screen shot of it and post it. We might be able to help you better if we can see what’s going wrong.

No error message, just Solidworks stops responding after a while. The step error log just says that each part was successfully imported, ending with the line “STEP-in completed.”

Whenever I get around to booting Windows next I’ll try upping the priority on the process. Have others had success importing this particular step file?

I just checked one of my error logs and ours seem to match up. It usually takes a couple of tries to get larger files to load, so be prepared to give it a couple of tries.

I’ve gotten it to open on a machine running an i3 with 4 gb of ram at my high school that was running Inventor as well as on my laptop with an i7 and 8 gb of ram running SolidWorks.

Killing lots of NI, Google, and other stuff and upping the priority worked (with a little bit of a wait) on my i7 quad w/ 8 gig. It’s been a while since I’ve cleaned up my Windows side…

Thanks for the tips!

Glad to know it worked for you. Any time you open a STEP that was originally an assembly there’s going to be some kind of wait. I think the longest I’ve ever had to wait was 20-30 minutes for one of the Robonauts’ masterpieces to load.

If there’s anything else you need help with please don’t hesitate to ask.

The files seem to open fine on my computer.
i7 4930k @ 4.7ghz
32GB of Ram
EVGA GTX 780ti

Hey it seem the CAD link no longer works. Does anyone have a stored version or an alternate link they would be willing to share with me?

hey, i am extremely interested in your design but the lind for the cad is no longer working. could i have the files? that would be awesome. Thank you

Sorry about this. I’m going to work on getting the file available in a google docs folder. I’ll update when it’s there with a link.

Until I get that set up if you go to our websitehere and scroll to 2014 there is a tech notes that has a lot of detail about the mechanical design and a ton of good information about how the programming was done.


Try this link, it has three different swerve designs, our battery cart and a Solidworks configurable Vex Versaplanetary gearbox with single stage, double stage, choice of motors, dual motor and all available output shafts.

New File Location