Thirty seconds you cannot touch

Head to head

Thirty seconds of autonomy, then sixty seconds of driver control with match loading allowed. The autonomous period is where matches are quietly decided: it runs blind, against an opponent doing the same, and a routine that works on a clean field at midnight can fail on a scuffed one at nine in the morning.

Skills

Separately there is a skills format — sixty seconds of autonomous coding with no driver, sixty seconds of driving, three attempts each, added together and posted to a worldwide leaderboard. You have to clock the score at a real event. It is the part of VEX that rewards patience rather than tactics, because you are competing against a number rather than a person.

The brain casing

I built the protective casing for the robot brain — the controller that holds the program and every port going to a motor or a sensor. It is the single component you cannot afford to have knocked loose in a collision, and on a machine that spends its life being rammed by another machine, collisions are the design load rather than the exception. A casing that merely holds the brain in place under gravity is not a casing; it is a shelf. The question is what the mounting does on the third impact, not the first.

The failure it prevents is also the one hardest to diagnose afterwards. A port shaken loose mid-match does not announce itself — the robot simply stops doing one thing, the log looks fine, and whoever wrote that subsystem spends the evening reading code that was never wrong.

Pneumatics

Air is stored, regulated, and released through solenoid valves into cylinders — a regulator and gauge setting the working pressure, push-fit fittings and tubing carrying it out to each actuator. What pneumatics taught me is that the interesting failure mode is gradual rather than sudden. A fitting that leaks slightly does not stop the robot; it quietly lowers the pressure available later in the match, so the mechanism that worked in testing becomes the mechanism that is weak in the final thirty seconds. You cannot debug that by watching one run.

Motors, sheet metal and the frame

Motor assembly and sheet-metal fabrication for the structure around it, plus wiring looms and a brain with more ports than you want to trace at eleven at night. Frame work is where tolerance stops being an abstraction: a bracket that is two millimetres out is invisible on the bench and becomes a drivetrain that pulls to one side over three metres of field.

What the routine has to do

Our autonomous code branches on alliance colour, then goes looking for the right blocks by detection class — red if we are red, blue if we are blue — before driving a measured path and taking them in. Motion runs on PROS with LemLib underneath, so a move is expressed as a pose and a target point rather than a guess at how long to run a motor.

The part I like

The intake does not have a sensor telling it whether a block went in. It has current draw. When the motor is loaded, it pulls more; when the block is seated, the draw falls away again. So the routine watches the current, waits out the first few hundred milliseconds of noise, and treats a sustained drop as confirmation. It is a sensor made out of something the motor was already telling us.

The problem

A camera does not see straight. Every lens distorts, and every camera is mounted at a slightly different height and angle, so before vision is worth anything you have to measure two things: how the lens bends the image, and how a point on the floor maps to a point in the frame. You measure both by photographing a checkerboard, carefully, many times.

We run three robots. Each needs its own calibration, and some need more than one — a mapping for the ground plane and another for when the camera toggles position. Which meant a folder of files where the wrong one loading silently is worse than none loading at all, because the robot keeps driving and simply believes something false.

What I changed

I reworked the file pathways so each robot resolves to its own calibration explicitly, and I put the calibration files into backup. That second half sounds trivial. It is the half that matters: a calibration takes an afternoon with a checkerboard to produce and a careless moment to lose.

The calibration tree

camera_calibration/
├── camera_calibration.py    # shoot the checkerboard
├── camera_check.py          # verify a calibration
├── config.yml
├── Calibration Checkerboard.png
├── Hehe_robot/
│   └── camera_distortion_calibration.yml
├── huang_robot/
│   ├── camera_ground_homography_calibration.yml
│   └── camera_toggle_homography_calibration.yml
└── jetson_robot/
    ├── camera_ground_homography_calibration.yml
    └── camera_toggle_homography_calibration.yml

That term's log

• 22 May
  Camera calibration. The pathway rework and the backups.
• 29 May
  Override template. A clean clone, a first attempt at mains, then a new template.
• 3 June
  Updated main. Template and entry point brought back together.
• 4 June
  New robot move. Motion primitive rewritten.
• 5 June
  Full override testing. End to end, on the field.