Continuing on the 2019 retroactive build thread I posted a few months ago, I found a similar email conversation from the 2020 season. For those who didn’t see that post, this is my side of an email conversation between myself and the mentors of my high school team covering Galaxia 5987’s progress through the season. This was the first year of the Open Alliance, but it was a closed group limited to the founding teams and we were not one of them.
Here are the robot book and reveal video from that year. Of course due to COVID we never got to see how the robot would fair through the competition season, but according to the statistics we had one of the top robots in the Israel district and I’m confident that we would have advanced to the Championship had it occurred.
Jan 4:
Hope you enjoyed kickoff today. I’d love to hear what you guys are thinking strategy-wise; it’s a pretty complex game. Seems like a team that can quickly cycle power cells to the 2 point goal and plays good defense without bothering with any other game tasks could be a very good alliance partner. Keep me in the loop with how your build season is going.
Jan 5:
We haven’t really started game analysis yet because kickoff here is at 6pm so we spend day 1 just reading the manual. Based on what I’ve looked at so far though, I put a much bigger emphasis on shooting the balls than the other tasks. I remember in 2016 teams were generally pretty accurate shooting at the high goal from ~1/3 field away, and that was with a bigger ball and smaller goal. I think it’s very feasible this year for teams to shoot 2 point shots from at least the edge of the Trench Run, if not further back.
If you figure 18 second cycles shooting 5x 2 point shots in each, plus 5 pts for auton movement and 5 pts for parking, that’s ~90 points. And if you have an alliance partner who can do the Control Panel, they only need to score a few more balls to get the extra RP. Compare that to a low goal + hanging strategy, where hanging takes 30 seconds to score 25 points. If you get 5x 1 point shots in each 22 second cycle (longer because now you have to cross the whole field), plus 5 pts for auton movement, that’s only ~60 points. You can squeeze a few more points out if you add a Control Panel manipulator and have a good alliance partner so you can replace a shooting cycle or two with Control Panel cycles. But it wouldn’t be that many more points, and it would require adding a whole new mechanism.
So for my personal priority list, I’m leaning towards something like this:
Need -
• Drivetrain
• Ground intake
• Storage for 5 balls
• 2 point shooterWant -
• 2 point shooter from Trench Run or farther
• Climber
• Human player intakeWish -
• Middle of the bar climber
• Color disk spinner
• 3 point shooterSkip -
• 1 point shooterThe team starts debating this tomorrow, so we’ll see if the students are thinking similarly to me.
Jan 12:
After a good amount of passionate debate, we finally decided on a robot strategy. Our main goal is to be an accurate long range shooter. We hope that we can shorten our cycles by shooting from behind the trench if we’re cycling from our loading station or from about midfield if we’re picking up balls in the opponents’ sector. We chose to make a tall robot that can’t go under the trench in order to get more distance on the shooter, to not need to extend up as far to climb, and to make packaging easier. We are also putting the shooter on a turret so that we can shoot quickly and more accurately instead of having to line up using the drivetrain.
We’ve done a good bit of prototyping since finalizing our strategy. What we’re learning is that the hardest part of this game is probably going to be reliably intaking and manipulating these balls. They’re very squishy so they squeeze into the tiniest gaps in the belt system, and they’re very friction-y (especially between one another) so they like to stick against anything not moving with them. We’ve had a lot of difficulty designing an intake that centers the balls as it intakes them. We’re making some progress, but probably still a few iterations away from something workable.
Our initial shooter prototypes are looking pretty promising. We’re getting decently accurate shots from about 18 feet with a pretty simple hooded flywheel shooter. The back of the trench is ~30’ from the target though, so we’ll need to do some more testing. We’ve been getting pretty good at quickly designing and cutting plywood prototypes with our CNC router and that’s helped us tremendously with quick prototype iterations, especially for the shooter with so many variables to change. Here’s how our progress looks at the moment.
For climbing, we have an idea for two single-profile elevators that extend up with hooks to grab on to the bar. In theory, we should be able to change the robot’s center of gravity and help level the switch by changing the relative heights of the two elevators. I’m not 100% convinced it will work so we’ll hopefully be making at least a small scale prototype, if not full scale with a previous year’s robot. I put a strong emphasis on making sure that we can mechanically connect both gearboxes and end up with a “single” elevator climber if we find that this system is too complicated, hard to control, or not necessary.
The wheel of fortune seems like the easiest task of the year. Our first prototype worked just fine to spin it even faster than top speed. Other than slowing it down to just shower than the max speed, the only real change we made from the first prototype is to allow the whole mechanism to rotate and have it spring return to center to allow for a lot of driver misalignment while still contacting the wheel in the right places.
We’ve started CADing our drivetrain, and in the end it looks like we will also go with a shifter. The students believe that the game will have significant defense and we’ll need to be able to push robots out of our way at times. So we’re designing the drivetrain with one “normal” ratio for 95% of our driving and one “pushing” ratio for battling against defense. I’m still not thrilled with the idea of a shifter, but this poses a much lower risk than a drivetrain that regularly shifts between gears, and if need be we can lock the gearbox in “normal” gear and we’ll be just fine.
I’ll try to take some more pictures/videos at the next meeting to show how the prototypes are coming out.
Jan 13:
Our intake prototypes are coming along. See a picture of our current iteration and a video of the last iteration working below. These mecanum-based designs don’t work too well when you put in more than one ball at a time though. Tomorrow we’re going to try prototyping a different style intake, with a straight roller to bring the balls over the bumper then a funnel system to line them up into the belt system.
Here’s a video of the current shooter prototype, which shoots a good bit farther than the last. Unfortunately, shooting the ball in that configuration put the motor under a lot of stress and it burned up a few shots later. So we still need some more iterations before the shooter is ready for competition.
For the problem of connecting the two sides of the lift, we are planning on running a long hex shaft through the base of the robot underneath all of the other mechanisms to connect the two gearboxes. For us we will disconnect the gear on one side of the hex shaft to uncouple the sides but keep the shaft in so we can connect the sides by simply adding the gear back in. This seems like an easier solution than connecting the actual lift carriages themselves so we don’t have to clear space for a cross member right through the center of the robot.
Jan 19:
Somehow we’ve managed to keep the schedule we planned before kickoff. We finished up prototyping for the most part a few days ago, and we should be done CADing the robot by tomorrow or the day after. All that’s missing at this point is the turret and shooter, where we’re still trying to nail down the best geometry for our shooter.
We were really struggling with our intake and ball movement using the mecanum wheels to align the power cells. The balls are just so squishy and grippy that they’ll go anywhere except where we want them to. We took a step back, tried looking at the problem from another angle, and ended up with something a lot better. We now have an over-the-bumper intake with regular compliant wheels that brings the ball in straight. Then we have two vertical rollers on a small ramp right behind the bumpers that center the balls and push them into the belt system one at a time. We’ve tested this with up to five balls at a time from all different angles, and it hasn’t had any problems. Here’s a video showing one of the prototypes in action (the final geometry is a bit different).
Our shooter prototypes are starting to get closer to our target specs. We still have to test a few different configurations in the next few days that we think will improve our shot distance. Right now we’re scoring pretty well from a bit over 27’. Our goal is to be able to extend that to 35’+ so we can shoot from the far side of the trench and have very short cycles to the human player station. We were originally considering adding an actuated hood that we can change the angle because we want to be able to shoot from such a wide range of shot distances, but we’ve found that the shooter that works from far distances also works from the initiation line or closer just by changing the wheel speed.
As has been the case for the past few years, our climber is probably the worst designed mechanism on the robot. There’s a joke going around the team that this will be the third year in a row that we’ll have to remove it because the robot weighs too much; hopefully this won’t be the case. Our plan is still to have the climber split into two separate single profile elevators that can each go to its own height and lift the full weight of the robot. If we can manage to program it correctly this should help us stay steady on an unbalanced switch and be able to make small adjustments to the switch angle if we don’t line up to climb properly.
We came up with a pretty cool solution for a braking system to hold the climber after the match ends: it’s a hex hub with rubber on the face that gets pressed into the gearbox plate by a pneumatic piston. When it’s unactuated, the hub spins normally with the shaft. When it’s actuated, the piston pushes the hub into the gearbox plate making a friction force, which travels through the hex hub into the gearbox shaft and holds the system in place. An internal snap ring lets the piston retract the hub. We calculated that each of the two brakes should be able to hold about 225 lbs at full pressure.
Jan 26:
We finalized the robot design on Wednesday. Here’s a picture of the final design (minus a few lightening patterns in the turret):
Since then we’ve made pretty good progress manufacturing parts. Despite having a number of small problems with our CNC router, we’ve managed to cut all of the polycarbonate sheet, HDPE sheet, and 2mm aluminum plates for both robots. We’ve also cut all the tubes we need to length and finished manufacturing all of the parts on the lathe. We have to finish the 5mm plates and mill all of the tubes, and then we can start assembling. In order to get the most out of each sheet of material we have to play a bit of Tetris. This makes for some pretty cool layouts:
Right now the robot weighs about 93 lbs (including electronic components) according to the CAD model. I’m hoping it’ll stay around 100 lbs in reality once we add wiring and tubing. That should give us a bit of an acceleration boost to help us move around the field quickly.
Today I discovered that our shooter flywheel was designed pretty unsafely. We had it actually overdriven 2:1 from 775pros, putting it at ~30k rpm at full speed. That’s about double the rated speed of the bearings supporting it and gave it the same kinetic energy as an anti-tank rifle bullet. Today we played around with the design to find pulleys that gave a lower ratio but kept the same center-to-center distance. We ended up with the flywheel on a 1.4:1 reduction putting it at a more reasonable 13k rpm. That’s still the same kinetic energy as a bullet from an AR-15 though, so we need to be careful to properly shield it and keep strict safety precautions.
Feb 3:
I haven’t been to meetings this past week because my finals season has started so I need to spend time studying (unfortunately). I had one test this morning, so I made it to a meeting this afternoon. We’re more or less done with manufacturing parts, and have started assembling.
Once we figured out some manufacturing problems, we’ve had two major problems with assembly so far. The robot we designed has a lot of timing belt pulleys of various custom sizes, and the plan has been to 3D print them. But we’ve found that our custom pulley CAD generators aren’t working great, and the settings we were using to print them weren’t great making the belts over-tensioned. So we have to re-print a lot of the pulleys, which is delaying our final assembly of a few mechanisms. The other problem we are having is that we had designed the robot to use about 20 plastic bushings in the conveyor and serializer, which we had never used before but should have worked according to the specs and would save us more than a pound over bearings. But when we actually tried to use them, we found that they had far too much friction for our application. We know from other teams’ experience with them that they should work for something like this, but we’ve decided to switch to bearings anyway because we don’t want to waste time fiddling with them. Unfortunately that means we need to remake a number of parts in the conveyor system, which will delay us by a day or so.
At one point today we had our drivetrain, intake, and serializer assembled and connected. Those three mechanisms have come together pretty smoothly for the most part so far. Unfortunately we had to disassemble them to deal with the bushing issue, so it’s a bit of a step backward.
This is (one side of) our climber. The right and left tubes are attached rigidly to the frame, and the middle one slides vertically like an elevator. Eventually it will get a hook at the top, but that hasn’t been manufactured yet. The elevator is actuated up by a constant-force spring, which shoots it up in less than a second. Then a rope (that we have yet to buy) will pull it back down. At the bottom on the right side is the gearbox attached to the elevator drum, which will spool the rope. On the left side is the pneumatic brake. The pancake piston is attached to that hub through a bearing, so the hub slides on the gearbox shaft sticking out the side. When the piston is activated, it pushes the hub (which will eventually have a grippy rubber covering) into the gearbox side plate, stopping the gearbox from rotating.
Here’s the shooter and turret system. It’s driven by three 775pros, but those pulleys will need to be replaced because of our 3D printing problems. We need to get that finished and wired ASAP so we can test the final version, since it has a few major changes from our prototypes. The shooter has a pretty substantial flywheel to maintain speed between shots, which was manufactured by our defense contractor sponsor. You can also see the “flipped” turret, where the circular bottom plate is rigidly attached and the star shaped top plate spins around it on bearing sandwiches. So far the turret works very well; it spins with little friction and almost no backlash.
Feb 3:
[Editor’s note: in response to a question about the elevator brake]
I’d also love to see the climber brake working. We’re waiting to get the rubber coating for the hub that will provide the friction, until then there’s no braking force. According to the calculus, each break should be able to hold ~150% of the robot’s weight, but we won’t really know until we try it. Apparently the students got the rope attached during school today, and they’re beginning to test the pull up and pull down action. Here’s a video of it lifting ~50 lbs on a pull up bar.
The robot will have two independent lifts, one on each side of the robot, each capable of lifting the entire robot’s weight. We can’t reach the full 79" to the top of the climbing bar when tipped away from us; we can get up to about 75", which means we would need to grab the bar with the hook on the lower 70% of its length. I’m hoping this will be good enough. We made sure that even if we’re hanging with only one hook on the end of the low side of the bar we should be able to lift up high enough so that even when the robot swings out it should still be off the ground. I don’t remember the exact numbers, but the geometry was pretty easy to accomplish using a 2D CAD sketch.
The flywheel is stainless steel, it weighs about 2 lbs and has a MoI of about 6 lb-in^2. It was originally going to be made from brass with a larger diameter which would have given us a higher MoI for less weight, but we couldn’t get the raw materials in time. The flywheel is offset from the shooter wheel because it is connected with a ~2:1 overdrive belt ratio. Since the energy stored is based on the square of the velocity, this should give us ~4x as much stored energy for insignificant weight gains. That is also the reason we have so many motors on the shooter: the large effective MoI of the flywheel means it takes a lot of power to spin up the shooter in a reasonable time. I too was curious whether the flywheel will act like a gyroscope to stabilize the turret. We may find that it takes more power to spin the turret when the flywheel is spinning than when it is not. The flywheel hood is constructed from a few sheets of HDPE cut on the router into the curve shape and laminated together. Here’s a picture of one slice, and a view of the assembled shooter that better shows how it’s constructed.
Feb 4:
[Editor’s note: responding to a note that 3 redline motors on the shooter is probably overkill]
3 Redlines is definitely a lot of power. We want to be able to make the 2/3 field shot five times in a row without having to wait for the shooter to recover every time, which meant we needed to store a ton of energy in the flywheel. In order to get all that energy into the system in our 3-4 second spinup time requirement, we need a lot of power. We also had the PDP slots to allocate (rest of the robot only needs 11 slots), so we figured we might as well. If we find it’s too much it’s a lot easier to remove a motor than to add one.
I had mentioned before that we were having problems with our 3D printed pulleys being off-dimension this year. Rather than take up precious time on our printer, which is currently backlogged, we decided to make the pulleys on the CNC router. We had a number of 20mm HDPE sheets donated from a sponsor that weren’t being used. Our conveyor system uses about 40x 36mm wide 24t pulleys to move the balls around; each one is wide enough for two 15mm belts side-by-side to transfer power through the system. So we designed the pulleys to be in two parts, each side with one belt and a flange, and then bolted the two sides together. The results came out great; they’re much stronger and better toleranced than the previous 3D printed versions, and we saved almost 48 hrs of printing time in less than 2 hrs of CNC time.
Feb 7:
I managed to get away from studying today and make it to a build meeting. The mechanical team finished the assembly of the practice robot this morning before I arrived, and they handed it off to the electrical team. Most of the mechanisms on the robot seem to work. The main problem we are facing is with the conveyor system. For some reason the belts have a lot of internal friction, so the BAG motor isn’t strong enough to power them. We’ll need to spend some time to figure out where the friction is and how to get rid of it, but I have a feeling part of the solution will be to replace the BAG motor with a stronger 775pro. We’re running a few days behind schedule, so we decided to hold off on assembling the Control Panel manipulator for now so the rest of the robot can get moved forward. Here’s a picture of the mechanical assembly of the robot when it was handed off:
The electrical team spent all day today wiring the robot; eight hours later, the wiring is all but done. Our original solution for running wires to the turret didn’t work, so we had to come up with a new solution. We ended up going with something much simpler than our original idea, just a relatively stiff cable protector that’s long enough to wrap the +/-170° the turret spins but short enough that it doesn’t get caught in anything. At this point the only electronics missing are the cameras, LEDs, and raspberry pi, which will all be added by the programming team. They should need another hour or two tomorrow morning to add the pneumatics, then the practice robot gets sent to the programmers to check that everything actually works and start testing code. Meanwhile the mechanical team should start assembling the competition robot tomorrow.
Editor’s Note: These closeup robot pictures weren’t included in the email thread but I figured I’d share them here anyway.
Feb 10:
Made it to another meeting today. We’re still running a bit behind schedule but the goal/hope is to have the competition robot assembled mechanically by the end of the day tomorrow. There’s still a lot to be done for it though, so I have a feeling it may take an extra day (hopefully not more than that).
We started testing the climber on the assembled practice robot today. With some basic open loop code (where the driver controls the power to each side independently) we were able to raise ourselves off the ground, hold for a second under motor power, then lock the brakes and hold indefinitely. It’s a good start, and I’m glad to see that the system works mechanically. Eventually we plan on adding closed loop control to automatically lower the sides together at the same speed while keeping the robot level. If we have extra time, we want to take that a step even further to be able to shift the force applied to each side to actively balance the bar. But we’re still a long ways from there. Meanwhile the brakes seem to be working well. We calculated that they should need 40psi to hold the weight of the robot on their own. We found today that when you add in the force needed to back drive the winch gearboxes the brakes only need 20psi. When the brake is released the robot falls to the ground relatively slowly because of this back drive force. We have a pretty significant leak in our practice robot pneumatics so we can’t keep 20 psi for more than about 2 minutes, but I don’t see why it shouldn’t be able to hold indefinitely if it can keep pressure. The hooks we designed need more precise alignment than I’d like and can only grab from one direction; I think we will end up replacing them for a slightly different geometry and double-sided so we can approach from forwards or backwards. We will also need to add some rubber or grip tape because the aluminum hooks slide on our bar when it’s angled.
We were able to fix the problem we were having with our conveyor system. We replaced the BAG motor with a 775pro and increased the gear ratio to give it enough torque to overcome the friction. This added torque then caused another problem where the balls would be pushed together too hard and start to squeeze out the sides between the belts. We fixed that by “pulsing” the conveyor on and off rather than running it continuously. This lets the balls in contact with one another expand and contract without being squeezed, while the balls not in contact will still travel up the conveyor. That’s let us take our first shots:
And since then we’ve been working on dialing in our shooter:
Meanwhile we found a new problem with our intake. The bumpers we were using to test our intake design were from last year’s robot, so they weren’t in the exact right place. When we tested with jumpers attached correctly, we found that the geometry is off so it doesn’t compress enough at some points and compressed too much at others. We’ll have to remake some plates to adjust for this. Not the end of the world, but yet another setback. We also found that the balls can bounce out during the handoff between the intake and indexer if the robot spins at the right (wrong) time. We’re trying to add some polycarbonate shielding to keep the ball from flying out, and we’re going to add some netting to keep balls from getting stuck in parts of the robot they shouldn’t be.
We continue to have problems with 3D printed pulleys. This time while the programmers were tuning closed-loop control, one of the main shooter pulleys had its teeth sheared off and then basically exploded. We remade the pulleys out of HDPE and should switch them out tomorrow. Bad things seem to happen when you spin things at 12,000 rpm. Even our bearings (that are rated for up to 16k) are starting to warm up after running continuously for a while.
Feb 17:
We’ve had some unexpected delays this past week. After we started testing our practice robot we found that some dimensions didn’t transfer well from our prototypes to the real design. Our intake wasn’t working well, and the shooter angle turned out wrong. We decided that we’d rather pause on assembling our competition robot to fix the problems with our practice robot first. That way we only have to assemble the competition robot once instead of iterating on two robots at the same time. We ended up splitting the difference between the first and second shooter hood angles to get a medium angle that works from just about everywhere on the field, and we’ve gone through another two or three iterations of the ball intake to get something that (hopefully) works well. The competition robot is all assembled now, and should be done wiring tomorrow.
Here’s a close-up picture of our climbing elevator brake system, and a sketch I drew to explain how it works to one of the parents. The black shaft and bearing are part of the climber gearbox, and the gray plate is one of the gearbox side plates. The light blue hub has a hex bore in it so it spins with the gearbox, and it also sits on the red bearing connecting it to the green piston. When the piston extends, the shoulder of the piston shaft pushes on the red bearing, which pushes on a shoulder in the light blue hub. That presses the hub into the face of the gearbox, keeping it from rotating and locking the gearbox shaft. When the piston retracts, the nut on the end of the piston shaft pulls on the red bearing, which pulls on the dark blue retaining ring and disconnects the hub from the gearbox plate. When the hub is disconnected it still spins freely with the gearbox shaft, but doesn’t make the piston shaft spin because of the red bearing. So far, it’s worked really well for us.
