I was looking at some old YouTube videos of amazing robot releases in early weeks. From a team that often is pulling long nights and full weekends near the end of the season to finish our bot, I am really interested in learning how your team plans and starts Prototyping on kickoff weekend.
So, what is your team’s plan?
Our team’s process is roughly the following:
We use a lot of wood and scrap to prototype, simply because they are there and easy to work with. Our initial goal isn’t necessarily a wonderful working model, but a proof of concept. Once a proof of concept is established, we take those two prototypes and move on to iterative prototyping while CAD team starts creating possible designs for it.
Once we see which prototypes work better, we continue from there.
Important to note that drivetrain CAD/construction occurs simultaneously with this process.
Hope that gives some sort of useful insight.
1716 tends to do little prototyping on kickoff Saturday.
What we do instead is split into subteams and then from there brainstorm all sorts of ideas for whatever module we’re assigned to.
From there, on Monday, after everyone had a chance to mull over ideas and come up with new ones, we start prototyping.
Now, a couple of tips are to…
One: don’t worry too much about being precise. It’s not the final robot, it’s a prototype. You don’t need everything measured perfectly, it’ll be refined later.
Secondly: cannibalize old or failed projects. Reuse parts that are useful, and see if you can use things for multiple purposes.
Third: don’t bother with motors, use drills. A lot quicker to set up, a lot more convenient, and saves a whole lot of time.
Those are things 1716 does, and it really shortens time to get working models.
Also, one more thing: you don’t need to ever stop prototyping. People come up with ideas all the time, and some are really useful. (For instance, 1716 thought of a blocker really late this year, but we made a working model, decided it was worth it to use it, and was able to bring it to competition and add it.)
Our prototyping isn’t perfect, but it’s quick and gets the job done; just like it should.
We use a similar process as posted above by wasayanwer97 but during the prototyping stage we end up having a lot of short meetings as people come up with new ideas. We have several groups working on many different ideas during the first two days, for the most part everyone can work on mocking up an idea if they think it has potential. We also work on getting a field molded during the first weekend. We try to put in more hours the first 5 days than we do later on, once we have a solid idea the rest is just getting it all in CAD and manufactured.
This album is some of the pictures I have from prototypes and the final mechanisms my high school team built back in the day for us visual learners.
I think you’ll find a number of teams don’t do prototyping on the first weekend, but come to a consensus on strategy and essential functions of the machine, then prototype through the first week.
Similar to the above posts we read the rules and start discussing the aspects of the game that we see are going to be played. Over the next week we brake off into smaller groups that prototyped shooters, brainstormed how to climb the tower, and continued to brainstorm robot concepts. Everyday during week 1 we typically begin with a meeting, break for projects, and then return to a meeting as mentors come in from work and we break for dinner.
We worked through some basic Lego robots this past year on a tabletop version of the pyramid to visualize how to climb the pryamid. Through it we learned a lot about the geometry and involved and where the best route of attack was.
For some robot concepts like this past year’s shooter and some mechanisms in 2012 we worked on them until we had the proof of concept down/the numbers we needed to design it. Our climber this year was brainstormed until a student came up with an idea of which he CADed out and designed until we had what we needed around the end of week 3 to build it. We tested it some more, kept iterating some aspects of it until we had what we needed in week 5 to build the competition climber which at that point was a nearly identical system except the parts were re-cut and less cheese holed from moving components around. Our shooter in 2012 took a similar road in that our prototype was tweaked and modified until eventually we took it apart, painted it, and built a mounting system to the robot. The same shooter we started with in week 2/3 stayed to be the one on the competition robot.
Here is a photo from 2012 where in the course of a few evenings in week 1 we prototyped skid plates for the bottom of our robot to cross the bump as well as our ball pickup system. Very basic systems but we learned what we needed from them before making the models in CAD.
What seems to be working for us (were still in the ‘learning’ stages, and constantly changing/iterating/gaining resources/mentors ect)
[ol]
[li]Attend Kickoff[/li][li]Read the game rules, out loud with entire team[/li][li]Read the robot rules, out loud with entire team[/li][li]Brainstorm Strategies[/li]-Include two values with each strategy
[LIST=1]
[li]Difficulty with your teams resources/abilities, scale of 1-10 (10 being most difficult)[/li][li]Estimated points value, decided upon by various simulation methods[/li]-I like to start with a “Godbot” strategy and a “Simple as possible” strategy, using them as boundaries.
[/ol]
[li]Select a strategy based on what earns you the most points, yet isn’t out of your capabilities (i.e. low difficulty, high reward. We usually settle on a difficulty value of around 4 or 5, but honestly if you find that a strategy with a difficulty of 2 gets you more points then a strategy with a difficulty of 5 you struck gold.)[/li][li]Conceptualize your robot as a whole system that plays decided strategy (as a team)[/li][li]Create a wanted/needed features list for each component. This becomes your prototyper’s bible.[/li][li]Prototype out any unanswered questions (i.e. 2010 ‘how difficult is it to control a ball’? and mechanisms based on said strategy.[/li]-Don’t be afraid to iterate
-We usually start with proof-of-concept prototypes and evolve them up to final prototypes, filtering out some ideas or gaining others along the way. Critical measurements are taken from final prototypes and transferred into our CAD drawings.
[/LIST]
We usually end up with a full mockup of our robot, as well as individual prototyped components, that get meshed together into a cad model. For example, this past year:
Full robot mockup
Final shooter+intake/conveyor protos (not the best picture but it was all I could find)
Final Product
One of the biggest thing’s we’ve done the past few years is to schedule ourselves for a 5 week build season, instead of 6. We haven’t hit 5 weeks yet, but we’ve been close, and as a result that last week doesn’t take as big a toll.
You need to go in with a generalized, season long plan. Finish the prototyping and drive train in the first week and have a design set by the end of the week. That’s when you come up with your specific schedule to try and get everything finished early.
One of the key tricks is to only take on what you can accomplish. We do a cost/benefit analysis, where cost is mostly complexity/time to implement (we haven’t had an issue yet where cost = $ for what we’ve wanted to do, but that is always something to consider), and you have to be realistic in the amount of time/effort you can put in so you know where to draw the line.
This year we are going to give the play the game with humans as robots in the school cafeteria with cardboard mockups, note to self: stop by the local appliance store to make sure the cardboard supply is set up. I expect that this will lead to wood and pvp proofs of concepts.
