Sometime late spring/early summer, I’m planning on doing a budget build challenge for the 2018-2019 VRC game that will be revealed at the end of April at World Championship. My goal is to take the parts provided by the RECF Team grant bundle and a few hundred dollars of extra spending money and build the most competitive MS/HS legal robot I can for the new VRC game. I think that this will be a fun and novel challenge, and I encourage other VRC veterans/mentors/alums/teams to join in and share their process.
The intention of the project is to provide a reference robot and engineering design process that could be used competitively which should be accessible to almost all teams/organisations. I get a lot of complaints from students that they don’t have the resources or hardware that they need, so their poor performance or design process is justified as a result. I’d like to show that even with just the base kits and what amounts to either club/team dues or a little buy in from a mentor/parent, a team can build a competitive robot and do well, maybe even win some events and judged awards.
I’m planning on using V5 for this challenge, and I expect that RECF will change the grant bundle to include V5 instead of the old Cortex-based system (either to be announced during or after Championship maybe?). I will substitute the control system for V5 however if they do not update the package in time.
I’d like some community feedback on what the requirements should be. Specifically, what should the minimum general requirements for the build be, and what should I set the budget at? Would $500 in addition to the grant bundle be too much? Too little? What documentation should be required? CAD models and analysis? BOMs? What in general would you like to see in something like this?
I think providing CAD models would result in too many people simply cloning the robot rather than following their own design process, so maybe don’t provide those. With that said, I think a few screenshots of CAD models would encourage some teams to consider CAD-modeling their own robot.
I do think, though, that each subsystem should have 1 or more clear sketches that do not indicate the parts used but do show the general physics of the subsystems. For example, a basic tank drive might be represented as shown in the attachment (though a little less crude).
As for the BOM, I would say, going along the same lines of discouraging clones, group the materials into categories (metal, gears, motors, etc.) and, in lieu of exact quantities, indicate how much you spent on each category, rounded to the tens place. This would give new teams an idea of roughly how they should split their budget.
One additional thing I think would be helpful are some sample engineering notebook entries. Perhaps include a few that demonstrate decision-making, a few that show evidence of testing (with some quantitative data), etc.
I might recommend using a chain drive, since high strength chain comes in the kit, and make the motors easy to swap out. V5 Motors should be able to handle independent direct-drive motors much better, since there will be less of a tendency for motor burnout when the robot is lifted onto only two wheels. I would recommend adding a few things that help new teams, like components that use pillow blocks, plexiglass, rubber bands, and using screws as axles when beneficial. There are a lot of quality-of-life tricks and tips that allow for easier servicing, less motor burnout, and overall reduced downtime. If the entry level bot designs demonstrate general best practices, then new teams can build like they are veterans.
Why are you so concerned about preventing teams from copying a design? Design convergence happens regardless of how much reference material on a design exists. Teams will organically converge on similar solutions to things is the problem set is constrained enough. It will happen regardless of whether or not I disclose the entire process.
I think this concept of preventing “clones” is somewhat against the sprit of what I’m trying to accomplish. The intent is to walk teams through a proper design process and teach them design and building techniques that will help them succeed. I can’t do that without sharing most of a documented process.
If I leave out a BOM, how in the world am I supposed to prove that I stayed within a certain budget? I’d be doing a poorer job of accomplishing the goals of the project by providing a limited set of information.
I want to see teams perform better. I want to see teams build better robots. If I had to choose between team 123A showing up to an event with something that doesn’t work or team 123A showing up with a screw for screw copy of a reference design, then I’ll take the latter every time. Here’s the thing: in 123A’s next season, there’s a good chance that they’ll want to do their own thing, and they’ll probably be better equipped for it and have more fun doing it.
100% agreed. The idea is about raising every team up to a minimum standard of play. A robot where everything is done poorly does not teach teams any good habits. Showing teams how to succeed at least a little bit within a small reasonable budget is a good resource for everyone.
I imagine some teams with extremely complicated expensive bots will be amazed at how successful a simple robot can be and try to simplify their design.
I also imagine some teams with very little money that always blame lack of funds on poor performance will be pushed to fully utilize the parts they have to succeed.
Sharing ideas is a great idea, and “best practices” also means using legal materials, of which “plexiglass” (a brand name of Acrylic or PMMA) is not legal. I realize the majority of teams use the term “plexiglass” to mean polycarbonate (or any of the other legal plastics), so let’s make it a best practice not to confuse new teams by specifying illegal materials when we don’t mean to.
I wonder if it would be more valuable to provide a paper list detailing the suggested budget distribution (like @Barin said), and also include a checklist of basic, intermediate, and maybe advanced build tips (in checklist form?) that tell new teams how to make the overall build quality better. Sample programs might help as well. It would be much more valuable if they can focus on the solution, build it, and not have to worry about loose screws and dying motors 24/7. Then, we (experienced teams) wouldn’t be giving them all the answers, we would see fewer clonebots, and perhaps have more consistent competitions.
I see your point, and I also realize we don’t entirely agree on what the exact goal(s) of this project should be. And I do realize my suggestions are on the extreme side of things, so I encourage you to take a more balanced approach.
Overall, though, I was trying to reduce artificial design convergence. I fully realize organic design convergence is natural and in many ways a positive thing. But I think most people would be upset if they devoted time and effort to going through the design process only to be beaten by a team that just copied a design from someone else. Plus, cloning the design doesn’t actually help the team learn the design process.
Regardless, this is your project, not mine. These are just my two cents; you can do with them what you want.
I’ve seen very good things come from giving teams a complete design that will get them going. It quickly leads to them finding ways to improve the design.
Doug Klein from the University of Kentucky put together some videos of prototype robots for the last two years. It has really helped new teams learn about building. Take a minute to look at these:
Here’s an assembly video for the “Kentucky Starter Bot” from Starstruck.
This could be built from the classroom kit. After building this, teams quickly changed the design and made more complex intakes and beefier drives. I don’t think we ever saw one unmodified used in competition. But we saw lots of designs that used this as the starting point.
Here’s an assembly vide for the In the Zone starter bot.
Again, this was based on the parts available in the classroom competition kit.
Here’s a video for coding the ITZ starter bot.
As I said, almost nobody showed up to compete with one of these unmodified. Nearly everybody changed something, and most changed almost everything. But it got new teams up and running, and having fun and learning.
So, it’s turned out to be less about the clone bots and more about learning how to put together a working drive, lift, and intake, and then programming it. As just a single example of the benefits, it’s very easy for people to see how well a two-rail chassis side works with the axle supported on both ends. You can tell people that, but it really sinks in when they build it.
I mean in essence, this is what they do in VEX IQ with basic bots that are simple to build and program and play the current game. This year it was the stretch bot.
I think this concept is great and also needed in VRC. Raising the floor and enabling more teams to have a positive experience competing should always be the goal. No one has fun with a robot that’s not working well.
I think this is a fantastic idea!! This was our first season, and we struggled with learning good building techniques and competition build work based almost solely on the Vex Clawbot information, Google, and a bunch of trial and error (and it WAS a struggle!). We started off building that because 1) we knew we had the parts in the kit and 2) we knew there were instructions to help us on the way. We really never intended to do a bunch of competing with it! However, as a team just moving from Vex IQ into VRC we needed a boost on how to build in a completely different way.
We walked through the available curricula (building & programming) and did the Clawbot build, but we were still woefully behind in knowing how to build a real competition robot. We learned a bunch of fantastic lessons along the way to building our final competition robot (which could score quite well in all areas by the end), but some of them were fairly costly, time-consuming, and stressful (and easily avoided with a bit more information).
A robot built with a large variety of techniques doing the same task would have been neat to experiment with (for instance: screw joints and axle joints, metal connections using different types of methods like gussets or angles, different ways of doing spacing, different screws and nuts that work better in different situations, etc). While perhaps not “best practices”, it would have been great to get a better feel for what you COULD do and what parts were available to help.
More information on wire management and how (very) important it is…
Robust sample programs using the competition template with ideas on how to test it without a competition switch would be nice. We didn’t find out about the RobotC debugger competition switch until several competitions in!
Personally, I think $500 over would have been too much for a starter robot (at least in our situation, since we weren’t planning to compete with it but rather using it to learn building techniques). We spent over that in the end, but in the beginning we wouldn’t have paid out that much additional for our prelim test builds unless it was clearly something we’d be using for a final build (like a bunch of aluminum, or a certain type of wheel). Once we got more advanced in our building we were more comfortable with what we would / wouldn’t be likely to use and more willing to buy additional items.
Maybe a robot with a few levels? Start with a robot that can be done with basically just the starter kit (and maybe a bit extra), then have a “next level” (or two) for $$ more that can be built to learn XYZ and added onto the original robot? Each level would be a completely functional robot when put together but they could build up to a more complex whole.
Reminds me of 118’s “Everybot” in FRC - I like it!
As a leader of 2 low-budget teams, I do agree that there are ways to do well and even win with less than other teams (as Oscar state above, for IQ it was “Stretch” bot - which my team won States with). What students mostly need is a very strong mastery of the basics as far as robot construction goes - a simple build accomplishes that.
I like this idea of having multiple versions. I think what teams will find based on results of something like that is that building something from just the super kit is significantly harder than building with the super kit and just a few extra items, even as little extra as a long structure kit or two and some more omni wheels.
I ran a summer camp during the Nothing But Net season where we worked with something like ten groups that took just the super kit and built bots, and it was a real challenge to get something scoring well. The super kit has almost no 17.5" structure components, so you can’t really build a full size robot, and only having two omni wheels was somewhat annoying (the regular 4" wheels have almost no traction on the foam tiles).
On the other hand, there is a lot to learn about careful resource management and decision making when dealing with that budget, whether it be $100, $250, $500, or even more. Documenting this process and the resulting decisions will likely be very useful for teams either in the transition phase from new team to established program, or for programs that are underfunded. That’s why I’m looking to lock in some number for this. I’d like to get an understanding of where the target demographic stands as far as budget is concerned to appeal to as many teams as possible.
