Google Summer of Code 2026 · Automotive Grade Linux

ROS-Embedded LiDAR Perception in CARLA with AGL Visualization

Bringing live perception from a self-driving car simulator onto the operating system that runs in real car dashboards — over ROS2 and rosbridge.

Contributor: Shaurya Rane · Mentors: Jan-Simon Möller, Rob Woolley

What this project is

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:

CARLA simulator → a virtual car with a virtual LiDAR sensor │ ▼ point cloud perception (ROS2 / PCL) → detects cars, pedestrians, cyclists │ ▼ 3D detections rosbridge (WebSocket) → carries the data out as JSON │ ▼ AGL dashboard app → draws a bird's-eye view of the surroundings

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.

The building blocks

The ideal setup vs. what we built

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:

┌──────────────────────┐ real LAN ┌──────────────────────┐ │ WORKSTATION (GPU) │ ───────────────► │ TARGET HARDWARE │ │ CARLA + LiDAR │ ROS2 / rosbridge │ AGL on real silicon │ │ official ros-bridge │ over Ethernet │ HMI application │ └──────────────────────┘ └──────────────────────┘

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:

DimensionIdealWhat we built
Machinesworkstation + target + GPU boxone server
AGL runs onreal automotive hardwareQEMU emulation (qemux86-64)
Sensor dataLiDAR point cloud → detectionsLiDAR point cloud on AGL (+ odometry); PCL detections as PoC
Networkreal LANQEMU slirp NAT via the host gateway
CARLA→ROS2 bridgeofficial carla_ros_bridgecustom two-process bridge
AGL clientHMI 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.

Progress log

This site documents the work in order. Start at Community Bonding and follow through the weeks.

Community Bonding

Understanding & setting up

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.

Week 1

Building AGL & proving the link

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.

Week 2

Live CARLA → AGL

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.

Week 3

Hardware & LiDAR on AGL

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.

Week 4

A repo, and the Jetson boots

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.