BackCompleted
Completed2026Author

RobotDrawing

Learned stroke routing for an ABB IRB140

Robotic drawing posed as a stroke-level routing problem, solved with a graph network and pointer decoder — and then measured honestly against the classical solvers it was meant to beat.

26.8 / 27.0 / 28.8

Avg pen-ups — SA / greedy / learned

Lower is better. Across the committed 28-image batch.

195 ms / 18 ms / 10.9 s

Avg runtime — SA / greedy / learned

Same batch. The learned router is ~56× slower than SA here.

28

Images in the benchmark

Each run through all three methods with identical inputs.

Problem

Classical solvers produce good stroke orderings and take time to do it. At point level the problem is also far larger than it needs to be — the decision that matters is the order and direction of strokes, not of individual points.

The hypothesis was that a learned router could match simulated annealing's ordering quality at a fraction of the runtime, by amortising the search into a trained model.

What I built

A learned router, the classical baselines to judge it against, and the control layer that puts a stroke order on a real arm.

  • Stroke-level formulation with forward/reverse direction optimisation to cut pen-ups and travel
  • GNN + Pointer Network trained in two phases: imitation learning warm-started from the classical solvers, then reinforcement learning
  • Curriculum learning from simple to complex graphs
  • Greedy nearest-neighbour and simulated-annealing baselines
  • A 28-image batch harness reporting pen-ups, pen-up distance, continuity and runtime per method
  • Feature and flooding ablations
  • Control and UI layer driving an ABB IRB140 arm

Measuring it properly is what produced the result

The batch harness runs all three methods over the same 28 images and records runtime and quality per method per image, rather than reporting a representative figure. That is the only reason the gap between the README's claim and the system's behaviour is visible at all.

The honest summary: simulated annealing wins on quality, greedy nearest-neighbour wins on speed by a wide margin, and the learned router currently loses on both.

The pipeline, and where it was measured

The benchmark harness is the part that matters: all three methods run over the same 28 images and every image records runtime and quality per method. That is the only reason the gap between the README's claim and the system's behaviour is visible.

  1. An image comes in

  2. Extract strokes

    The problem is posed at stroke level rather than point level — the decision that matters is order and direction, not individual points.

  3. Build the stroke graph

  4. Route it

    Greedy nearest neighbour — 18 ms, 27.0 pen-ups
    Simulated annealing — 195 ms, 26.8 pen-ups
    Learned router (GNN + Pointer Net) — 10.9 s, 28.8 pen-ups

  5. Direction flipping

    Forward/reverse optimisation to cut pen-ups and travel.

  6. Drive the ABB IRB140

    Through the control and UI layer.

The benchmark

28 images, all three methods, identical inputs. Lower is better on both columns. The README advertises ~150 ms inference and a 20× speedup over SA; these are the numbers the committed run actually produced.

MethodAvg pen-upsAvg runtime
Simulated annealing26.8195 ms
Greedy nearest neighbour27.018 ms
Learned router28.810,880 ms

Experiments

Learned routing vs. classical optimisationnegative result

Question
Can a learned router match simulated annealing's stroke-ordering quality at a fraction of the runtime?
Method
GNN + Pointer Network trained by imitation then RL, benchmarked against greedy nearest-neighbour and simulated annealing over 28 images on pen-ups, pen-up distance, continuity and wall-clock runtime.
Result
No. The learned router averaged 28.8 pen-ups against SA's 26.8, and 10.9 s against SA's 195 ms. The amortisation hypothesis did not hold on this benchmark.

One result did not confirm the hypothesis. They are reported here because an experiment that only ever confirms things is not an experiment.

Limitations and failure modes

  • The repository README advertises ~150 ms inference and a 20× speedup over SA. The committed batch results do not reproduce that, and the two have not been reconciled — the 150 ms may measure model inference alone, excluding stroke extraction and post-processing, but nothing in the repository establishes it.
  • The learned router loses to simulated annealing on quality and to greedy nearest-neighbour on speed on this benchmark.
  • 28 images is a small benchmark, and pen-up counts vary enormously across them (0 to 302), so the averages hide a wide spread.
  • Deployment on the ABB IRB140 demonstrates execution, not an advantage over the classical baselines.

Gallery

Quality against runtime across all three methods. The learned router sits where you would least want it — slowest and highest pen-up count
Quality against runtime across all three methods. The learned router sits where you would least want it — slowest and highest pen-up count
Runtime by method across the 28-image batch
Runtime by method across the 28-image batch
Pen-up counts by method — lower is better
Pen-up counts by method — lower is better

Not yet captured

  • ABB IRB140 executing a stroke order

Attribution

Built by me
Formulation, models, training, benchmark harness and the ABB control layer.
Experiment performed by me
The 28-image benchmark against classical solvers, including the negative result reported above.

Related

  • OpenDroneKit

    Offline drone inspection — mission planning, flight, geospatial reconstruction and defect intelligence