GSoC 2025 - Final Journey
Automotive Grade Linux (AGL) - meta-ros
Summary:
The integration of the Robot Operating System (ROS) Framework as an option within Automotive Grade Linux (AGL) through the meta-ros yocto layer is an important step in upgrading vehicle technology using automotive systems. This project is important for several reasons:
- Bridging the Gap Between Robotics and Automotive Software.
- Expanding AGL’s Capabilities
- Advancing Open-Source Development
- Enhancing Real-World Use Cases
Objectives:
- To integrate meta-ros scarthgap layer onto AGL master branch for further releases.
- Bring-up the same and get it working on Pi500.
- Write a demo application showing interaction and communication between ROS libraries and AGL Application.
Journey:
The project covered many interconnected pieces, starting with integrating the Yocto layer meta-ros. During the community bonding period, my initial plan was to add the layer using bitbake-layer and build a default AGL target. I cloned meta-ros, added it as a BitBake layer in my build environment, and successfully compiled ros-core with the layer included.
Hardware support became the next major task. I initially tested everything on QEMU x86_64, but our goal was to run on real hardware. I attempted a Raspberry Pi 5 target, which booted but showed frontend and UX glitches. With guidance from my mentors, we discovered the kernel source being used was outdated. To fix this, a patch adding the necessary DTS support was upstreamed, resolving the boot and display issues on the Pi 5.
Up to this point, the ROS integration into AGL had been done manually. Since AGL’s build process relies on features enabled before compilation, we needed an AGL feature to standardize this. Because ROS is a development feature, it belonged in meta-agl-devel. I prepared and submitted a patchset introducing a new feature, meta-agl-ros2, which automatically includes the ROS 2 layers required to build ROS packages such as ros-core.
Once the system built and booted reliably, I tested ROS publishers and subscribers directly on the hardware. Using standard ROS tutorials, message sending and receiving worked successfully within AGL. With the core integration proven, the next step was to develop a demo application. The idea was to go beyond terminal-based demonstrations and showcase ROS capabilities through an actual UI/UX. We spent time defining the scope of this application.
To interface the application with ROS, we evaluated two Flutter libraries: ros-bridge and rcldart. We chose rcldart because it is more recent and actively developed. After contacting the maintainer, we received permission to use it. Communication between ROS and Flutter worked on my development system, but initially failed on hardware due to user-namespace differences. AGL applications run under a separate user, but after resolving this, we successfully tested custom publishers and subscribers on the device.
With communication established, we needed a real-world use case. We chose to incorporate a camera. Early experiments with simulators didn’t yield much direction, but eventually we focused on object detection as a practical automotive feature. The idea was to detect objects in real time, enabling the car to warn the driver or even brake in critical scenarios. I implemented this in the application, and once we confirmed it was working, we expanded the concept further. With remaining time, we added a driver-monitoring feature that detects fatigue or drowsiness using camera input, allowing the system to alert the driver and trigger appropriate safety behavior.
Results:
- Was successfully able to integrate meta-ros scarthgap on AGL master.
- Pi500 now boots successfully with raspberrypi5 target.
- The demo application is now extended from just subscriber/publisher sync, it also has camera detection running a model in background in ROS-end to be able to do face detection and person detection.
Challenges:
- Initially Pi kernel upstream was quite old, which lacked dts support, so we had to add that in order to be able to boot-up Pi500.
- The ROS backend, which ran on the terminal, was not able to communicate with the application, we were able to debug this by finding out the userspace/namespace issues where the backend was running.
- A lot of glitches and components in the application, which got fixed along the way.
Future Scope:
- Upstream the meta-ros layer and in-sync with further releases of AGL.
- Test the upstreamed layer with base use cases along with application.
- Maintain the application for higher upstream and for further hardware updates.
- Establish gRPC communication with AGL frontend, to have an end-to-end communication setup between AGL and ROS.
Patch-sets:
- https://gerrit.automotivelinux.org/gerrit/c/AGL/meta-agl-devel/+/31201?usp=dashboard
- https://gerrit.automotivelinux.org/gerrit/c/AGL/meta-agl-devel/+/31175?usp=dashboard
- https://gerrit.automotivelinux.org/gerrit/c/AGL/meta-agl-devel/+/31265?usp=dashboard
- https://gerrit.automotivelinux.org/gerrit/c/AGL/meta-agl-devel/+/31266?usp=dashboard
- https://gerrit.automotivelinux.org/gerrit/c/AGL/AGL-repo/+/31178?usp=search
- https://gerrit.automotivelinux.org/gerrit/c/AGL/meta-agl-devel/+/31100?usp=search
- https://gerrit.automotivelinux.org/gerrit/c/apps/flutter-ros-demo/+/31275?usp=search
- https://gerrit.automotivelinux.org/gerrit/c/apps/flutter-ros-demo/+/31276?usp=search
- https://github.com/danascape/flutter-ros-demo
Images:
Get Involved
Stay tuned for the detailed technical deep-dives in the upcoming blog posts. I am planning to include examples, code, etc, such that anyone can follow along with it.
Have questions about automotive software development or want to collaborate on open-source automotive projects? Reach out to me on my email
Journey: GSoC 2025 Journey





