^ Robot V1 ^
This is where it all starts, the CAD.
First, we needed a plan.
Since it’s a team effort and I’m the CAD manager, we decided to hold brainstorming meetings for the hardware subteam. While generating ideas, we kept our design requirements and constraints in mind.
For this year’s game, CenterStage, the robot must complete a few key tasks:
Pick up game elements (called pixels) and accurately place them on an angled board.
Compete during an autonomous period where many points are available.
Operate during a driver-controlled period.
Perform in the end game, which includes launching a paper airplane (drone launcher) and hanging (suspending the robot).
Robot must fit within an 18in³ volume.
Must use GoBilda electronics (hubs, batteries, DC motors — except for servos).
No sharp edges allowed.
With these tasks and constraints defined, we could begin brainstorming the features needed to accomplish them.
Rigid frame design
Simple drivetrain
Active, actuated intake
Angled slide system
Paper airplane launcher
After our brainstorming meetings, I began working on our CAD. The goals were: to keep our parts tree as simple and organized as possible, to go through the effort of CADing the fasteners, and to implement the required features while staying within our constraints.
The first thing I wanted to finish was the drivetrain. The key elements I implemented into the drivetrain were:
A steel baseplate for rigidity (which later became one of our main issues)
Four 19.2:1 motors
Four mecanum wheels, belt-driven to reduce backlash
Custom odometry pods for accurate robot positioning
Odometry Pods
The goal when designing these odometry pods was to improve the mounting capabilities of the already bad enough REV odometry pod. To do this, I designed a custom case that is easily 3D printed. It constrains the omni wheel on both sides using bearings to keep the motion smooth, and it includes two additional bearings near the cable plug to allow for easier mounting. (To mount, you just need two standoffs and a spring.)
To my surprise, I toleranced the parts correctly for 3D printing. My general rule, based on my measurements, is that PETG tends to increase in dimension by about 0.1 mm on horizontal surfaces. Knowing this allowed me to account for it in my design, which led to the assembly going together quite well on the first try. That’s not to say all the parts were perfect—I ended up finding a different solution to attach the spring instead of using the tiny loop. However, I left the loop in the design just in case I wanted to change the configuration later.
The reason we don’t have to worry too much about the absolute accuracy of the encoder is because what really matters is the linearity of the measurement. As long as the measurement per degree is linear, we can scale it accurately to match the actual distance traveled. This is useful because it means I can focus on building the pods mechanically and let the software handle the calibration and scaling.
Here is the Slide Assembly and my slide calculations
Here is V1 next to V5. The key difference is that instead of using two linear bearings, I switched to just one, since the linear application didn’t require that much support. In V5, I was still unhappy with the overall width of the design, as it interfered with the drivetrain motors. However, switching to a single bearing led to a genius idea—one I should have thought of earlier: using the baseplate as structural support. This decision simplified many of the force calculations and helped me optimize motor selection, ensuring the system would function properly on the first try.
This is the start of the ball screw actuator the actuator is using a 135mm long 16mm ballscrew 5mm pitch.
Slide Assembly
The slide assembly is the most complex subsystem on the entire V1 robot. Considering the part count and the strength and rigidity I wanted, I initially opted for MGN15 slides from Zyltech. However, once I accounted for the mass, I realized the resulting force would likely cause the robot to tip over. To design a lighter system, I analyzed several options by evaluating the static torque of different slide configurations. I ultimately chose MGN9 slides, which offered a better balance of weight and stability. I then used related rates to calculate the minimum torque required to move the slide system at 10 degrees per second. Doing so allowed me to decide what motor to use.
Designing The linear actuator:
Designing the linear actuator to angle the slide system was quite tricky. I went through six iterations before settling on a design that was compact enough to fit within the available space.
V6 Linear Actuator (Using the Baseplate for Support)
Next, for the slides, I implemented a spool system that can extend and retract the slides while being actuated by the ball screw.
I created a main hub that houses a large bearing and can be tapped to mount the slides using eight M3 screws. The spools are driven by a motor that turns a spool connected to a 48-tooth gear, which then drives a 36-tooth gear in the opposite direction. This second gear is mounted on a shaft with a smaller return spool, which is ¾ the diameter of the main spool to match the gear ratio.
The actuator attaches in the center of the system. Once again, I take advantage of the steel baseplate's rigidity to support the entire assembly.
Designing the slides:
Using what I had already determined from my theoretical calculations, I now needed to actually design the slides. With MGN9 rails from Zyltech, I built on ideas from Rogue’s previous year’s bot and used 3 mm plate to create a similar system— just with continus stringing. By using plate sandwiching and 90° threaded mounts, I designed a simple slide system that is easy to string, includes built-in end stops, and is (supposedly—more on this in V2) rigid.
Designing the intake/extake:
This was the most challenging part of our robot to design. The difficulty came from overthinking the problem—if you try to do too much, you end up with what I designed.
Design Process
Constraints:
Must fit within 18 in³ when folded
Can pick up no more than two game pieces
Desired Features:
Strong
Adjustable (via servos)
Lightweight
With these constraints and features in mind, I began brainstorming. One idea was to use counter rollers to grip the sides of the game pieces, while plastic brushes applied force toward the rollers. The friction from the rollers would then lift the game pieces upward. From there, I wanted to use a conveyor belt system to funnel the pieces into the intake.
CAD and Manufacturing
Once the concept was laid out, I moved into CAD. Because of the limited time before competition, we were forced to begin manufacturing right away to ensure the robot could score. This decision left little time for testing and caused me to overlook some simple issues that could have been avoided.
The main issue came from the conveyor: the rubber bands I used to create a sliding surface for the pieces ended up creating too much friction because of their sheer number. This forced me to redesign after the fact, replacing the counter roller with a scrubber and wedge system, which ultimately worked.
The extake was fairly simple—a 3D-printed box with a servo that locks the game pieces in place and releases them one at a time. There was no need to overcomplicate the design.
Lessons Learned
While there is still much room for improvement, I learned a hard but valuable lesson here: don’t begin building until you’ve fully tested a concept—even under competition pressure. Also never neglect weight!!!!
This was one of my favorite parts of the event because of its simplicity—and because we turned out to be quite good at it. In fact, I didn’t realize just how good until someone sent me a DM saying we had placed 2nd in the world for this event.
I had originally assigned this project to a teammate to fully design the system and plane. However, due to time constraints, I jumped in to help. From my observations, I noticed two common issues with most planes:
Excess horizontal velocity caused them to slide too far upon landing.
Excess vertical velocity caused planes to take more damage on impact, which led to inconsistent launches.
My theory was that the ideal flight path would be a parabola that gradually steepens during the second half of the motion, limiting horizontal velocity on landing.
For inspiration, I looked at space re-entry vehicles such as NASA’s Apollo Command Module from the Saturn V rocket. When re-entering the atmosphere, it approached at an angle to reduce speed, primarily in the horizontal direction. Applying this principle, we aimed to design a paper airplane with small drag wings to encourage it to flip backward and “ride” air resistance during descent.
I shared 2 videos of the second half of the flight path to illustrate exactly what I mean.
With help from my teammate in completing the launcher, we were able to put everything together and tune our system to the point where we held #2 in the world for the paper airplane event for a until we got knocked out at semi-reigonals.