pic: Team 2451 Pwnage

[pwnageNick]

Originally Posted by Bryce2471

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:

Originally Posted by John Duffy: Midwest Swerve Tech Paper

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]

Originally Posted by CENTURION

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]

Originally Posted by Bryce2471

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.

Originally Posted by Bryce2471

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

Originally Posted by pwnageNick

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.

Originally Posted by Bryce2471

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.

Originally Posted by CENTURION

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.

Originally Posted by CENTURION

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.

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

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.

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

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.

Originally Posted by Joel Glidden

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, 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?

[rnewendyke]

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

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"

Originally Posted by Ether

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....3-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]

Originally Posted by compwiztobe

Importing the step file currently at http://www.pwnagerobotics.com/index....3-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]

Originally Posted by rnewendyke

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]

Originally Posted by compwiztobe

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.