02 / Architecture

Pixels become a circuit graph.

The system combines fixed breadboard geometry, computer vision, deterministic circuit reasoning, and optional Arduino measurements.

One pipeline, different kinds of evidence

Photo / clip
Normalize
Perceive
Netlist → Check

The system is designed to infer as little as possible. Some information is already known: the board’s geometry, the available parts, and the exercise’s intended circuit. Some information can be measured: for example, which LED responds when the Arduino drives a pin. The remaining uncertainty—especially component and wire endpoint locations—comes from the image.

1. Capture and normalization — implemented

The student photographs the circuit. The normalizer finds the breadboard, corrects its perspective, and maps the known hole grid into a consistent top-down coordinate system.

The inherited implementation in breadboard/rectify.py is based on Hartley Blakey’s breadboard-normalizer. It uses a coarse document-corner estimate, hole-grid detection, alignment, and the board’s rail stripes to disambiguate orientation. It can refuse to use a poor alignment rather than silently assign the wrong hole numbers.

This is a working subsystem, not a guarantee that every photograph will normalize successfully. The previous team identified failures on a subset of challenging images.

2. Visual perception — our current engineering focus

Once the grid is normalized, a perception model must answer:

  • Which components appear in the image?
  • Where do their leads or wire ends enter the breadboard?
  • Which endpoints belong to the same physical object?
  • Which predictions are confident enough to use?

The output must be sufficient to describe the student’s actual circuit as structured data. An earlier model can detect resistors and two keypoints, but the whole circuit—including LEDs, sensors, and overlapping wires—remains unsolved.

Explore the computer-vision problem in detail.

3. Structured circuit data — interface implemented

The system’s breadboard/netlist.py defines the data model. A component can be described by type and connection-hole coordinates; an example fragment might look like this:

{
  "id": "W_blue",
  "type": "wire",
  "pins": {
    "1": { "hole": "a54" },
    "2": { "hole": "a33" }
  }
}

This is an illustrative component fragment, not the full expected JSON file. The existing example builds and Netlist implementation are the source of truth for the exact schema.

4. Circuit checking — implemented

The checker represents the electrical circuit as a graph: electrical nodes connected by components. It can compare a proposed build to the required lab circuit and identify certain wrong or missing connections, reversed components, or uncertain observations.

A significant design choice is that different physical layouts of the same electrical circuit are acceptable. The checker operates on electrical topology rather than demanding a single visual arrangement.

5. Arduino-assisted diagnosis — existing prototype

Photographs cannot prove all electrical behaviors. The previous team implemented USB-based Arduino interrogation and an LED “blink and watch” routine that uses camera observations to determine which LED responds to a given output pin.

These tools have been demonstrated on real hardware by the previous developers. Our team’s end-to-end classroom hardware setup has not yet been verified, and Chrome deployment remains future work.

What is currently demonstrated?

Capability State
Diagnose supported builds provided as JSON Working in the inherited code
Normalize a saved breadboard image Working on tested examples
Run Arduino LED diagnostics Previous-team prototype
Automatically reconstruct every connection from an image Not complete
Run the full product in the classroom’s browser Not complete

Review current development status · Browse the actual implementation