CS 109 · Think Faire

Think Faire: Robotics

My assigned Think Faire topic is robotics. Below are three proposed presentations, each taking a different real-world application and asking what the hard computer science problem actually is underneath it.

← Back to my homepage

Framing

The angle I want to take

Most robotics demos are sold on the hardware — the arm, the gripper, the drone. I would rather spend the presentation on the part you cannot photograph. In every application below, the mechanical problem was solved years before the system worked, and what held it back was software: a control loop that had to close fast enough, a planner that deadlocked at scale, a perception model that failed in bad light.

That framing also fits the format. A Pecha Kucha gives you twenty seconds a slide and no time to recover from a tangent, so each of these is built around a single question with a concrete answer rather than a survey of a field.

Format note. Pecha Kucha is 20 slides advancing automatically every 20 seconds — 6 minutes 40 seconds total. Each outline below is scoped to that budget, with a rough slide split.

Proposals

Three presentation ideas

Three sectors, three different corners of computer science.

Idea 01

The Quarter-Second That Decides a Surgery

Application: robot-assisted and remote surgery

The question: a surgeon moves their hand and an instrument moves inside a patient. What has to happen in between, and how late is too late?

Systems like the da Vinci platform are often described as the surgeon’s hands being made steadier. The interesting claim is narrower: the whole system is a real-time control loop with a latency budget, and that budget is what decides whether surgery can happen over a distance at all. Past roughly 200 ms of round-trip delay, surgeons start to overcorrect, because the feedback they are reacting to describes a world that has already moved on. That is not a mechanical limit or a bandwidth limit — it is the speed of light through fibre plus every queue and scheduler on the path.

What the presentation would show:

Slides 1–4: follow one hand movement through the stack — sensing, filtering, transmission, actuation, haptic return.
Slides 5–10: where the milliseconds go, and why a general-purpose OS is a problem when a deadline missed is not just slow but wrong.
Slides 11–16: the 2019 transatlantic and 5G remote-surgery demonstrations, and what the distance limit really is.
Slides 17–20: what this buys — specialist surgery reaching hospitals that have no specialist — and the failure modes that follow when the link drops mid-procedure.

Real-time systems
Control loops
Networking
Safety-critical software

Idea 02

A Thousand Robots, One Floor, No Collisions

Application: warehouse fulfillment and logistics

The question: shortest-path routing for one robot is a solved first-year exercise. Why does running it on a thousand robots at once bring the whole warehouse to a halt?

This is the idea I find most genuinely surprising, because the failure is so counter-intuitive. Give every robot the individually optimal route and they will converge on the same corridors and deadlock — each one waiting on a square the next one is waiting to leave. The problem is not path-finding, it is multi-agent path-finding, and it is combinatorially harder: optimal solutions are NP-hard, so real warehouses use reservation tables, time-indexed grids, and conflict-based search to buy a good-enough answer inside a deadline. It is a clean demonstration that a correct algorithm can still be the wrong algorithm.

What the presentation would show:

Slides 1–4: the floor as a graph; one robot, A*, no difficulty.
Slides 5–9: an animated deadlock — everyone individually optimal, collectively stuck.
Slides 10–15: reserving space and time; conflict-based search; why the industry accepts suboptimal routes to get an answer in time.
Slides 16–20: what it costs — throughput, warehouse jobs that changed shape, and what happens to the humans still walking that floor.

Multi-agent planning
Graph algorithms
Scheduling
Complexity

Idea 03

Teaching a Machine to Tell a Weed From a Seedling

Application: agricultural robotics

The question: a weeding robot has about 50 ms to decide whether the green thing under it is a crop or a weed, outdoors, in changing light, on hardware it can carry. What makes that so much harder than a benchmark?

Machines like the Carbon Robotics laser weeder kill weeds without herbicide, which matters: agriculture applies hundreds of millions of pounds of it a year, and resistance keeps rising. But the computer vision here gets none of the conditions a benchmark dataset assumes. Lighting shifts hour to hour, plants occlude each other, a weed and a seedling of the same species can be near-identical at the stage you need to act, and inference runs on an embedded board rather than a datacentre GPU. The asymmetry is the heart of it: a missed weed costs almost nothing, a false positive destroys a plant the farmer paid for. I would use this to make the point that a model’s accuracy number is close to meaningless until you know what each kind of error costs.

What the presentation would show:

Slides 1–4: the scale of herbicide use, and what a mechanical alternative has to beat.
Slides 5–10: why field images break models that score well on clean data.
Slides 11–15: the latency and power budget of inference on a moving vehicle — a problem I have touched on a much smaller scale with Raspberry Pi projects.
Slides 16–20: asymmetric error costs, and who gets access to a machine that expensive.

Computer vision
Edge inference
Embedded systems
ML evaluation

If I had to choose

My ranking

Idea 02 is the one I would push for. It has a single idea that lands in one slide — everybody optimal, everybody stuck — it animates well under a twenty-second clock, and it needs no domain knowledge the audience doesn’t already have from a first algorithms course.

Idea 03 is the one I am most personally interested in, since it overlaps with the embedded work I have done. Idea 01 has the strongest hook but the most ground to cover, and it is the easiest of the three to run out of time on.

← Back to my homepage My projects