Bringing live perception from a self-driving car simulator onto the operating system that runs in real car dashboards — over ROS2 and rosbridge.
Modern cars are full of sensors. One of the most important is LiDAR — a spinning laser that measures the distance to everything around the vehicle, producing a 3D point cloud of the world. Software then turns that cloud into something useful: “there's a car 12 metres ahead, a pedestrian to the left.” Finally, the dashboard draws it on a screen so the driver (or the system) can see what the car sees.
This project builds that whole journey — but in simulation, so it can be developed and tested without a physical car:
Each box is a real, separate technology, and getting them to talk to each other — cleanly, reproducibly, and under real-world constraints — is the heart of the work.
It's worth being honest about the gap between the textbook deployment and the one we could actually run. The ideal is three machines, each doing the job it's suited for, on a real network:
We couldn't reach that: the target single-board computer (a Raspberry Pi 4B) wouldn't boot due to a hardware fault — a Jetson Nano has since been ordered as its replacement — and the only machine large enough to run CARLA was the GPU-less server. So everything collapsed onto one box, with AGL emulated in QEMU and a lightweight custom bridge. The table shows what's faithful to the goal and what is still a stand-in:
| Dimension | Ideal | What we built |
|---|---|---|
| Machines | workstation + target + GPU box | one server |
| AGL runs on | real automotive hardware | QEMU emulation (qemux86-64) |
| Sensor data | LiDAR point cloud → detections | LiDAR point cloud on AGL (+ odometry); PCL detections as PoC |
| Network | real LAN | QEMU slirp NAT via the host gateway |
| CARLA→ROS2 bridge | official carla_ros_bridge | custom two-process bridge |
| AGL client | HMI application (bird's-eye view) | standard-library WebSocket client |
What's genuinely proven: the transport leg — rosbridge → AGL — is identical to the ideal, and it now carries a live CARLA LiDAR point cloud all the way into an AGL VM (see Week 3). The remaining pieces (the HMI application, real target hardware, the final perception algorithms) all plug into that same proven pipe without changing its shape — they swap the cargo, not the channel.
This site documents the work in order. Start at Community Bonding and follow through the weeks.
Locking the architecture (and why rosbridge, not DDS), the two-Python-version puzzle, and standing up CARLA + the AGL/ROS2 toolchain on a GPU-less server.
Compiling the AGL+ROS2 image (and the recipe bug that blocked it), standing up rosbridge, a pure-stdlib WebSocket client, and proving an AGL VM can subscribe over QEMU networking.
Wiring the real simulator into the pipeline, fixing three runtime bugs, and watching the AGL dashboard track a self-driving car live at 20 Hz.
A Raspberry Pi target that wouldn't boot (Jetson Nano ordered), and a live CARLA LiDAR point cloud reaching AGL — produced on a server with no GPU at all.
Cleaning up the code into a public repository, and reviving the Jetson Nano after outdated firmware blocked Linux from booting — the target board is now building and booting.