Our DECODE robot did not arrive as a finished idea. It developed through prototypes, measurements and the practical lessons of competition. J.A.R.V.I.S. combines mechanical design and software around one aim: acquire artifacts efficiently, manage them predictably and score consistently.
One week, one working prototype
Our first functional robot, “7days”, was built in a week for the first demo. It used a compliant intake, a single-motor transfer and a servo-operated gate. Two shooter wheels without a hood gave the team an early reference, but left-to-right shot inconsistency showed where development was needed.
A more integrated machine
The later design combines a dual intake with a three-element storage system and a rotating turret. Passive fenders guide artifacts inside the robot, while a structural support nicknamed the “Second Floor” helps prevent the shooter lifting after contact.
- Dual-sided collection reduces the manoeuvres needed to acquire artifacts.
- Custom plates use a Voronoi pattern to reduce weight.
- Mechanical and software changes are tested together rather than treated as separate projects.
Engineering as a process
The team begins with the game manual and scoring analysis, develops concepts in CAD, prototypes and tests them, and integrates validated subsystems. The final step is not simply assembly: mechanisms and control software are tuned together under realistic conditions.
Intake & Intelligent Storage
The intake and storage systems are designed as one flow: collect an artifact, guide it into a known position, identify it and release it when the scoring routine needs it.
A dual-sided intake
The robot collects from both sides to reduce unnecessary turns and repositioning. A steel transmission plate carries power from one motor to both intake shafts through a bearing-supported system.
- Eight gecko wheels on each side provide contact with the game elements.
- Ten PETG spacers on each side maintain alignment and reduce lateral play.
- Passive guides help keep artifacts on a predictable path.
Three positions, six sensors
Each of the three storage positions uses two colour sensors. Infrared distance is checked first to confirm an object is present; colour is read only after confirmation. The team’s analysis estimates that a single sensor could look through a hole in the 18-hole artifact around 5.6% of the time, compared with about 0.3% for the dual-sensor arrangement. These are geometric estimates, not independently measured match statistics.
Keep the control loop available
The second sensor is queried only if the first does not confirm detection. Polling is limited to 10 Hz per position, reducing unnecessary I²C transactions and preserving processing time for drivetrain and turret control.
Aiming, Flywheels & Shot Consistency
The turret and shooter combine mechanical alignment, sensor feedback and software tuning. The objective is a repeatable shot from a known position, with recovery between launches and adjustments for changing conditions.
Closed-loop turret aiming
The design uses a 435 RPM motor, a 29:113 belt ratio and a REV Through Bore Encoder rated at 8,192 counts per revolution. Together these provide about 31,920 encoder counts per turret revolution. The stated ±0.006° is a theoretical quantisation figure, not measured aiming accuracy.
- PID control includes a minimum-power threshold.
- Angular-velocity feedforward helps compensate when the robot base rotates.
- Localisation and AprilTag observations support target alignment.
Eight physical shooter prototypes
Three major generations shaped the design: a fixed 45° three-wheel arrangement, a larger 96 mm bottom-wheel version, and a dual-6,000 RPM flywheel system. Testing exposed trade-offs in energy transfer, backspin, material friction and durability. We tested several wheel configurations across these iterations.
Velocity control and an adjustable hood
Combined encoder deltas and a five-sample median filter reduced recorded RPM noise from roughly 200 RPM to about ±10 RPM in the team’s testing. PID and feedforward help compensate for load and voltage changes, while distance-based lookup tables select targets. The current hood is described as adjustable from 35° to 55°, with RPM-loss compensation intended to improve consistency.
Chassis, Drivetrain & Feeding
Reliable scoring starts with a stable chassis and a predictable transfer path. Our hardware work connects structure, transmission and artifact handling rather than optimising each part in isolation.
A stable mechanical platform
Drivetrain motors are supported between a structural plate and a second plate near the shaft. The team uses an aligned and tensioned belt transmission to distribute power to the wheels. A printed guide keeps artifacts elevated and reduces the chance of jamming inside the intake.
Seven shovel iterations
The feed mechanism uses three custom CAD-designed and printed shovels. Their curved profiles were refined through seven iterations to guide artifacts into the flywheel with less variation.
- A Swyft Speed servo drives the system.
- A 2:1 gear ratio is used for angular velocity.
- Individual, sequential and colour-based activation support different scoring tasks.
Choose parts for the season, not just the first match
The team compared servo options using speed, reliability, maintenance and replacement needs. The team selected Swyft Speed as the preferred solution for fast mechanisms. The comparison is a record of the team’s application and experience, not a universal product ranking.
Autonomous: Composable by Design
Autonomous development is built around readable, non-blocking actions. Instead of one long sequence of hard-coded steps, the team composes smaller behaviours that can be changed, tested and combined.
Actions that work together
The codebase integrates Pedro Pathing with actions for following trajectories, updating pose and holding a point. Sequential, Parallel, Race, Sleep and Instant primitives form larger routines. AutoBase keeps these updates coordinated with the main control loop.
A routine for the match plan
The team developed close-side and far-side routines, with gate and non-gate variants. The options trade scoring volume, reliability and the work left for an alliance partner.
- Close-side two-line and three-line options, including gate variants.
- Far-side one-line and two-line options, including a gate variant.
- An Auto MTI routine targets all 15 pre-existing artifacts and up to three additional artifacts.
Targets remain targets until demonstrated
We planned a possible 36-artifact autonomous collaboration with Sirius #25482 for the Istanbul Premier Event. This is presented as a planned alliance strategy, not an achieved competition result. The Auto MTI figure is likewise a routine’s stated potential, not a published match score.
Software That Keeps the Robot Responsive
Our robot software is organised around modularity, composability and a clear separation of responsibilities. The team’s Kotlin codebase gives each subsystem its own lifecycle and keeps time-sensitive behaviour within a coordinated control loop.
One component lifecycle
Subsystems share init(), start(), loop() and stop() methods. A component registry lets OpModeBase initialise and update them in a consistent order; bulk caching and unified telemetry help the team observe the robot as a complete system. Dagger 2 provides compile-time dependency injection.
Control at the right moment
Flywheel speed is calculated from encoder deltas, filtered and controlled with PID plus feedforward. Colour sensing is requested when the feed mechanism activates, reducing unnecessary I²C traffic. If all three storage positions cannot be identified reliably, the feed logic falls back to sequential activation.
- Colour-based commands reduce driver workload.
- Pattern-based activation supports MOTIF scoring.
- Field-centric mecanum control, slow mode and intake reversal support teleoperated driving.
Sensors with a purpose
The documented sensor stack includes a REV Through Bore Encoder, odometry pods, a goBILDA Pinpoint computer, REV Color Sensor V3 units and a Limelight 3A camera. Each supports a specific decision: speed feedback, localisation, artifact identification or AprilTag alignment.
What the season taught us
Low loop times matter, and PID coefficients must be revisited when a mechanism or timing changes. Real-world units make control code easier to understand, while subsystem-local tuning constants make the robot easier to maintain.
