Skip to content
Saim Hashmi

Capstone: two robots, and what happens when the leader dies

2026-09-23

My SYSC 4907 capstone plan: two small ESP32 cars elect a leader, I switch the leader off, and the survivor has to take over by itself. A Cadmium DEVS model is the specification.

Capstone: two robots, and what happens when the leader dies cover

This is where my capstone stands today. It is a plan, not a result. The build window is January to late March 2027, and I have not bought the cars yet. I'm writing it down now because the shape of the idea is clear, and the open questions are the interesting part.

The problem

Imagine a handful of small robots doing a job together. If the one in charge fails, the rest of the job should not stop with it, and nobody should have to notice and reassign the role by hand.

I am not building the warehouse or the rescue robot. I am building the smallest version of that problem that still forces a real answer: two robots, one of them dies mid-task, and the other has to notice and take over on its own.

The demo

Two identical ESP32 cars sit inside a foam-board square about 1.5 m across. They agree on a leader and creep through a scripted patrol at low speed. The leader sends a heartbeat. I flip the leader's power switch. The other car sees the heartbeats stop, elects itself, and carries on. Nobody types a command.

A laptop sits next to the table showing an overhead camera view and the model's trace. The election must keep working if that laptop is unplugged.

Where Cadmium fits

The wheels are a timed PWM pulse and the camera is an OpenCV script. Neither of those is the interesting part. The election is.

I'm modelling it in Cadmium, the DEVS simulator used in my supervisor's lab. One atomic model, Robot, is instantiated twice inside a coupled model. It has four phases: follower, suspect, electing, leader.

  • A leader waits 250 ms, then sends a heartbeat.
  • A follower waits 750 ms. A heartbeat from its leader resets the wait. If the wait runs out, it starts an election.
  • It then listens for about 500 ms. An election from a higher id makes it yield. If nothing higher shows up, it becomes the leader.

DEVS suits this because the protocol is a timer plus a message. The awkward case is when a heartbeat and a timeout land at the same instant. DEVS has an explicit transition for that, so the tie-break is written down once instead of being scattered through firmware. My current guess is that the timeout wins, unless a higher-id election arrives in the same instant. I would rather have a false alarm than miss a dead leader.

The model has two jobs. This fall it runs on the laptop with a driver that drops heartbeats, so I can check the survivor becomes leader before any hardware exists. After a hardware trial, I replay the timestamped radio log into a fresh model and compare the model's phase changes with what the real robot wrote to its serial port.

What I want to measure

The lab's earlier work on running Cadmium across two boards compared logs by eye. I want a small table instead: trials, recoveries, false elections, and median and worst skew between simulation and hardware. I'm planning around twenty kill trials, plus short runs where the leader stays on, so a false election can show up.

What I'm leaving out, on purpose

Cadmium on the robots themselves, a radio protocol of my own, a third robot, SLAM, and anything fast in the control loop. The cars run the same phases as a small state machine in firmware. Porting Cadmium onto the motor board would add flash size and timer conflicts with PWM, which is the risk this scope exists to avoid.

One hardware detail I keep returning to: a stalled motor can pull the supply down and reset the ESP32, and the radio goes quiet. That looks identical to the failure the demo is performing. So the motors get their own battery, and the switch I flip has to cut the ESP32 itself.

Open questions

I wrote down eleven questions for my supervisor and TA. The ones that decide the most: should Cadmium live on the laptop or the board, are two robots enough, and what should the report claim. If the January radio test goes badly, I would stop that week and fall back to a smaller version rather than design my own physical layer.

The floor I want to protect: if the gearboxes are bad, two stationary boards can still run the election, with LEDs showing the role change and the model and the table still real.

I'll write again once the cars exist.

That's the whole story.

Liked it?

Say hi, I'm open to new-grad roles from summer 2027.

Something off?

Tell me and it gets fixed tonight.

← All writing