[GSoC 2026] Micro-ROS Integration on NuttX

[Yashvee30]

Micro-ROS Integration on Apache NuttX
Yashvi Shah | yashveeyes@gmail.com | github.com/yashvee30
GSoC 2026 Proposal — Apache NuttX

1. Motivation
ROS 2 is the standard communication framework in modern robotics. It handles messaging between sensors, actuators, and controllers. But ROS 2 cannot run directly on microcontrollers — it needs too much memory and processing power.
micro-ROS solves this. It brings ROS 2 communication down to microcontroller level using a lightweight middleware called DDS-XRCE. A small client runs on the MCU and talks to an agent on a host PC, which connects it to the full ROS 2 network.
micro-ROS officially supports three RTOS platforms FreeRTOS, Zephyr, and NuttX. Among these, NuttX has the strongest technical foundation: POSIX-like APIs, deterministic scheduling, and support for a wide range of hardware. But the NuttX integration has comparatively limited support and was archived in 2025.

This project fixes that.

2. Problem Statement

The core problem is : NuttX has evolved significantly, but the micro-ROS integration was never updated accordingly. This resulted in long-term divergence and eventually led to the repository being abandoned.

This issue is clearly reflected in the official micro-ROS NuttX tutorial:
https://micro.ros.org/docs/tutorials/core/first_application_rtos/nuttx/

The tutorial also highlights the required hardware setup, including the Olimex STM32-E407 board, ARM-USB-TINY-H JTAG adapter, and serial/USB connections.

Problem 1 — Outdated Build System Root Cause

Every micro-ROS NuttX app is built using Make.defs and Makefile. The official tutorial lists these as the only build files:

app.c
Kconfig
Make.defs
Makefile

Modern NuttX applications use CMakeLists.txt. A simple example — the hello app in nuttx-apps:

if(CONFIG_EXAMPLES_HELLO)
nuttx_add_application(
NAME ${CONFIG_EXAMPLES_HELLO_PROGNAME}
SRCS hello_main.c
STACKSIZE ${CONFIG_EXAMPLES_HELLO_STACKSIZE}
PRIORITY ${CONFIG_EXAMPLES_HELLO_PRIORITY})
endif()

A search for CMakeLists.txt inside micro_ros_nuttx_app returns nothing:

Problem 2 — Complexity
The official tutorial requires manual steps before anything runs. This includes:

Setting up micro-ROS build system
Cloning NuttX tools from Bitbucket
Manually compiling kconfig-frontends from source
Running menuconfig by hand
Flashing via JTAG

Problem 3 — Limited Hardware Accessibility
Although NuttX supports a wide range of microcontrollers, the micro-ROS integration was primarily validated on a specific hardware setup, namely the Olimex STM32-E407 board. Flashing and debugging require an external JTAG adapter.

Problem 4 — Memory Instability
The memory configuration in the integration was written against an older NuttX memory layout. On current NuttX this causes hardfaults hard crashes due to stack and heap mismatches. The DDS-XRCE buffer sizes are also not tuned for constrained MCU environments.

3. Proposed Solution

Pillar 1 — Fix the Build System

Write CMakeLists.txt for micro-ROS components inside nuttx-apps, following the same pattern modern NuttX apps use. This is the root fix — everything else depends on it.
The current state:

makefileMENUDESC = "micro-ROS library and app"
include $(APPDIR)/Directory.mk

The target state:

cmakeif(CONFIG_MICRO_ROS)
nuttx_add_application(
NAME micro_ros_app
SRCS micro_ros_app.c
STACKSIZE ${CONFIG_MICRO_ROS_STACK_SIZE}
PRIORITY ${CONFIG_MICRO_ROS_PRIORITY})
target_include_directories(apps PRIVATE
${CMAKE_CURRENT_SOURCE_DIR}/include)
endif()

Pillar 2 — Expand Board Support

Create validated defconfig files for STM32 Nucleo-F446RE and ESP32 — boards that developers actually own. Both configs will include correct memory layout to prevent hardfaults.

Pillar 3 — Example Application and Documentation

Write a working publisher/subscriber example validated end-to-end with a ROS 2 agent on a host PC.

4. Deliverables

ID	Deliverable	Verified When
D1	CMakeLists.txt for micro-ROS in nuttx-apps	cmake --build succeeds on current NuttX
D2	defconfig for STM32 Nucleo-F446RE	Builds, flashes via USB, runs publisher
D3	defconfig for ESP32	Builds, flashes via USB, runs publisher
D4	Memory-safe configuration	Zero hardfaults on both boards
D5	Publisher/subscriber example	communication with ROS 2 agent
D6	GitHub Actions CI pipeline	Catches build regressions automatically
D7	Updated documentation	New developer succeeds

5. Timeline

Week	Dates	Goal
Week 1	May 1 – May 7	Study nuttx-apps CMake structure and understand current micro-ROS integration.
Week 2	May 8 – May 14	Identify build issues and breakpoints. Start fixing CMake migration problems.
Week 3	May 15 – May 21	Set up CI pipeline skeleton and validate basic build flow.
Week 4	May 22 – May 28	Write and test CMakeLists.txt for micro-ROS core integration.
Week 5	May 29 – June 4	Validate build on NuttX and fix compilation issues.
Week 6	June 5 – June 11	STM32 Nucleo defconfig setup and testing on hardware.
Week 7	June 12 – June 18	ESP32 defconfig setup and serial transport testing.
Week 8	June 19 – June 25	End-to-end ROS 2 communication (publisher/subscriber).
Week 9	June 26 – July 2	GitHub Actions CI setup and regression testing.
Week 10	July 3 – July 9	Documentation updates and cleanup.
Week 11	July 10 – July 16	Buffer + testing + bug fixing.
Week 12	July 17 – July 23	Final polish, optimization, and submission readiness.

6. Anticipated Challenges

CMake linking with micro-ROS libraries

The main challenge is integrating micro-ROS with the NuttX CMake build system. micro-ROS provides prebuilt static libraries from a colcon-based build, but NuttX uses its own build system. The difficulty is making these libraries properly linkable inside nuttx_add_application() by handling include paths, library paths, and link order correctly.
There is no ready-made implementation in micro_ros_nuttx_app.
It is important to note that ArduPilot already runs on NuttX successfully, which proves that complex robotics software can be integrated into NuttX. However, micro-ROS integration is still incomplete and requires proper CMake-based linking and modernization.

Memory differences across boards

STM32 Nucleo and ESP32 have different RAM, stack, and heap configurations. A configuration that works on one board may cause hardfaults on another. Each board will require separate tuning and real hardware testing.

7. Potential Benefits

If successful, this project will make micro-ROS usable on NuttX in a stable and production-ready way.
Today, most micro-ROS users rely on FreeRTOS and Zephyr. NuttX support is not practical due to broken integration. A working implementation would allow developers who already use NuttX (for its POSIX compliance and real-time features) to also run ROS 2 nodes on microcontrollers.
NuttX is already proven in real robotics systems such as ArduPilot, which shows it is capable of handling complex flight and control software. This project extends that capability into the ROS 2 ecosystem.
This would make NuttX a stronger alternative alongside Zephyr and FreeRTOS for robotics development.
In addition, the CI pipeline created in this project will continuously validate the integration. This helps prevent future breakages and ensures long-term maintainability of external middleware support in NuttX.

8. About Me

I am Yashvi Shah, a robotics engineering student with experience in ROS 2, embedded systems development, and C/C++.
I have contributed to the Apache NuttX community in the area of board support. While working with NuttX 12.7 on Raspberry Pi Pico, I identified a regression in the NSH console that was affecting real hardware functionality. The issue was confirmed and acknowledged by NuttX maintainer Alan Carvalho de Assis. #15162

NOTE : Please consider marking this issue with the gsoc2026 label.

Verification

• I have verified before submitting the report.

[acassis]

Please confirm if you submitted the proposal before the deadline yesterday?