I already have a robot. Dalek Bob is brilliant, a full-size Dalek that genuinely stops people in their tracks. He's awesome. He's also 65kg, requires two people and a van to move anywhere, and the risk assessments involved in letting kids anywhere near him are a bureaucratic marathon. Bob is a showpiece. You can't hand him to a group of teenagers on a Tuesday afternoon and tell them to figure it out.
I've been thinking for a while about how to get young people genuinely excited about technology, not the watered-down, press-a-button-and-something-happens version, but real technology. The kind where things go wrong, you have to figure out why, and when it finally works you actually understand what you did.
The Waveshare UGV Rover arrived a few weeks ago. Six wheels, aluminium chassis, dual controllers an ESP32 handling the low-level motor control and a Raspberry Pi sitting on top doing the thinking. It's a serious bit of kit for the price, and it's fully open source, which matters to me.
The plan was simple enough. Use a Steam Deck as the controller. The Deck runs Linux, it's got a decent gamepad built in, and half the young people I work with already know what one is. Seemed obvious.
It was not simple.
The rover communicates via JSON commands sent over HTTP or serial. That part was straightforward, a quick curl command proved the connection was working in about two minutes. The hard part was getting the Steam Deck's own controller to talk to a Python script without Steam intercepting everything first.
The Steam Deck's physical sticks don't exist as far as Linux is concerned unless Steam is running and creates a virtual gamepad. Kill Steam and the sticks disappear. Keep Steam running and it grabs exclusive access so nothing else can read them. It took a while to find the path through, launching the script as a non-Steam game from Game Mode, letting Steam's input layer stay active, then reading the device directly via evdev rather than going through pygame.
There were axis mapping issues, calibration offsets, resting values that weren't zero, wheels spinning in opposite directions for reasons that took three iterations to pin down. Normal stuff. Frustrating in the moment, instructive in retrospect.
By the end of an afternoon I had a working controller. Push the left stick forward, the rover drives forward. Right stick steers. B button stops it dead. It works.
Here's why I think this matters beyond just being a fun afternoon project.
When I put that rover on the floor and hand a young person a Steam Deck, something changes. It's not a worksheet. It's not a tutorial. It's a machine doing something in the physical world because of decisions made in code. The connection between the abstract and the real becomes visible.
The rover is fast enough to be exciting and robust enough to take a knock. The fact that it runs on open protocols means we can get into the code. We can change the speed. We can add new controls. We can ask questions like, what if we wanted two people to control it at once? What if we wanted it to stop automatically when the battery gets low? What if we wanted to stream the camera to a second screen?
Every one of those questions is a project. Every project teaches something real.
I'm not under any illusion that robots solve digital exclusion. They don't. But engagement is the first problem. If a young person from Oldham who has written off technology as something that isn't for them spends forty minutes trying to make a six-wheeled robot navigate around a room, and walks away thinking maybe this is something they could learn, that's a crack in the door.
Dalek Bob will still come out for events. He's too good not to. But the rover can be out every week, handled, programmed, argued with, and learned from without a risk assessment or a transit van.
That's what we're trying to create. Cracks in the door.
The rover is going to earn its place here. Give it a few weeks.