As part of FIRST's plan to adapt to the global pandemic going on right now, the standard FRC season has been replaced with a set of socially distant "FRC At Home" challenges, one of which is the Game Design Challenge. This challenge flips the script on the FIRST Robotics Competition, and instead of teams designing robots to play the FRC game they are given, they are now designing games for theoretical FRC robots to play.
One of the teams, FRC 3847, also known as Spectrum, created the game Roll Up, which you can find more info about here. I really like this game (and Spectrum overall as a team), and I've been missing designing robots for a while, so I finally penciled some time aside and decided I would design robots for some of my favorite team-created FRC games, the first one being Roll Up. Instead of making a new blog post every time I have an update, I'll just continue adding to this post, with each new update being added after a page break.
4/7/21
Despite this post being made on 4/8, I technically started the design process on 4/7, so I will start there. I didn't do a whole lot of game analysis at first, but I did come up with the following thoughts:
Climbing is very important, not only for the ranking point, but also to make sure the opponent doesn't pull ahead in the endgame
It seems critical to be able to manipulate the large balls, since I believe you are limited to 10 small balls in autonomous and I don't think there are any ways of getting more until teleop, meaning that the best way to get points during auto is to score your preloaded large ball + as many as you can grab from the middle of the field as possible. There's a 2 game piece possession limit on the large balls (I believe there's no limit on small balls), so being able to carry 2 large balls is ideal.
With 18 large balls on the field, there is enough for each robot to be carrying 2 large balls + have 6 left over. I think there will be times in matches when it is hard to find large balls to score with.
I'm having trouble determining which game piece is more advantageous to score in a scenario where you can only do one. Ideally a robot can manipulate both effectively, but I think the designers very much intended to create a challenge where robots are typically better off being the master of one game piece as opposed to the jack of all trades, and realistically if my team (FRC 299) were to design a robot for this game, it would probably be in our better interest to only interact with one of the game pieces. With the large balls, the low number of balls on the field will create game piece shortages, and there's the 2 ball possession limit, but the scores are worth up to 10x more than the small balls during teleoperated period. I also think creating a mechanism to collect, store, and launch 2 large balls is going to be much easier than collecting a large amount of small balls, indexing them, and then launching them (potentially launching multiple at a time side by side). The large amount of small balls and no limit on possession could allow teams who can score small balls quickly to rack up, but there's this rule that says robots cannot possess small balls inside their robot higher than 18" off the ground. This is a really interesting rule that not only creates a unique limitation on teams designing for small balls, but also makes it so that optimizing your robot to utilize as much of its area as possible for small balls is necessary to succeeding with them.
I did some preliminary solidworks sketches for a robot that I thought might be able to score both small balls and big balls. I figured it would be easier to aim solely for the outer ring with hopes of making it into the inner ring (similar to the strategy in Infinite Recharge of aiming for the outer port and hoping to land in the inner port), and alongside that it may be feasible to roll several balls up the ramp in at a time. Since the outer ring hole is 28" wide, I wanted to try for 4 small balls next to each other, but I couldn't get it to fit nicely inside the chassis with the drivetrain I had set up (COTS swerve). I considered having the launcher outside the chassis with some articulated shooter that would lower outside the frame, but decided against it. Next I tried for 3 balls wide and that seemed to work out pretty nicely. At 3 balls wide, I could comfortably fit balls stacked 2.5 high (so really 2 high, maybe some others jumbled in there), 3 wide for the shooter, and 4 long across the chassis, for roughly 24 balls in the robot hopper. Not a whole lot, but not too little either, and with shooting balls 3 at a time it wouldn't take too long to empty the hopper in a volley for shots (rolls?). 24 balls in the outer ring is 24 points during teleop (1 pt each), and 48 points if I make it into the inner ring (2 pts each). Compare that to 20 points for 2 large balls in the outer ring (10 pts each) or 40 points for 2 balls in the inner ring (20 pts each). This design also leaves almost no room in the floor of the robot for large ball interaction. I could explore other designs, but I decided it may be better to just stick with one game piece. I was on the fence about which game piece to pick, because while I think the large balls make more sense competitively given their ease of designing around, importance in autonomous, and their higher point values seeming to be worth the extra cycles / difficulty in obtaining, the small ball robot offers a more unique design challenge when it comes to handling that many game objects and potentially scoring multiple at once. I think I will go with the large ball robot first, and maybe come back to this game after a bit and design a small-ball robot.
Considering my large-ball focused robot, I've made the following as my requirements list:
Need:
Fast, maneuverable driving around a semi-open field
Ability to cross the small bump in the middle of the field
Ability to pick up 2 large balls within quick succession of each other (if not at the same time)
Ability to store 2 large balls and index into a single file feed
Ability to launch large balls roughly floor level to roll up the ramp into the outer ring
Ability to climb to the top rung such that bumpers are 36" above the ground in ~5 seconds
Ability to stay on the ramp without rolling off
Ability to go from line up to both large balls scored in ~4 seconds
An autonomous routine that can score my preloaded large ball as well as a second large ball collected from the middle of the field
Ability to shoot from anywhere in my ramp zone
Want:
Camera tracking to center the robot on the goal
Ability to grasp onto the lower climb bar to either make room for another robot on the ramp or to shoot from a closer position (if that seems reasonable)
Ability to launch large balls roughly floor level to roll up the ramp into the inner ring
Ability to climb to the top rung such that bumpers are 36" above the ground in ~2.5 seconds
Ability to go from line up to both large balls scored in ~2 seconds
A 3 large ball auto routine
Nice to have:
LED visual aid for drivers to tell if robot is aligned and ready to shoot
4+ large ball auto routine
Double-sided intake (if deemed advantageous)
I've set up my new master sketch for this robot (seen below). It's far from finished but I'm trying out some different geometries and ideas for indexing. Ironically I may end up copying the indexing from Spectrum's 2020 robot, though I also may try something with a directional change if I go with a swerve (odds are I will).
Of course I don't have much in the means of prototyping most of these things since my team is homeless and it's quarantine so I'll go with my gut on what I think will probably work. That's all for now, I've gotta get back to some homework. Maybe later on today I'll get some more sketch work done and update it here. Still have more website stuff I need to take care of before I actually share this with friends / potential employers.
4/12/21 - 4/13/21
I've made a decent amount of progress with the sketch and robot assembly over the past two days. I've gotten my main robot sketch roughly 85% done, with major progress made on the ball ejection system, intakes, bar latch, and feeder system. I have a rough concept for the climber but it's bigger than I'd like it to be, and I'm not a huge fan of its current form factor and general functionality. I'm going to spend some more time iterating on that over the next couple of days. There's nothing keeping my robot from being as tall as the max height limit allows, but every part of my robot except the climber can fit in less than half the max height allowed so I feel like having the climber being a large beam way up there is less than ideal.
One of the climber options I've been considering is a cascading series of telescoping tubes on a pivoting arm. In a similar way to how a cascade elevator system works, the inner tubes would use a cabling system mounted to a fixed point to move the inner tube in the telescoping series up and down, but instead of the original power coming from the linear motion of an external elevator stage, I want the power to come from the pivoting of an arm the telescope is mounted on, and I want to be able to parameterize the design so that I can get any amount of internal stage lift from any amount of arm pivoting motion (or at a bare minimum, find out what are the reasonable ranges for such). I think I'm going to make that its own project and play around with some ideas for that separately.
That aside, here's an update on the main robot sketch:
These "master sketches" aren't too pretty, but they help me quickly iterate dimensions and geometry without the need to jump to 3D parts. On the left is the top view, which really just helps determine the drivetrain shape. Sometimes I'll add details onto it from other subsystems if I need to, but for now I haven't needed that much extra detail on that view yet. The middle is the "front" view, showing the robot from the side that I call front/back. On this view you can see the intakes and their varying positions, as well as the central feeding and indexing system at the center of the robot that will reorient the balls from an unorganized volume into a single-file line, ready to feed into the ejection mechanism. The right frame is the "side" view of the robot, showing the feeder system and ejection mechanism and how they interact with each other. This view also has the low bar latch system and a rudimentary climber sketch on it. In order to climb, my robot will effectively drive up the ramp and latch itself onto the low bar in order to stay in place on the ramp, and then extend the climber mechanism towards the upper bar. By going to the top of the ramp I can decrease the distance my climbing mechanism needs to travel to get to the upper bar, which in turn decreases the size my climbing mechanism needs to be into something that can reasonably fit into my frame perimeter without need for extension.
Of course this is all theoretical and this robot isn't being built so I have no way of knowing how reasonable some of my design guesses are, so I'm just going with my gut on what feels is relatively possible.
Once I got to a point on the 2D sketch that I was comfortable with, I started making the move to 3D. I tend to caution my students to not move to 3D too soon, but when they ask "what is the right time to move to 3D", I don't really have an answer other than "you reach a point as the designer where you feel you've gotten enough out of 2D to build a strong foundation, and then you start 3D". For me, I never really leave 2D to go to 3D modeling, I just reach a point where I include 3D modeling in my design process. I always go back and forth between 2D and 3D, because each one gives me more information that I can better use on the other, and vice versa. It's an iterative process. You start in 2D, then reach a point where doing things in 3D would give you more information on how to best move forwards with the design, so you start doing 3D, then as you complete more detail-work in 3D you return to 2D to further iterate on the parts of the design that haven't been done in 3D yet, which gives you more details to work with on the current (and future) 3D parts, and then it's back to 3D, then back to 2D, over and over and over again until the design is "done".
First I modeled the drive system in 3D, utilizing the dimensions I had derived from my 2D sketch.
This drivetrain utilizes 4 WCP brushless swerve modules on an aluminum tubing frame made of 2x2x1/16", 2x1x1/16", and 1x1x0.040" tubing, with hole patterns for mounting purposes. The unique shape came out of the design of the ball ejection mechanism that will sit inside the frame cutout on the right hand side of the image. I used 2x2 tubing for the outer frame because while I was on FRC 1323, we found that using 2x2 tubing on our swerve frames gave us more mounting room in the corners of the frame as well as space for mounting bumpers that didn't get in the way of mounting mechanisms. I think it's a worthwhile tradeoff that can open up the design space when using a swerve drive system.
Next I modeled the ball ejector mechanism. I actually designed the entire system using details I put in my main sketch as a stencil of sorts. This is a process I use pretty heavily and is part of why I put so much effort into making a sufficiently detailed main sketch. The main downside of this method is that if you update the main sketch, you need to update the relevant parts that are based off of that sketch that utilize the sketch elements you updated. Ultimately this is just a hacky way of doing top-down design, but until I make the move to onshape (or find a better way of doing this in Solidworks that doesn't crash all the time) I'm gonna stick with this one.
My ball ejector mechanism works similarly to the standard FRC flywheel shooter mechanism, but flipped upside down. It still uses a high-inertia flywheel to accelerate a ball along a curved path backed by a hood, but instead of launching the ball into the air, the ball is released tangent to the floor it is on, rolling the ball with (hopefully) enough power to roll up the ramp and into the goals. There is a 2" roller above the flywheel that holds balls in place until the flywheel is up to speed, and will spin, feeding the balls into the flywheel with the belted feeding system once the robot code determines that the shot criteria are met. I got decently far on the 3D model of the subassembly, and plan to finish some more of it in the coming days. I'm still on the fence about whether I should pocket the large 1/4" aluminum plates that make up the ejection mechanism. Realistically this robot should be pretty light, and the plates are low enough that I don't think they'll negatively effect my center of gravity (they may even help it). Pocketing the plates will make them lighter, and potentially look cooler (which is always nice), at the expense of increased machine time, which in real life is a serious consideration of value. While this robot isn't being built, I want to design it as if it were. Luckily I don't need to decide this now, so I'll come back to it later.
These are more or less the main subsystems I have started 3D work on. There's a small gearbox for the feeder I've put some effort into but I don't think it's of enough importance to go into detail on right now. Next step is either gonna be the intakes or refining the feeder system. I'm not gonna touch the climber for a short bit while I think about that cascading telescope idea. I think there's a lot of useful potential there, but it needs some more marinating time.
