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.

Tasks:

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).

Constraints:

• 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.

Planned Features:

• 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

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.

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!!!!