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.

What I worked on

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.

Beyond that: motor assembly, and sheet-metal fabrication for the structure around it. Pneumatics, wiring looms and a brain with more ports than you would like to trace at eleven at night.

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.