pic: Team 2451 Pwnage

[Kevin Ainsworth]

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

[Jibsy]

This looks really nice! I remember when I first saw the CIM in wheel idea... took away the clunky look that I always found swerve modules to have.
Importing the STEP file into SW right now to take a better look. How did it hold up/perform through competitions so far? Do you have any video/more pictures?

[SpaceOsc]

work of art:D

[Kevin Ainsworth]

We didn't have a single issue with it at the Central Illinois Regional.
http://www.thebluealliance.com/match/2014ilil_qf4m1
Check out the impact we deflected with 58 seconds left.
I just uploaded a technical paper one of our students, John Duffy, wrote about Team 2451 Pwnage 2014 swerve drive. There are many additional pictures that John created, exploded views, section views, etc. There is also additional specifications and descriptions for your viewing pleasure.

[pwnageNick]

So proud to be an alum and now mentor of this team, and all of the great work the students have put into this years robot. We knew it was going to be tough to execute the swerve drive this year with it being our first competition swerve but they did a fantastic job. If you can, I suggest taking some time to take a look up close at the Midwest Regional this weekend, or hopefully St. Louis in a couple weeks.

-Nick

[s_forbes]

Awesome module, I'm amazed that you've somehow managed to pack everything into an even smaller space than the Nutrino's design from 2012!

The gear teeth look pretty clean cut in this image, how did you guys manufacture the gear for rotating the module and the ring gear reduction for the wheel? Also, will this be in St. Louis this year?

[pwnageNick]

Awesome module, I'm amazed that you've somehow managed to pack everything into an even smaller space than the Nutrino's design from 2012!

The gear teeth look pretty clean cut in this image, how did you guys manufacture the gear for rotating the module and the ring gear reduction for the wheel? Also, will this be in St. Louis this year?

I'll let Kevin or a student answer your question about the gears, but I can tell you that the team is not currently qualified for STL. The team were quarter-finalists at Central Illinois, and will be competing this weekend at Midwest (so fingers crossed).

-Nick

[Joey Milia]

Wow...I love it

I was a bit skeptical of the delrin rollers as bearings when I first saw it but now that I've read your reasoning I love them.

This makes me wish 192 had started swerve earlier...

[ekapalka]

Do you have any close-up videos of it in action? Or a picture of it from the top? I know you provided the CAD file, but (to me) it's not quite as awe-inspiring as the photograph :P

[Aren_Hill]

Awesome module, I'm amazed that you've somehow managed to pack everything into an even smaller space than the Nutrino's design from 2012!


It's actually a bit bigger diameter than the Neutrino one :p

But the slight size increase was for features that are definitely worth it from a reliability/quality standpoint.

I'm very happy they chose to make it as it is a very cool example of what can be done.

Good luck at Midwest to 2451.

-Aren

[eddie12390]

I'll let Kevin or a student answer your question about the gears, but I can tell you that the team is not currently qualified for STL. The team were quarter-finalists at Central Illinois, and will be competing this weekend at Midwest (so fingers crossed).

-Nick

You're required to qualify so that I can get a look at them in real life :p

[RoboAlum]

As a kid who grew up using 71's crab drive, and seeing how big and clunky our drive was this module is amazing I wish I would of went to Midwest this year just so I can see this thing in person.

[Bryce2471]

I love the low look of these swerves, I curious if you have trouble with tangling your wires. Does your software know when to unwind the swerves? How long does that take?

Our team did a non coaxial crab drive a few years back, and we didn't enjoy it very much. This year we did our first independent coaxial setup.

[pwnageNick]

I love the low look of these swerves, I curious if you have trouble with tangling your wires. Does your software know when to unwind the swerves? How long does that take?

Our team did a non coaxial crab drive a few years back, and we didn't enjoy it very much. This year we did our first independent coaxial setup.

I'll answer this, as most of the team will be busy for the next few days and may not have time to answer. The modules have somewhere around 350 degrees of freedom on their rotation. There are hard stops to ensure that the module does not rotate past those 350 degrees in either direction so that the wires do not become tangled. However it is included in the code and the modules will automatically rotate the opposite direction 180 so occasionally it has a slight delay but due to the gearing on the banebot that rotates the module, it does this very quickly and doesn't effect driving too much. This is also a reason the drivers have been given so much practice time.

If slip rings were installed on each of the modules, then coaxial performance would be possible, such as the ones Bomb Squad uses this year. Up until they posted the info about theirs, we had trouble trying to find a slip ring module available on the market that was rated for the right specs and was not giant or extremely heavy.

We actually manufactured our own slip ring (http://www.chiefdelphi.com/forums/showthread.php?t=110126&highlight=slip+ring+2451) last year and while Al from 111 and Head Inspector said it would perform fine and he would pass it, there are no custom electrical systems allowed on an FRC bot, and it even uses custom slip rings as an example. Maybe one day they will revise that rule. Probably not though.

-Nick

[Bryce2471]

I'll answer this, as most of the team will be busy for the next few days and may not have time to answer. The modules have somewhere around 350 degrees of freedom on their rotation. There are hard stops to ensure that the module does not rotate past those 350 degrees in either direction so that the wires do not become tangled. However it is included in the code and the modules will automatically rotate the opposite direction 180 so occasionally it has a slight delay but due to the gearing on the banebot that rotates the module, it does this very quickly and doesn't effect driving too much. This is also a reason the drivers have been given so much practice time.

If slip rings were installed on each of the modules, then coaxial performance would be possible, such as the ones Bomb Squad uses this year. Up until they posted the info about theirs, we had trouble trying to find a slip ring module available on the market that was rated for the right specs and was not giant or extremely heavy.

We actually manufactured our own slip ring (http://www.chiefdelphi.com/forums/showthread.php?t=110126&highlight=slip+ring+2451) last year and while Al from 111 and Head Inspector said it would perform fine and he would pass it, there are no custom electrical systems allowed on an FRC bot, and it even uses custom slip rings as an example. Maybe one day they will revise that rule. Probably not though.

-Nick

Thanks for the quick response. I like your simple code solution, and it looks to not make a large difference in your driving performance. Do you use drive encoders? Sense your already raping wires anyway, it seems like it might be worth it for you guys.

I'm also curious if you give me an estimate amount of time spent on machining and assembling all those custom parts. we spent quite a bit of time on ours, and they only require five parts to be cut on the CNC mill.

[pwnageNick]

Thanks for the quick response. I like your simple code solution, and it looks to not make a large difference in your driving performance. Do you use drive encoders? Sense your already raping wires anyway, it seems like it might be worth it for you guys.

I'm also curious if you give me an estimate amount of time spent on machining and assembling all those custom parts. we spent quite a bit of time on ours, and they only require five parts to be cut on the CNC mill.

To answer your encoder question:

Numerous redesigned elements and upgrades during the season included revised dead stops, cooling vents that force airflow over the motor, altered mounting plates, absolute encoders and encoder mounts for turning, new gear-end plate to cover the shaft and gears, added encoders to the CIMs themselves, magnetic tooth counters on the gear.

So magnetic tooth counters were mounted to measure the speed of the wheels. There is an encoder mounted above the wheel mounted to the banebot motor assembly (which you can see in the CAD image) which measures the rotation of the modules.

As far as an estimate of hoe much time was spent on machining, I can tell it was a lot. I cannot give a good estimate hour wise, so I'll leave that for Kevin or a student, but we work at a company called Genesis Automation who we would not survive without and have access to CNCs, quite a few mills, lathe, bandsaw, etc.

-Nick

[CENTURION]

Wow, this is really something guys. Great work!

Any chance we could get a few more of those sweet, sweet, hi-res photos? The CAD really isn't doing the rest of it justice.

Do those holes in the hubs create any sort of airflow to the CIM (sort of like a fan?)?

Not to derail too much, but can you talk a bit about your frame? Am I correct in thinking that it's basically VexPro Versaframe, but with the world's mos insane bellypan?

[pwnageNick]

Not to derail too much, but can you talk a bit about your frame? Am I correct in thinking that it's basically VexPro Versaframe, but with the world's mos insane bellypan?

I can speak about the frame. The team basically designed the bottom level first out of the 1x1 VersaChassis tubing to easily mount the modules to the frame. By making the 3x3 looking grid type pattern, this made the tubing surround the large gear for pivoting which we like to protect it, and it still allowed for plenty of ground clearance, not that much was needed for this year.

I wouldn't say the bellypan is that crazy, it basically just covers the bottom of all the tubing to anchor it together. Then a second layer of the same tubing layout was put above the first, with vertical pieces connecting them around the perimeter of the frame. The middle two rails on the upper level were upgraded to 1x2 VersaChassis tubing because they had a lot mounted to it and the team felt it best for that area to be stronger.

Other then that the frame is just some sheet metal brackets to tie the whole thing together with rivets.

Let me know if you have more questions.

-Nick

[magnets]

This is for sure the coolest part I've seen all year, and is quite possibly my favorite robot mechanism ever. This makes swerve's weight and space more reasonable. I spent the last 30 minutes going through the CAD drawing.

A few questions-

How did you guys make the gears? Was it wire edm/waterjet, or did you guys make them on a mill w/ an involute cutter?

[evanperryg]

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!

[Bryce2471]

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.

[Joel Glidden]

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?

[rnewendyke]

Thanks for the quick response. I like your simple code solution, and it looks to not make a large difference in your driving performance.

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.

Do you use drive encoders? Sense your already raping wires anyway, it seems like it might be worth it for you guys.

So magnetic tooth counters were mounted to measure the speed of the wheels. There is an encoder mounted above the wheel mounted to the banebot motor assembly (which you can see in the CAD image) which measures the rotation of the modules.

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'm also curious if you give me an estimate amount of time spent on machining and assembling all those custom parts. we spent quite a bit of time on ours, and they only require five parts to be cut on the CNC mill

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.

Any chance we could get a few more of those sweet, sweet, hi-res photos? The CAD really isn't doing the rest of it justice.

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

Do those holes in the hubs create any sort of airflow to the CIM (sort of like a fan?)?

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.

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.

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.

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?

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.

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?

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 (http://www.chiefdelphi.com/forums/showthread.php?t=128381), 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.

[ekapalka]

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 (http://www.chiefdelphi.com/media/papers/2426)?

[rnewendyke]

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 (http://www.chiefdelphi.com/media/papers/2426)?

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"

The second "180 problem" I am looking at is more difficult: if the drivetrain does not have unlimited steering, or if the sensors have have gaps (dead zone). The design goal is to minimize the "bad behavior" around the discontinuity. One approach might be to build some smarts into the control algorithm so that it looks for opportunities to steer the wheels away from the discontinuity whenever doing so would be least disruptive (for example when speeds are very low).

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.

[GearsOfFury]

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...!

[Aren Siekmeier]

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?

[rnewendyke]

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.

[Aren Siekmeier]

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?

[rnewendyke]

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.

[Aren Siekmeier]

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!

[rnewendyke]

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.

[tickspe15]

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.

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

[Roboshant]

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?

[nickrod99]

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

[pwnageNick]

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 website here (http://www.pwnagerobotics.com/our-robots) 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.

[Kevin Ainsworth]

ftp://Kevin061815:Ainsworth@files.genesisautomation.com/

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.

[Kevin Ainsworth]

ftp://Pwnage120916:2451@files.genesisautomation.com
New File Location