ROS2 Development Guide
Architecture, Nav2 & Industrial Deployment

1. Executive Summary -- ROS2 Ecosystem Overview

ROS2 (Robot Operating System 2) has become the de facto standard middleware for production robotics. Unlike its predecessor ROS1, which was designed primarily for academic research on single machines with best-effort UDP multicast, ROS2 was engineered from the ground up for multi-robot, safety-critical, real-time industrial deployments. Built on the OMG Data Distribution Service (DDS) standard, ROS2 provides deterministic communication, fine-grained Quality of Service (QoS) policies, lifecycle-managed nodes, and native support for security through DDS-Security (SROS2).

The migration from ROS1 (final distribution: Noetic, EOL May 2025) to ROS2 is now an industry imperative. ROS2 Jazzy Jalisco (May 2024, LTS through 2029) and the upcoming Rolling release provide stable foundations for commercial deployment. The ecosystem has matured dramatically: Nav2 has replaced the ROS1 navigation stack, MoveIt2 provides full manipulation planning, and micro-ROS extends the ROS2 graph down to microcontrollers running FreeRTOS or Zephyr.

This guide covers every layer of the ROS2 stack, from DDS wire-protocol internals to cloud-native deployment patterns, with production-tested code examples and configuration templates. Whether you are migrating an existing ROS1 fleet, building a new AMR from scratch, or deploying industrial arms in a Vietnamese manufacturing facility, this resource provides the architectural decisions and implementation details you need.

1.1 Why ROS2 Over ROS1

ROS1 served the robotics community for over 15 years, but its architectural limitations became blockers for commercial deployment. ROS1 relied on a single-point-of-failure rosmaster for service discovery. Its TCP/UDP transport layer lacked QoS guarantees. There was no native support for security, lifecycle management, or real-time execution. Multi-robot systems required fragile workarounds with separate ROS masters or multimaster packages.

ROS2 addresses every one of these limitations. DDS provides decentralized peer-to-peer discovery, eliminating the rosmaster bottleneck. QoS policies (reliability, durability, deadline, liveliness) allow developers to tune communication semantics per-topic. Managed nodes with lifecycle states (unconfigured, inactive, active, finalized) enable graceful startup and shutdown sequences critical for industrial systems. SROS2 provides authentication, encryption, and access control at the DDS layer.

2. ROS2 Architecture & DDS Middleware

2.1 The DDS Layer

At the heart of ROS2 lies the Data Distribution Service (DDS), an OMG standard for real-time publish-subscribe middleware. ROS2 abstracts DDS through the rmw (ROS Middleware) interface, allowing vendors to be swapped without changing application code. The two dominant DDS implementations in the ROS2 ecosystem are Eclipse Cyclone DDS (default since Galactic) and eProsima Fast DDS (formerly Fast-RTPS).

DDS operates through the RTPS (Real-Time Publish-Subscribe) wire protocol, which handles participant discovery, endpoint matching, and data serialization. When a ROS2 node creates a publisher on a topic, DDS announces this endpoint to all other DDS participants on the same DDS domain (identified by ROS_DOMAIN_ID, default 0). Subscribers that match the topic name and compatible QoS profile automatically establish communication -- no broker, no master, no single point of failure.

2.2 Nodes, Topics, Services & Actions

Nodes are the fundamental computational units in ROS2. Each node is an independent process (or thread within a component container) responsible for a single coherent function -- a LiDAR driver, a path planner, a motor controller. Nodes communicate through four mechanisms:

• Topics (publish/subscribe): Asynchronous, many-to-many data streams. A LiDAR node publishes sensor_msgs/msg/LaserScan on /scan; any number of subscribers (SLAM, obstacle avoidance, visualization) consume it independently. QoS profiles control reliability, history depth, and deadline enforcement.
• Services (request/response): Synchronous RPC calls. A client sends a request and blocks (or uses a callback) until the server responds. Used for discrete operations like /set_parameters, /trigger_calibration, or /save_map. Not suitable for long-running operations.
• Actions (goal/feedback/result): Asynchronous, preemptable long-running tasks built on topics and services. The Nav2 NavigateToPose action sends a goal, streams continuous feedback (distance remaining, ETA), and returns a final result (success/failure). Actions can be canceled mid-execution.
• Parameters: Node-local key-value configuration that can be read and written at runtime. Parameters are served via built-in services and can be declared with types, ranges, and descriptions. Use ros2 param set /node_name param_name value for runtime tuning.

2.3 Component Containers and Intra-Process Communication

Running each node as a separate OS process introduces inter-process overhead (serialization, context switching). ROS2 component containers load multiple nodes as shared libraries into a single process, enabling zero-copy intra-process communication. For image pipelines -- where a camera driver publishes 30 FPS of 1080p frames consumed by a detector node -- intra-process communication eliminates serialization entirely, reducing latency from ~5ms to ~50 microseconds.

3. Nav2 Navigation Stack

Nav2 (Navigation2) is the production navigation framework for ROS2, replacing the ROS1 move_base stack with a modular, plugin-based architecture built on behavior trees, lifecycle-managed servers, and configurable planning/control algorithms. Nav2 handles everything from global path planning and local trajectory optimization to recovery behaviors and waypoint following.

3.1 Architecture Overview

Nav2 is composed of several lifecycle-managed server nodes coordinated by the BT Navigator, which executes behavior trees defining the navigation logic. The core servers are:

• Planner Server: Computes global paths from current pose to goal. Default plugin: NavFn (Dijkstra/A*). Alternatives: Smac Planner (2D/Hybrid-A*/Lattice), Theta* for any-angle paths, or custom plugins for constrained environments.
• Controller Server: Generates velocity commands to follow the global path while avoiding local obstacles. Default plugin: DWB (Dynamic Window approach). Alternatives: Regulated Pure Pursuit (RPP) for smooth AMR trajectories, MPPI (Model Predictive Path Integral) for dynamic environments, or TEB for time-elastic band optimization.
• Recovery Server: Executes recovery behaviors when the robot gets stuck. Built-in recoveries: spin (rotate in place), back_up (reverse), wait (pause and re-attempt). Custom recovery plugins can trigger re-localization, map updates, or operator alerts.
• Smoother Server: Post-processes global paths to produce kinematically feasible, smooth trajectories. Reduces unnecessary turns and oscillations that stress mechanical components.
• Costmap 2D: Maintains layered occupancy grids (static map, obstacle layer, inflation layer, voxel layer) used by both planner and controller. Configurable resolution, update frequency, and sensor sources.
• Waypoint Follower: Executes multi-waypoint missions with configurable task executors at each waypoint (e.g., wait 5 seconds, take photo, trigger action).

3.2 Behavior Trees for Navigation

Nav2 replaced ROS1's finite state machine with BehaviorTree.CPP, a powerful library for building modular, composable navigation strategies. Behavior trees (BTs) offer several advantages over state machines: they are easier to visualize, inherently support fallback and recovery patterns, and can be modified at runtime via XML files without recompilation.

A typical navigate_to_pose BT follows this logic: (1) compute a global path, (2) follow the path with the controller, (3) if the controller fails (obstacle), re-plan, (4) if re-planning fails, execute recovery (spin, backup), (5) if recovery fails, abort with error.

3.3 Nav2 Parameter Configuration

Nav2 performance depends heavily on parameter tuning for your specific robot kinematics, sensor configuration, and operating environment. Below is a production-tested parameter file for a differential-drive AMR with 2D LiDAR:

3.4 Lifecycle Management

Nav2 nodes implement ROS2 lifecycle states, providing structured startup and shutdown. This is critical for production robots where sensors must initialize before navigation begins. The lifecycle sequence is: unconfigured -> configure() -> inactive -> activate() -> active. The Nav2 lifecycle_manager orchestrates this sequence across all navigation nodes, ensuring correct ordering (costmaps before planner, planner before controller).

4. MoveIt2 for Manipulation

MoveIt2 is the standard motion planning framework for robotic arms in ROS2. It provides inverse kinematics solvers, collision-aware motion planning, grasp generation, and trajectory execution with real-time control. MoveIt2 supports any robot described by a URDF/XACRO model and integrates with all major industrial arm platforms (Universal Robots, FANUC, ABB, KUKA, Franka Emika).

4.1 Motion Planning Pipeline

MoveIt2's planning pipeline processes motion requests through several stages:

1. Kinematics: IK solvers (KDL, TRAC-IK, or BioIK) compute joint configurations for desired end-effector poses. TRAC-IK typically finds solutions 2-3x faster than KDL with higher success rates near joint limits.
2. Planning: OMPL (Open Motion Planning Library) provides sampling-based planners -- RRTConnect for fast bi-directional planning, RRT* for optimal paths, PRM for multi-query scenarios. Pilz Industrial Motion Planner adds LIN (linear), PTP (point-to-point), and CIRC (circular) motion primitives required by industrial standards.
3. Collision Checking: FCL (Flexible Collision Library) performs continuous collision detection against the planning scene (robot self-collision, known obstacles, octomap from depth sensors). Checking runs at microsecond granularity per configuration.
4. Trajectory Processing: Time-parameterization (TOTG or iterative spline) converts geometric paths into time-optimal, jerk-limited trajectories respecting joint velocity, acceleration, and jerk constraints.
5. Execution: MoveIt2 servo enables real-time Cartesian velocity control for teleoperation or visual servoing, publishing joint commands at 100-1000 Hz.

4.2 Grasp Planning

For pick-and-place applications, MoveIt2 integrates with grasp planners that generate candidate grasps from object geometry or point cloud data. The pipeline is: (1) segment the target object from the scene, (2) generate grasp candidates (approach vector, gripper width, pre-grasp offset), (3) filter candidates by IK feasibility and collision, (4) rank by grasp quality metric, (5) execute the highest-ranked grasp with approach-grasp-retreat sequence.

5. Perception Pipeline -- SLAM, Point Clouds & Object Detection

5.1 SLAM Algorithms in ROS2

Simultaneous Localization and Mapping (SLAM) is the foundation of autonomous robot navigation. ROS2 supports multiple SLAM implementations, each with distinct strengths:

SLAM Toolbox is the recommended starting point for 2D indoor navigation. It provides both online (real-time) and offline (post-processing) mapping modes, supports serialization of maps for later re-use, and integrates directly with Nav2 through the /slam_toolbox node. For production warehouses, we recommend building a map offline with high-quality scans, then using AMCL (Adaptive Monte Carlo Localization) for online localization against the saved map.

5.2 Point Cloud Processing

3D perception pipelines in ROS2 process point clouds from depth cameras (Intel RealSense, Orbbec) or 3D LiDAR (Velodyne, Ouster, Livox) through several stages:

• Filtering: VoxelGrid downsampling reduces point density (e.g., from 300K to 30K points) while preserving geometric features. PassThrough filters remove points outside the region of interest. StatisticalOutlier removal eliminates noise.
• Segmentation: RANSAC plane extraction identifies floor and table surfaces. Euclidean cluster extraction segments individual objects from the remaining points. Region-growing segmentation handles more complex geometries.
• Registration: ICP (Iterative Closest Point) or NDT (Normal Distributions Transform) aligns point clouds from multiple viewpoints into a unified scene model.
• Object Recognition: Deep learning models (PointNet++, VoteNet, or projected 2D detectors like YOLOv8 with depth back-projection) classify and localize objects from point cloud data.

5.3 Object Detection Integration

Production perception systems typically fuse 2D detection (faster, more mature) with 3D depth data. The pipeline detects objects in the RGB image using YOLOv8 or RT-DETR, then projects the 2D bounding box into 3D space using the aligned depth frame and camera intrinsics. This yields a 3D bounding box with pose estimation suitable for grasp planning or obstacle representation.

6. Industrial ROS2 -- micro-ROS, PLC Integration & OPC-UA

6.1 micro-ROS for Embedded Systems

micro-ROS extends the ROS2 communication graph down to resource-constrained microcontrollers (MCUs) running FreeRTOS, Zephyr, or NuttX. This enables sensors, motor controllers, and safety I/O boards to participate as first-class ROS2 nodes without a Linux-capable processor. micro-ROS supports publishers, subscribers, services, parameters, and even actions on MCUs with as little as 50KB of RAM.

The architecture uses a micro-ROS Agent running on a Linux host that bridges the MCU's XRCE-DDS (DDS for eXtremely Resource Constrained Environments) protocol to the full DDS network. Communication between MCU and Agent can use serial (UART), USB, UDP over Wi-Fi/Ethernet, or custom transports.

6.2 ROS2 + PLC Integration

Industrial facilities run PLCs (Programmable Logic Controllers) for machine control, safety interlocking, and process automation. Integrating ROS2 robots with existing PLC infrastructure requires bridging two paradigms: ROS2's DDS publish-subscribe model and the PLC's cyclic scan-based execution model.

Common integration patterns include:

• OPC-UA Bridge: OPC-UA (Open Platform Communications Unified Architecture) is the standard for industrial interoperability. The ros2_opc_ua_bridge package exposes ROS2 topics and services as OPC-UA nodes, allowing SCADA systems and PLCs with OPC-UA clients to read robot state and send commands. This is the recommended approach for greenfield industrial deployments.
• EtherCAT via ethercat_driver_ros2: For hard real-time control of servo drives and I/O modules, the ethercat_driver_ros2 package provides a ROS2 control hardware interface for EtherCAT buses. This enables MoveIt2 to control industrial servo drives directly with sub-millisecond cycle times.
• Modbus TCP/RTU: The simplest integration for legacy PLCs. A ROS2 node acts as a Modbus TCP client, reading PLC registers for sensor data and writing registers for robot commands. Suitable for non-safety, non-real-time coordination.
• MQTT + Node-RED: For IoT-style integration where PLCs publish to an MQTT broker and a ROS2 MQTT bridge subscribes. Low-code orchestration via Node-RED provides visual workflow configuration for non-robotics engineers.

6.3 Safety Standards

Industrial ROS2 deployments must comply with safety standards including ISO 10218 (industrial robot safety), ISO/TS 15066 (collaborative robot operation), and IEC 62443 (industrial cybersecurity). While ROS2 itself is not safety-certified, the architecture supports safety-rated implementations through:

• Safety-rated PLC: All safety functions (emergency stop, speed monitoring, zone restriction) are implemented on a dedicated safety PLC (SIL 3 / PLe rated), communicating with ROS2 for coordination but never depending on ROS2 for safety.
• DDS-Security (SROS2): Authentication, encryption, and access control for all ROS2 communication. Prevents unauthorized command injection or telemetry spoofing.
• Watchdog patterns: ROS2 nodes publish heartbeats; if the safety PLC does not receive a heartbeat within the configured timeout, it triggers a safe stop.

7. Real-Time ROS2 -- DDS QoS, RT Kernels & Scheduling

Real-time performance in robotics means deterministic execution within bounded time limits -- not necessarily fast, but predictable. A motor controller that occasionally takes 50ms instead of 1ms is more dangerous than one that consistently takes 5ms. ROS2 provides the building blocks for real-time systems, but achieving true determinism requires careful configuration at every layer: OS kernel, DDS middleware, memory allocation, and application code.

7.1 DDS Quality of Service Profiles

DDS QoS policies are the primary mechanism for controlling communication behavior in ROS2. Critical QoS parameters for real-time systems:

• Reliability: RELIABLE guarantees delivery (with retransmission); BEST_EFFORT drops messages under congestion. Use RELIABLE for commands, BEST_EFFORT for high-frequency sensor data.
• Durability: TRANSIENT_LOCAL delivers late-joining subscribers the last N published messages; VOLATILE only delivers messages published after subscription. Use TRANSIENT_LOCAL for map data and configuration topics.
• Deadline: Specifies the maximum expected period between messages. If a publisher misses a deadline, the subscriber's listener is notified. Critical for watchdog patterns.
• Liveliness: AUTOMATIC (DDS monitors participant liveness) or MANUAL_BY_TOPIC (application must explicitly assert liveness). Use MANUAL_BY_TOPIC for safety-critical heartbeats.
• History: KEEP_LAST(N) retains only the last N samples; KEEP_ALL retains all (bounded by resource limits). Use KEEP_LAST(1) for state topics (latest value is all that matters).

7.2 RT Kernel Configuration

For sub-millisecond determinism, deploy ROS2 on a PREEMPT_RT patched Linux kernel. Ubuntu 24.04 includes the RT kernel as an optional install (linux-image-realtime). Key system-level configurations for real-time ROS2:

• CPU isolation: Use isolcpus=2,3 kernel parameter to reserve CPU cores exclusively for ROS2 processes, preventing interference from other system tasks.
• Thread priority: Set ROS2 executor threads to SCHED_FIFO priority 80+ using pthread_setschedparam() or chrt at launch.
• Memory locking: Call mlockall(MCL_CURRENT | MCL_FUTURE) at process startup to prevent page faults from swapping.
• Disable CPU frequency scaling: Set governor to performance mode to eliminate frequency transition latency.
• DDS shared memory: Enable CycloneDDS shared-memory transport (via Iceoryx) to bypass the kernel network stack entirely for same-host communication.

8. Simulation -- Gazebo, Isaac Sim & Webots

Simulation is non-negotiable in professional ROS2 development. It enables algorithm validation, regression testing, CI/CD integration, and synthetic data generation without hardware. The ROS2 ecosystem supports multiple simulators, each with distinct capabilities.

8.1 Gazebo Harmonic (Recommended Default)

Gazebo Harmonic (gz-harmonic, released 2024) is the primary simulator for ROS2 development. It replaces the legacy Gazebo Classic with a modern, modular architecture featuring improved physics, rendering, and sensor simulation. Key capabilities:

• gz-ros2-control: Direct integration with ros2_control for simulated hardware interfaces. Your controller configuration works identically in simulation and on real hardware.
• Sensor plugins: High-fidelity simulation of LiDAR (multi-echo, intensity), cameras (RGB, depth, thermal), IMUs, GPS, contact sensors, and force-torque sensors with configurable noise models.
• Multi-robot: Native support for multiple robots in a single world with independent namespaces and tf trees.
• Distributed simulation: Run physics, rendering, and sensors on separate processes or machines for large-scale simulations.

8.2 NVIDIA Isaac Sim

Isaac Sim provides photorealistic rendering with RTX ray tracing, GPU-accelerated PhysX 5 physics, and built-in tools for synthetic data generation (domain randomization, automatic labeling). Its ROS2 bridge publishes sensor data, tf transforms, and joint states directly onto the ROS2 network. Isaac Sim excels for:

• Training perception models with synthetic data (sim-to-real transfer)
• Digital twin validation of warehouse layouts before physical deployment
• Reinforcement learning with massively parallel environments (10,000+ concurrent scenes on a single GPU)
• Photo-realistic visualization for stakeholder demos

8.3 URDF/Xacro Robot Description

Robot models in ROS2 are defined using URDF (Unified Robot Description Format) and its macro-enabled variant Xacro. A well-structured Xacro model parameterizes dimensions, mass properties, and sensor placement for easy reconfiguration.

9. Deployment & DevOps -- Docker, CI/CD & OTA Updates

9.1 Containerized ROS2 Deployment

Docker containers have become the standard deployment mechanism for ROS2 applications. Containers provide reproducible builds, dependency isolation, and simplified fleet-wide updates. A well-structured ROS2 Docker image uses multi-stage builds to minimize image size and separate build-time dependencies from runtime.

9.2 CI/CD Pipeline

A robust CI/CD pipeline for ROS2 projects automates building, testing, and deploying robot software. We recommend GitHub Actions or GitLab CI with the following stages:

1. Lint & Format: Run ament_lint_auto, ament_clang_format, ament_flake8, and ament_xmllint to enforce code style.
2. Build: Compile the workspace with colcon build in a Docker container matching the target ROS2 distribution.
3. Unit Tests: Execute colcon test for gtest (C++) and pytest (Python) test suites. Publish test results as artifacts.
4. Integration Tests: Launch the full navigation stack in Gazebo headless mode, send navigation goals, and verify the robot reaches them within tolerance. Use launch_testing for orchestrated scenario testing.
5. Build Docker Image: Build and push the production Docker image to a container registry (ECR, GCR, or self-hosted).
6. Deploy: For staging: deploy to a test robot via docker-compose pull. For production: trigger OTA update through fleet management platform (Balena, AWS IoT Greengrass, or custom).

9.3 OTA Updates

Over-the-air updates are critical for maintaining robot fleets in the field. The update mechanism must be atomic (rollback on failure), bandwidth-efficient (delta updates), and staged (canary deployments to a subset of robots before fleet-wide rollout). Options include:

• Balena: Docker-based OTA for edge devices. Manages fleet of devices, supports delta image updates (90% bandwidth reduction), and provides a web dashboard for monitoring. Excellent for fleets of 10-1000 robots.
• AWS IoT Greengrass: Deploys ROS2 components as Greengrass components. Supports staged rollouts with automatic rollback. Integrates with AWS IoT Core for telemetry and command channels.
• Ubuntu Core + Snap: Snap packages provide transactional updates with automatic rollback. ROS2 workspaces can be packaged as snaps using the colcon-ros-snap plugin. Ubuntu Core provides a minimal, immutable OS base.
• SWUpdate + RAUC: Linux-native A/B partition update systems. The robot boots from partition A; updates are written to partition B. On reboot, the bootloader switches to B. If B fails health checks, automatic rollback to A.

10. Cloud Robotics with ROS2

10.1 Architecture Patterns

Cloud robotics extends the ROS2 computation graph from the robot to the cloud, enabling capabilities that exceed onboard compute -- large-scale SLAM map management, fleet-wide path optimization, ML model training and deployment, and centralized monitoring dashboards. The key architectural decision is partitioning computation between edge (robot), fog (on-premise server), and cloud tiers.

• Edge (robot): Real-time control loops, safety systems, local perception, sensor drivers. Latency requirement: <10ms. Must operate autonomously during network outages.
• Fog (on-premise): Fleet management, traffic coordination, map server, shared perception fusion. Latency requirement: <100ms. Connected to robots via dedicated Wi-Fi or 5G network.
• Cloud: Long-term data storage, analytics, ML training, remote monitoring dashboards, OTA update management. Latency tolerance: seconds to minutes.

10.2 AWS RoboMaker

AWS RoboMaker provides cloud services specifically designed for ROS/ROS2 robotics:

• Simulation: Run Gazebo simulations at scale in the cloud for regression testing, reinforcement learning, and parameter sweeps. Launch hundreds of parallel simulation worlds using AWS Batch.
• Fleet Management: Deploy and manage ROS2 applications across robot fleets using AWS IoT Greengrass. Monitor robot health, push configuration updates, and collect telemetry data.
• RoboMaker + S3: Upload SLAM maps, log files (rosbag2), and telemetry data to S3 for offline analysis. Use Athena or Spark for fleet-wide analytics.

10.3 Azure IoT + ROS2

Microsoft's Azure IoT ecosystem integrates with ROS2 through the azure_iot_hub_ros2 bridge, enabling:

• Device Twin: Mirror robot configuration and state as Azure IoT Device Twins. Changes to the desired state in the cloud propagate to robot parameters automatically.
• Azure Digital Twins: Build live digital twin models of your facility, with robot positions updated in real-time from ROS2 odometry topics.
• Azure ML + ROS2: Train perception models in Azure ML, export as ONNX, and deploy to robots via IoT Edge modules. The onnxruntime_ros2 package provides efficient inference integration.

10.4 Fog Computing for Multi-Robot Coordination

For latency-sensitive multi-robot coordination (fleet path planning, shared map updates, task allocation), a fog computing layer running on an on-premise server provides the best balance of performance and reliability. The fog server runs a ROS2 graph with fleet-level nodes:

11. Complete Code Examples

11.1 Python ROS2 Node -- Sensor Fusion

This example demonstrates a complete ROS2 Python node implementing an Extended Kalman Filter for fusing wheel odometry with IMU data. This pattern is fundamental for all mobile robot applications.

11.2 C++ ROS2 Node -- Motor Controller

A minimal C++ ROS2 node demonstrating a hardware interface for differential drive motor control via CAN bus. This pattern is the foundation for the ros2_control hardware interface.

11.3 Complete Launch File

A production launch file that brings up the full navigation stack -- robot state publisher, sensor drivers, SLAM or localization, Nav2, and Rviz2 for visualization.

12. APAC ROS2 Ecosystem & Community

12.1 Vietnam

Vietnam's ROS2 ecosystem is rapidly growing, driven by the country's expanding robotics manufacturing sector and its strong software engineering talent pool. Vietnam produces over 50,000 engineering graduates annually, and universities including VNU-HCM, Hanoi University of Science and Technology, and Da Nang University of Technology are incorporating ROS2 into their robotics curricula.

Key developments in the Vietnamese ROS2 ecosystem:

• Manufacturing robotics: Vietnamese electronics and automotive factories (Samsung, LG, VinFast) are deploying ROS2-based AMRs for intralogistics, replacing legacy AGV systems with flexible navigation. The ROS2 + micro-ROS stack allows integration with existing Mitsubishi and Siemens PLCs on the factory floor.
• Agricultural robotics: Research groups at Can Tho University and Nong Lam University are developing ROS2-based autonomous spraying drones and harvesting robots for the Mekong Delta's rice and fruit farms.
• Talent availability: ROS2 developers in Vietnam command $1,500-3,500/month (compared to $8,000-15,000 in the US/EU), making Vietnam an attractive location for robotics R&D centers. Seraphim Vietnam provides ROS2 development teams for APAC robotics companies.

12.2 Japan & South Korea

Japan and South Korea are the largest ROS2 markets in APAC. Japan's TIER IV (Autoware) is the leading contributor to ROS2-based autonomous driving software, and SoftBank Robotics uses ROS2 for its commercial service robots. In South Korea, ROBOTIS (creators of TurtleBot and Dynamixel actuators) is a founding ROS2 ecosystem contributor, and Naver Labs operates one of Asia's largest indoor robot fleets running ROS2.

12.3 Singapore & Southeast Asia

Singapore's Advanced Remanufacturing and Technology Centre (ARTC) and A*STAR research labs actively contribute to ROS2 packages for industrial applications. The National Robotics Programme funds ROS2 development for healthcare, logistics, and facilities management. In Thailand, the EEC Smart Factory initiative is driving ROS2 adoption in automotive manufacturing, while Indonesian startups are building ROS2-based delivery robots for Jakarta's dense urban environment.

12.4 Contributing to the Ecosystem

The ROS2 ecosystem thrives on open-source contributions. Whether you are fixing a documentation bug, contributing a new Nav2 plugin, or sharing a hardware driver, the community welcomes contributions. Key contribution pathways:

• ROS Discourse: The primary discussion forum for design proposals (REPs), troubleshooting, and announcements.
• GitHub Organizations: ros2, ros-navigation, moveit, micro-ROS, gazebosim -- each maintains repositories accepting pull requests.
• ROSCon: The annual conference (with APAC-specific ROSCon JP and ROSCon events) for presenting new work and networking.
• ROS2 Documentation: The official docs site accepts contributions via GitHub, and localization efforts (Japanese, Korean, Chinese) are ongoing.