What I mean by this is, when do you transition from making mechanisms to putting those mechanisms together into a robot?
Traditionally, our team has struggled because we have built mechanisms, and then we put together a really bad combination of items that don’t complement each other. Things like using mecanum wheels that don’t actually have the traction to put out all the force our gearboxes can provide (we gear them too high, so we go slowly without any added push), especially when strafing offered us no strategic benefit. I’m frustrated by it, and I can’t say I’m not part of the problem, but my team HAS to change the way we design our robot.
Do you CAD your robot before you build it? This can really help you with robot design. If you provide more information on your design process, we may be able to give your better suggestions.
It depends on how much CAD talent we have. The students who had the most experience with CAD graduated last year, so this year, we didn’t get as much CADed as we liked. You can really see the difference in the final product. We were able to get the robot done a lot sooner (I believe CADed by around week 3), so we had the opportunity to paint it and make it look great. This year, however, because a lot of our design was done on the fly, we ran into a lot more problems and took a lot longer to build. As a result, our final product didn’t perform as well as we hoped nor did it look aesthetically pleasing.
It sounds like you have three separate issues: strategy for design, systems integration, and detailed design (particularly verification to strategy). I think you’ll find most perennially strong teams have their whole-robot strategy laid out and prioritized within the first week (maybe two if you have fast manufacturing). This is turned into functional objectives–not strafing when it’s not useful, and making sure the mechanisms you focus on will actually help you perform to your best. You might like Karthik’s Effective FIRST Strategies presentation (here’s last year’s) as well as the QFD presentation from FiM Championships.
Systems integration–putting the mechanisms together into a robot–is also something much easier/better done before and with mechanism development rather than after. When we nail down out strategy, we also roughly allocate things like space, weight and motors. As mechanism designs (both CAD and prototyping in our case) mature, the system integration matures with it. This is not an easy task, but it’s worth it to have a better robot at the end. We’re usually done the major integration decisions by week 4, though the chassis and drivetrain construction at least starts before then. It continues to change a bit until…well, this past Saturday. Actually, the Saturday of IRI.
Finally, you’ve learned that mechanism design needs to keep the strategy in mind. If you want to go fast but also strafe with mecanum, you need to work out your gear ratio based on that. The same goes for everything else–how high will your shooter mount? How ling can your climb take? etc. We constantly iterate this as well.
After nailing down a few good prototypes week 2-ish, we began to try to integrate all of our systems conceptually, then in CAD.
I find that rather than trying to slap together three differing designs for three differing parts, make a system that is made to go together.
During build season we were trying to integrate our <90 degree shooter, a bucket hopper, and our roller ground intake. We discovered that the three wouldn’t fit together well without significant testing and tuning to avoid jams and different angular adjustments.
Suddenly our driver had an idea- make one straight line path from collection to shooter without any complex elevation changes that could cause jamming or significant test/tune time. His design called for a straight line with frisbees lined up side by side up to the shooter with just enough room for 4 discs. In order to facilitate this, we just had to lower the entire tray’s angle at the beginning of the match.
The moral here is that it is difficult to integrate systems that aren’t meant to go together. Some teams can integrate differing systems extremely well- Code Orange’s bot is basically what we wanted to do, just couldn’t pull it off.
Know your team’s strengths, based on your history and the group of students you have. If you don’t have many programmers capable of creating perfect vision targeting- don’t build a 987-style epic turret. Build one or two shooter angles. Develop one or two spots you can shoot from at least 3/4 of the time.
If your team can handle large load holding mechanisms- i.e. a climber this year- then build one. If you guys can build the perfect arm, then use one of those.
Anyway, now I’m rambling. Hopefully that helped a little. I would recommend watching Karthik’s presentation- or at least looking at the powerpoint that he presents on the Simbot’s website. twentyfour.ewcp.org is also a good blog to look at in terms of strategic design.
Yes, we CAD our robot, but we only realize the problems in week 5 when we get our parts back.
Thanks for the advice. I’m definitely going to show that video to my team! How do you go about allocating space, weight and motors before you have developed your mechanisms?
I think this is our problem. We definitely develop our mechanisms independently, and they are meant to work well, not to work with the other mechanisms. Which is why they don’t work well when we finally put them together on a robot. Thanks for your help!
From what it sounds like, you have different people designing each mechanism. To get the mechanisms to work well, your design teams need to communicate with each other. Also, if you decide how your mechanisms will work together before splitting up into separate teams, you can make sure that the designs are capable of working together.
Our team usually has a general strategy nailed down within the first 72 hours, and we simultaneously brainstorm any mechanism that would achieve that strategy. Mechanism priority influences where in the build season we build it (we have a really small team. Building more than two things at once is not really possible.) Space and placement for each mechanism, based on said mechanism’s functions is also allocated within the first 72 hours.
Next comes rough paper cad, then detailed computer cad (done mainly by 2 people…small team). The detailed cad is a ongoing process up to week 5-6.
After prototyping mechanisms (along with their detailed CAD), **their compatibility is guaranteed by using standardized mounting techniques **(gussets, brackets, axles, etc). Tolerances are handled in CAD, troubleshooted on the prototype, and built into the final.
Overall, there are a few changes we can make (adding more people would allow this technique to expand, reducing the approval bottleneck by having more experienced members). The only problem we really have with the DESIGN process is that sometimes we forget to try and combine mechanisms (like 842’s intake/shoot/climb) and rather prototype individual mechanisms for tasks (like in an assembly line). The rational is that if we want to build 3 things, but only have the manpower for 1, we would rather have one thing done than nothing.
The hard part is building stuff in 6 weeks with only 4-5 dedicated members.
Our design concept was picked on Day 3, Monday after Kickoff. We then worked for three weeks on prototypes, the chassis build, and CAD design only to throw everything out on the Friday of Week 3 and try again.
At around Monday of Week 4, we all “knew” what the robot would look like. We prototyped a wooden shooter + hopper frame to ensure everything would work okay, then mounted it on the robot using the same shoulder joint that our climber would have used. The rest just happened.
Our head mentor is currently (and probably will be for some time) our lead CAD coordinator, making sure all of the subsystems work well together before manufacturing… or after, if we have to. I think teams need one or two people to integrate everything successfully in CAD, with good communication skills so they can talk about the design with prototypers and subsystem CADers. We then got everything cut and painted and had about 5 days to test it all before ship. Even so, we weren’t “done” with the robot until the beginning of our second regional.
We use standardized mounts like you, so they mount just fine, but I’m curious as to how you make sure they actually interact correctly. For instance, our feeder looked fine in the CAD, but when we tried it it flipped the frisbee almost every time, which turned out to be impossible to fix without rebuilding the feeder entirely.
I’d love to know how your head mentor goes about coordinating CAD. None of our mentors are mechanical engineers (actually, none are engineers at all), so the students coordinate the CAD as a group of about 5. Does he set requirements/specifications before the CAD is started, or does he let them start and then facilitate discussion to avoid conflicts?
We quite simply didn’t have enough people that are skilled enough at detailed CAD design + system integration that management at the “end” of the process is a problem. I think we just used a Google Drive this year between him and the 2 other people doing full subsystems in CAD.
We have a fair number of first and second year students who know enough Inventor to draw up prototypes and make part drawings for those prototypes, but they’re a little ways off from being able to do full subsystem CAD. This year for manipulator, the CAD workflow went from student prototyper -> a mentor (me) to touch up the details and integrate lessons learned -> head mentor to integrate the subsystem with the whole robot. Students were around every step of the way.
Once we’re fortunate enough to have a larger CAD team (should be this season, we have a lot of promising sophomores who made real contributions this year), we’ll probably move on to some more sophisticated version control.