This is the zipped CAD assembly of GUS Team 228’s 2009 FRC robot, Gus 11.
This is the zipped CAD assembly of GUS Team 228’s 2009 FRC robot, Gus 11. Everything mechanically important was modeled; missing are most of the sensors (including camera), electrical and pneumatic systems.
Originally modeled in Solidworks, I exported a STEP file for universal importability into the CAD program of your choice. The original .zip file was too large for CD-Media, so until it can be uploaded here, it can be downloaded here: http://www.team228.org/documents/2009/FRC228-Gus-11_Entire-2009-Robot.zip
What was the thought behind the pneumatics on the intake assembly (i.e. why wasn’t the intake static)
Did the empty cell mechanism end up working well? It looks brilliant.
And a non-design question: Why is the assembly made mostly of individual parts rather than sub-assemblies? Is there some advantage to doing it this way?
The idea behind the pneumatics was when the robot stopped picking up balls and wanted to shoot, the pneumatics would pull the ball intake backwards, blocking the gap for the ball intake (and thus aiding the movement of balls the elevator up to the shooter.
The empty cell exchanger would work if you can get it close enough, and calculations based on robot bumper dimensions. Unfortunately, close enough was about two inches away in real world tests on the field. If there wasn’t the rule prohibting expansions outside of the bumper perimeter, we could have made the fingers about two inches longer and it would have worked great.
The only reason why there aren’t too many sub assemblies is because I used folders to organize parts in Solidworks and used patterns whereever possible. There will most likely be more sub assemblies in our 2010 robot, as 2009 was the first year we modeled our entire robot and was a learning experience for us.
I see. I like to build CAD models in lot of small sub-assemblies, then put all those sub-assemblies together in one big assembly. The main advantage is that most of the time, you only have to work with a small assembly, rather than having to open up the whole thing to make changes. The downside is that if you move or rename a file, its whole sub-assembly starts complaining, and it can take a little longer to isolate the problem.
Once again, very nice!. I can’t wait to see your 2010 CAD!
Another disadvantage to subassemblies is that if a part can move (rotate, translate, etc) within the subassembly then it will remain stationary in the main assembly. For example, If I have a drive train assembly and an arm assembly, then put both of those into the overall robot assembly, then I’m unable to rotate the wheels and the shoulder joint on the arm from the main robot assembly.
Of course, this assumes I haven’t missed something…
In Solidworks, you can right click on a sub assembly, go to Properties, then in the Properties window set the assembly from Rigid to Flexible. Sub assemblies are Rigid by default, but selecting Flexible allows them to move however the mates in the sub assembly were set up.
Oh, that’s right! I had forgotten about that. I’ve had this problem, too. It bugs me little that I can’t rotate an arm or raise an elevator in the main assembly, but, then again, I really only use the full assembly for show (and weight, of course). If I want to illustrate motion, I open up the subassembly I’m dealing with. Again, allows me to work with only small assemblies. Maybe this comes from worrying about my computer crashing all the time!
For those that use inventor, you can also make assemblies flexible and allow you to move the sub assemblies. However it is a big drain on computer resources, pick and choose what you want to make flexible wisely.
This is my question to everyone, because this is automatically what I thought when I saw this robot last year. How many other people automatically when they saw GUS say to themselves “dang they got it dead on, and why didn’t we think of that”. It’s an amazing design and above all it’s simplistic, which we should all strive for in our designs.
And my question to GUS is this, how did you assemble your conveyer belts? 2228 used a very similar looking system. We took aluminum tubes and riveted wedge top in small sections to create channels for polycord to ride in. This worked pretty well, but on our elevator conveyer the polycord would often slip out, even in competition, and this proved the biggest disadvantage of our system.
Can’t answer for GUS, but my team used solid Delrin and lathed grooves into it for our rollers (the overall design was very similar to GUS’s). The polycords still slipped, but not very often.
Originally the robot was designed to use foam between the polycord loops. This didn’t work so well, as the foam from McMaster was a lot softer than we were expecting. So we replaced it with neoprene roughtop belting, with PVC pipe spacers on some of the rollers. The rollers were originally PET-G, but upgraded to aluminum as part of the 40lb allowance.
We had some minor issues with the polycord loops “jumping” from one track to another, but these only happened if for some reason there was a Orbit ball jam in the system, and were usually limited to one or two loops total moving over one or two spots throughout the entire match. Because the loops were close enough together, this usually didn’t negatively impact operation. Had we installed sensors on the robot to detect jams, we could have easily averted most of these issues.
Other than popping one or two of the loops back into their tracks at the end of every match, nothing else on this robot ever required any sort of maintenance or repair. Our students even got into the habit of cleaning the fingerprints off the Lexan side panels in the pits just to have something to do.
There was just a single part throughout the entire season (Connecticut, Championship, BattleCry@WPI, Where’s Wolcott, Bash@theBeach) that required any kind of repair, and that was the 3/8" drive shaft on the ball intake bent slightly during a particularly nasty impact in autonomous at BattleCry@WPI. Even though it was bent and made angry noises, it still worked for the rest of the competition. We machined a replacement shortly thereafter, and it’s been working great since.
Here’s some photos of the spacers from our team’s website:
I can’t wait to show the team this tomorrow, at our last meeting before kickoff :D, and watch everyone in the room kick themselves, because if we simply had PVC rings like those we could have rapped and riveted the wedgetop just like we did, but that extra 1/4 or so that the PVC has in it’s wall thickness would have created deep enough channels to prevent the polycord from jumping if not 100% of the time 99.9% of the time. And as the driver who piloted the robots elevator conveyerbelt and shooter I have to say this would have saved me the trouble of finding the perfect sequence of running the motor forward and backward to jump back to the right loop, so we could still shoot (surprisingly that actually worked on occasion but it’s not something I want to see have to happen). Once again thank you to you and the rest of 228 for showing us your robot, and like I said before you guys have the right motto because simplicity is the key to any successful design.
Also thank you to Jamie Kalb I think our mentors would be very interested in this approach to the design.
You bet. The thing to watch for is that it’s heavy. Our rollers were 7-8 pounds each before we lathed more grooves in to cut down their weight. Even so, we couldn’t get them below 5 pounds, if I remember correctly.
WildStang has used lexan tubing for rollers like this. When they suggested we replace our cracked wooden one with lexan, we were amazed at the weight savings. We were also happy with the way the new roller basically shrugged off impacts without damage.
