Fetch

side2
side1
front

Inspiration

Galleries and event spaces have a problem where the bin is never where people are. Staff move it around by hand all night. We wanted a robot that could learn a venue in ten minutes and then bring the bin to whoever needs it.

The constraint that shaped everything: we had no encoders, no IMU, and no lidar. Most navigation approaches assume at least one. We had to build something that worked without knowing where it was.

What it does

FETCH carries a trash can around a gallery. Staff teach it the venue by driving it to each art piece once and pressing a button to name that spot. After that it drives to any of them on its own.

Visitors call it by opening a web page on their phone and pointing the camera at the AprilTag beside them. The Raspberry Pi identifies which tag they are at and sends the robot from wherever it is to them. No app to install.

The robot moves on four mecanum wheels, so it can strafe sideways and rotate in place without repositioning.

How we built it

Four NEMA 17 steppers driven by A4988s on a CNC shield, controlled by an Arduino Uno R4. A Raspberry Pi 4 runs the web interface and does all the vision work. The chassis, deck, sensor pod, and the mount that holds the trash can are printed from parts we modeled ourselves.

Navigation stores a graph. Nodes are places, edges are the actual driving between them, recorded as velocity commands with durations. Pressing "mark" saves everything driven since the last mark as one edge.

Edges work in both directions for free. Reversing one means replaying its segments backwards with every velocity negated. That is a true inverse only because the robot is holonomic, and we verified the net displacement of forward plus backward is exactly zero. A car could not do this.

Routing uses Dijkstra weighted by recorded driving time rather than hop count, so it does not pick one slow edge over two fast ones.

Both interfaces are served by a single Python process using only the standard library plus pyserial, tunneled out through Cloudflare so they work on venue WiFi that blocks devices from talking to each other.

Challenges we ran into

The venue network isolated every client, so no local IP was reachable from a phone. We solved it by having the Pi dial out to Cloudflare and having phones meet it there.

Teaching originally required the camera to see a tag at the moment you saved a spot. In practice the camera is low and fixed while tags sit higher, so the tag was often out of frame exactly where the robot needed to stop. We rebuilt teaching so it records driving instead of vision, which removed the requirement entirely.

Adding a new state to the navigator broke the abort path, which left the wheels turning after a stop. An integration test caught it before it ran on hardware.

Accomplishments that we're proud of

Navigation that works with zero odometry hardware. The robot has no idea where it is in any coordinate system and still gets where it is going.

Safety that does not depend on the network. The obstacle veto and a 500 ms communication watchdog both live in firmware, so they still fire if WiFi, the tunnel, or the Pi disappears mid run.

A visitor interface that needs no install. Detection runs on the Pi, so any phone browser works.

What we learned

Open loop replay drifts a few percent per leg, which is why the graph uses many short edges instead of one long route. Short legs keep each error small and give the robot places to re-ground.

Sensor failures need to fail open, not closed. A disconnected ultrasonic reads zero, and treating zero as an obstacle would freeze the robot completely. Both the firmware veto and the replay loop require a reading that is close and physically plausible before acting on it.

What's next for Fetch

Closing the loop on arrival using the tags for a final position correction, which would take accuracy from centimetres of drift down to near exact. Microstepping on the drivers to cut motor noise. Battery monitoring so it can return to home to charge on its own.