Team JVN started out with a strategy session that went surprisingly quickly. Once we began analyzing the game, we realized that due to the nature of the game cycles, it is pretty easy to determine the possible flows a match can take. (Well, at least as far as we think!) We discovered that the highest scoring cycles all included some way to elevate the game balls, even if it’s only over the truss and not more complicated/difficult movement. We began talking about putting a launcher of some kind on the robot, perhaps something that can intake the balls from the floor; add in a catcher and you have an extremely robust scoring machine. It also means that you become an attractively versatile alliance partner, which is obviously desirable.
One of these all-in-one machines could truss or catch, score by launching into the high goals, pick up another ball without catching it in the air, and so on. Our team felt this was a good path and decided to move forward prototyping a launcher/catcher robot. A catapult-style launcher would fit in well with our initial intentions of planting our robot on the goal wall and doing a layup-type movement. The catcher component would help show how viable truss-catching actually is, and would give us a feel for the new 20″ outside perimeter rule for 2014.
Our first prototype, the catcher bot, was surprisingly large. It actually inspired our confidences in the ease of making something that could both catch effectively AND toss a ball to another catcher bot. Given the potential scoring importance of assists in this year’s game, this was a particularly important discovery for us. The second prototype, our catapult launcher, had a ball airborne within the first two hours of the build. This was also particularly confidence-inspiring for the team. We utilized an old 2005 kitbot chassis that we had laying around into the base for our robot. We sent team members Charles Wensel, Carlos Perez, and Randy Larsen on our first Home Depot run for some 2×4’s and used those to create a tower. We added VersaFrame parts for the arms, added surgical tubing for tensioning, and voila – our catapult was working like a charm. But all of that was just the beginning.
After the prototypes were complete, we began JVN’s favorite part – the iteration of our designs. Those on ChiefDelphi or that have worked with John over the years have heard his “Design is Iterative” mantra many, many times. And for good reason – it’s an incredibly important part of the design process. The subteam – and later, most other team members – spent the majority of their afternoon and evening testing the launcher, recording the results, and attempting to find the correlations. For example, we noted the direction the ball was launched (e.g., “ball launches straight up”). Then we tweaked the robot in some way, such as tilting the robot forward to simulate changing the hard stop position. We then recorded the results – “ball now launches more forward” – and repeated this process over and over to understand the launcher’s behavior. As we tested the launcher, the structure itself began to change. We began to change the parts of the robot that we felt might affect these key components, and eventually ended up creating a more versatile and adjustable robot overall. Specifically: adjustable peg lengths for the ball cradle, adjustable hard stop length, adjustable pivot point for positioning, adjustable pivot height, adjustable surgical tubing strength, adjustable starting angle for release, etc. When the robot changed, our results changed as well. Now our results were more like, “Launches straight up. Adjust nylon strap to change actual hard stop position. Now launches more forward.”
To understand the robot further, we changed only one variable at a time to really nail down the correlations between each variable and the final output. We kept it simple by using basic tools (such as a tape measure) to track and record how much a nylon strap needed to move, or an angle meter to record the starting angle, etc. This isn’t complicated to do, but so many teams get this wrong by not properly dedicating the time and effort to this task. Small prototyping efforts can yield hugely important results later in the build season. By being efficient in our prototyping processes (and by utilizing some cool maths that we’re referring to as “Aren’s Sweet Spot” that we’ll bring up in a later post), we had an extremely consistent high shooter robot by the end of evening. It appears the final robot will end up looking very similar to the prototype design since we were pleased with its overall performance. There’s still a lot ahead of us, not to mention a small mountain of CAD work. We’ll keep you updated!