prototyping with relatively limited time

Our team is a bit time-constrained relative to other teams. We meet 3 (occasionally 4) times a week during build, for around 4 hours each meeting, and we also take much of one week off during build due to finals.

We’re trying to become more efficient through refining our engineering process, adding examples/templates/“how-to’s” for team members to use where possible to save time, etc.

One area we know we can improve is prototyping. We’re looking to upgrade both our approach and our kit for prototyping, but even as we do that our time constraints will limit how much we can do before we have to build the robot for programming & driving practice.

So making good prioritization decisions about what to prototype, how to be as efficient as possible in order to maximize iteration, etc. are key. Are there other time-constrained teams out there who feel they’ve figured this out to some degree (approach, how to plan/prioritize, decision trees, lists of dimensions by mechanism archetype & which ones to typically prioritize…)? If there are 20 things we could do but only time for 3 to 5, how to pick?

Thanks!

My best recommendation would be to pick one or two game tasks that you think will make you the most beneficial as an alliance partner, prototype what you need for those tasks, and then design your robot to just do that.

Karthik says, “If you do ONE thing, every single match, without fail, you will beat the guy who does many different things poorly. Every time.”

JVN says, “You don’t need to prototype everything, just the stuff you want to work.”

Take those two statements together, and you find that if you only have time to prototype one or two things, then you should focus on getting those one or two things working perfectly every time.

As far as deciding which one or two things you want to focus on, I would point you to Karthik’s Strategy Conference he gives every year at Champs. There should be a link to a video somewhere in this thread from his 2016 talk.

Intellgent design of wood prototypes (to be made on a laser cutter/router) can be incredibly helpful to prototype quickly and effectively. Rather than remake your prototype for different wheel sizes or geometries, taking the time to design those things in (out of shop, in cad) can save you lots of shop time in testing. If you have access to those machines or anything similar, I’d highly reccomend doing a few trial runs in the offseason and then implementing this modular/adjustable prototype design in-season.

This is somewhat both resource and game dependent, but one of the things that I fell in love with was the way that for the 2017 season, FRC125 was doing small scale rapid prototyping via practice golf balls and 3D printing. Design, print it overnight, test, repeat.

It’s also not the most ideal solution, but what about figuring out how much you can accomplish outside of normal meeting hours and use the regular meetings more as update/convergence periods, later to be turned into assembly periods? For the most part, you should be able to do, say, CAD work and programming in between meetings, and if you wanted to be really intrepid, figure out an electrical layout so that all you have to do is physically laying out components and connections.
If you have automated machining, ask if the teacher would be okay with doing the actual machining between meetings or during the day or what not so that when you all convene, it’s mostly assembly rather than watching the machine itself.

My old team met about 12-15 hours a week during season. I think the key to prototyping was thinking about the testing goals and procedures from the start of the prototype design. Don’t just think about whether or not the mechanism will work, but rather which variables directly affect the performance of the mechanism and design your mechanism and tests to change them (ie shot angle, compression, etc).

Effective testing of the prototypes is important as well. Always test something objective and measurable and keep the tests consistent (dont test intaking a cube straight on with one prototype and at an angle for a different configuration). When tweaking your prototype, tweak only one variable at a time so the changes can be attributed to each variable.

Lastly, always iterate. Engineering is an iterative process, and remember that even your competition robot is a prototype and can be iterated on.

Develop a comprehensive test plan that takes into account how the mechanism needs to work during competition. It is bogus to set your robot in front of the goal and shoot a buch of game pieces into the goal and declare that it works great when the robot will have to drive across the field, stop then shoot quickly.

Take notes when testing. Repeat each test a statistically significant number of times (at least 5 X). You need to base your decision on objective data rather than impressions and feelings. You will also need that data to reproduce the configuration that gave the best results. It’s a bummer to say “it worked great but we don’t remember the setting”

One thing you may want to consider; you can withhold 30 lbs of the robot on bag day. So if there is one or potentially 2 mechanisms that are small enough to stay below 30 lbs, you can postpone the prototyping and building of these elements until after bag day. This would allow you to focus on the other aspects of the robot during the build season and then work on these smaller elements later.

You can also do osmosis prototyping for these elements by watching some of the week 1 event to see what designs are working well and what designs are not working well.

An example this year could be your intake. You could bag a robot without an intake and then watch some reveal videos and week 1 events and see which intake designs seem to be working well and then copy those designs. You can easily get a design built and tested using a “mule” vehicle (a previous year’s robot, for example) and be ready to just bolt it on to your robot when you take it out of the bag at your first competition.

It is a little scary and doesn’t give your drive team any time to practice with a complete robot before bag day, but if you are truly time constrained, you are probably foregoing those things anyway.

I certainly don’t recommend this as your strategy going in to the season, but if you work on the bigger mechanisms, then, assuming you are confident that you will have the time to work on it after bag day, you could save the smaller items until the end (which may end up being after bag day).

With a huge time constraint, I highly suggest spending pre-season researching past games of both FTC and FRC. Very often, there is some sort of game that has similar to past games. This gives you a lot of direction towards what designs works for what game pieces before the game even is released.

Also, I highly suggest a kit bot drive train. Being able to build a solid drive train quickly frees up more time to develop mechanisms.

As a follow up question: what sort of practical advice do you have for rapid prototyping. As in, stock up on part A before the season, invest in this equipment, etc. We are also a time limited (and budget limited) team.

[ol]
[li]VersaPlanetary gearboxes with hex shaft output
[/li][li]775pro/Redline motors (wait for sale?)
[/li][LIST=2]
[li]Or just use drills
[/li][/ol]
[li]Wood
[/li][/LIST]

This is basically the backbone of our prototyping strategy. Put together something that works with 2x4s and go from there.

Our team meets about 15 hours a week, and we usually only prototype one or two things. We use wood, shafts, bearings, and hand drills to prototype if it is someting that needs to move.

For Steamworks, our gear catcher didn’t move so we just started with a couple of pieces of wood and kept cutting until it worked fell to the correct position. We thought this idea would work in concept, so we needed to figure out specifics.

For Power-Up, we used drills and wheels to find the ideal wheel position for our cube intake. We knew that a wheel intake would work for the cubes, so we just needed to figure out the best position

Also, notice how we only were looking at a couple of variables for each mechanism.

Take advantage of projects and resources that do prototyping for you. WestCoast Products’ MCC, the Robot in 3 Days teams, 973 Greyt Mechanisms - while these won’t solve the problem for you, they’ll get a lot of the guesswork done for you and let you focus on iteration and tuning.