[Documentation] [TitleIndex] [WordIndex

Planet ROS

Planet ROS - http://planet.ros.org

Planet ROS - http://planet.ros.org[WWW] http://planet.ros.org


ROS Industrial: PLCnext ROS Bridge: Enabling Hardware Interoperability Between Industrial PLCs and ROS

For developers already working with ROS, the integration of industrial fieldbuses, I/Os, and functional safety into robotic applications often introduces unexpected challenges. ROS offers a flexible and modular software framework, although connecting it to industrial automation hardware typically requires additional integration layers and specialized knowledge.

This led to the idea of creating a solution that allows ROS developers to leverage a PLC where it excels, for example in deterministic control, industrial communication, and safety, while high performance computation and complex logic remain handled within ROS.

PLCnext Technology Architecture Overview

PLCnext Controls run PLCnext Linux, a real-time capable operating system that hosts the PLCnext Runtime. The Runtime manages deterministic process data and stores it in the Global Data Space (GDS).

Key architectural components :

PLCnext ROS Bridge

Concept

At its core, the PLCnext ROS Bridge is a custom ROS node with dedicated services running inside a Docker container, packaged as a PLCnext App. It provides a bidirectional communication gateway between the PLCnext Global Data Space (industrial side) and ROS topics (robotics side).

To illustrate this, consider a motor connected to the PLC via EtherCAT/FSoE or PROFINET/PROFIsafe. The motor, along with its associated safety functions, can be managed through simple PLC logic and represented by a set of variables. Depending on the implementation, these variables, such as setpoints, command velocities, etc., can be exposed to ROS. When the navigation stack publishes a command velocity, the ROS Bridge, as a subscriber to this topic, writes the received values to the corresponding variable on the PLC side. Likewise, information such as safety status or system state can be sent from the PLC to ROS and made available through a defined topic.

Commissioning Workflow

The ROS Bridge Node is generated through an automated code-generation process. This process is driven by the Interface Description File (IDF), which defines the PLC instance paths (variables) that should be exposed to ROS.

A typical build process performs the following steps:

  1. Building the ROS Packages
    • Parse the IDF and generate the source code for the topic, publisher and subscribers
    • Build the ROS Node
  2. Place the resulting binaries and gRPC dependencies into a Docker image with a minimal ros-core installation.
  3. Package the Docker image, together with required metadata, into a read-only PLCnext App.

The resulting App can be deployed to a PLCnext Controller using the Web-Based Management (WBM) interface. While it is possible to build everything in a local environment, the project is designed to be built via CI/CD. An example pipeline can also be found in the GitHub repository.

Runtime Behaviour

After installation, the App starts the container defined via the compose file. Inside this container, the generated ROS Node connects to the Global Data Space using the built gRPC client and then exposes the selected PLC variables via ROS publishers and subscribers. This enables ROS developers to integrate automation components, such as sensors, actuators, I/O modules, and fieldbus devices, into a ROS-based architecture through the GDS. Moreover, the Bridge sets up a set of services that enable users to read and write information at runtime.

Further Reading

More Information about the PLCnext Technology:

[WWW] https://rosindustrial.org/news/2026/3/27/plcnext-ros-bridge-enabling-hardware-interoperability-between-industrial-plcs-and-ros

ROS Discourse General: Questions on Zero-Copy for Variable-Size Messages (PointCloud2) with Iceoryx in ROS 2

Hi everyone,

I am currently working on optimizing high-bandwidth sensor data transmission (specifically LiDAR point clouds) using ROS 2 and Iceoryx for zero-copy communication.

I have successfully set up the Iceoryx environment and confirmed zero-copy works for fixed-size types. However, I am facing challenges when applying this to variable-size messages, such as sensor_msgs/msg/PointCloud2.

As I understand it, Iceoryx typically requires pre-allocated memory pools with fixed chunks. In the case of PointCloud2, the data size can vary depending on the LiDAR’s points (in my case, around 5.2MB per message).

I have two specific questions:

1. Best practices for variable-size data like PointCloud2

How should we handle messages where the size is not strictly fixed at compile-time while still maintaining zero-copy benefits? Should we always pre-allocate the “worst-case” maximum size for the underlying buffers? If anyone has implemented this for sensor_msgs/msg/PointCloud2 or similar dynamic types, I would appreciate any advice or examples.

2. Tuning RouDi Configuration (size and count)

Regarding the roudi_config.toml (or the RouDi memory pool setup), what is the general rule of thumb for determining the optimal size and count?

For high-resolution LiDAR data:

I’ve already got Iceoryx installed and basic IPC working, but I want to ensure my configuration is production-ready for large-scale sensor data.

Thank you in advance for your insights!

2 posts - 2 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/questions-on-zero-copy-for-variable-size-messages-pointcloud2-with-iceoryx-in-ros-2/53585

ROS Discourse General: WEBINAR: Accelerating Robotics Development with Qt Robotics Framework

Join Qt Group Webinar

Accelerating Robotics Development with Qt Robotics Framework

Qt Robotics Framework (QRF) introduces a fast, reliable way to connect Qt‑based applications (QML and C++) with ROS2 middleware. By automatically generating strongly‑typed Qt/QML bindings from ROS2 interface definitions, QRF enables robotics teams to integrate control, visualization, and simulation capabilities with minimal boilerplate and maximum safety.

In this webinar, Qt Group’s engineers and industry experts demonstrate how QRF simplifies prototyping, reduces integration complexity, and helps teams move rapidly from concept to production.

Whether you’re building robot controllers, diagnostics dashboards, or simulation environments, Qt Robotics Framework reduces the development cycle and improves reliability across your robotics stack.

Speakers:

Accelerating Robotics Development with Qt Robotics Framework

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/webinar-accelerating-robotics-development-with-qt-robotics-framework/53584

ROS Discourse General: ROS2 Studio — GUI tool for performance monitoring, bag operations and system dashboard

Hi ROS community! :waving_hand:

I’d like to share a tool I built — ROS2 Studio, a single GUI that brings together the most common ROS2 monitoring and bag operations in one place.

What is ROS2 Studio?

ROS2 Studio is a PyQt5-based desktop GUI that runs as a native ROS2 CLI extension (ros2 studio). Instead of juggling multiple terminal windows, everything is accessible from one interface.

Features

Installation

cd ~/ros2_ws/src
git clone https://github.com/Sourav0607/ROS2-STUDIO
cd ~/ros2_ws
colcon build --packages-select ros2_studio
source install/setup.bash
ros2 studio

Compatibility

Tested on ROS2 Humble and Jazzy on Ubuntu 22.04.

Links

Feedback, issues, and contributions are very welcome! I’m actively maintaining this and plan to add more features based on community input.

— Sourav

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/ros2-studio-gui-tool-for-performance-monitoring-bag-operations-and-system-dashboard/53554

ROS Discourse General: Remote Control of Robotic Arms – Using a Standard Gamepad

Gamepad Control for PiPER Manipulator

1. Abstract

This document implements intuitive control of the PiPER robotic arm using a standard gamepad. With a common gamepad, you can operate the PiPER manipulator in a visualized environment, delivering a precise and intuitive control experience.

Tags

PiPER Manipulator, Gamepad Teleoperation, Joint Control, Pose Control, Gripper Control, Forward & Inverse Kinematics

2. Repositories

3. Function Demo

20260326-173204

4. Environment Setup

Clone the project and enter the root directory:

git clone https://github.com/kehuanjack/Gamepad_PiPER.git
cd Gamepad_PiPER

Install common dependencies and kinematics libraries (choose one option; pytracik is recommended):

Option 1: Based on pinocchio

(Python == 3.9; requires piper_ros and sourcing the ROS workspace, otherwise meshes will not be found)

conda create -n test_pinocchio python=3.9.* -y
conda activate test_pinocchio
pip3 install -r requirements_common.txt --upgrade
conda install pinocchio=3.6.0 -c conda-forge
pip install meshcat
pip install casadi

In main.py and main_virtual.py, select:from src.gamepad_pin import RoboticArmController

Option 2: Based on PyRoKi

(Python >= 3.10)

conda create -n test_pyroki python=3.10.* -y
conda activate test_pyroki
pip3 install -r requirements_common.txt --upgrade
pip3 install pyroki@git+https://github.com/chungmin99/pyroki.git@f234516

In main.py and main_virtual.py, select:from src.gamepad_limit import RoboticArmController orfrom src.gamepad_no_limit import RoboticArmController

Option 3: Based on cuRobo

(Python >= 3.8; CUDA 11.8 recommended)

conda create -n test_curobo python=3.10.* -y
conda activate test_curobo
pip3 install -r requirements_common.txt --upgrade
sudo apt install git-lfs && cd ../
git clone https://github.com/NVlabs/curobo.git && cd curobo
pip3 install "numpy<2.0" "torch==2.0.0" pytest lark
pip3 install -e . --no-build-isolation
python3 -m pytest .
cd ../Gamepad_PiPER

In main.py and main_virtual.py, select:from src.gamepad_curobo import RoboticArmController

Option 4: Based on pytracik

(Python >= 3.10)

conda create -n test_tracik python=3.10.* -y
conda activate test_tracik
pip3 install -r requirements_common.txt --upgrade
git clone https://github.com/chenhaox/pytracik.git
cd pytracik
pip install -r requirements.txt
sudo apt install g++ libboost-all-dev libeigen3-dev liborocos-kdl-dev libnlopt-dev libnlopt-cxx-dev
python setup_linux.py install --user

In main.py and main_virtual.py, select:from src.gamepad_trac_ik import RoboticArmController

5. Execution Steps

  1. Connect manipulator and activate CAN interface:sudo ip link set can0 up type can bitrate 1000000

  2. Connect gamepad:Connect the gamepad to the PC via USB or Bluetooth.

  3. Launch control script:Run python3 main.py or python3 main_virtual.py in the project directory.It is recommended to test with main_virtual.py first in simulation mode.

  4. Verify gamepad connection:Check console output to confirm the gamepad is recognized.

  5. Web visualization:Open a browser and go to http://localhost:8080 to view the manipulator status.

  6. Start control:Operate the manipulator according to the gamepad mapping.

6. Gamepad Control Instructions

6.1 Button Mapping

Button Short Press Function Long Press Function
HOME Connect / Disconnect manipulator None
START Switch high-level control mode (Joint / Pose) Switch low-level control mode (Joint / Pose)
BACK Switch low-level command mode (Position-Velocity 0x00 / Fast Response 0xAD) None
Y Go to home position None
A Save current position Clear current saved position
B Restore previous saved position None
X Switch playback order Clear all saved positions
LB Increase speed factor (high-level) Decrease speed factor (high-level)
RB Increase movement speed (low-level) Decrease movement speed (low-level)

6.2 Joystick & Trigger Functions

Control Joint Mode Pose Mode
Left Joystick J1 (Base rotation): Left / RightJ2 (Shoulder): Up / Down End-effector X / Y translation
Right Joystick J3 (Elbow): Up / DownJ6 (Wrist rotation): Left / Right End-effector Z translation & Z-axis rotation
D-Pad J4 (Wrist yaw): Left / RightJ5 (Wrist pitch): Up / Down End-effector X / Y-axis rotation
Left Trigger (LT) Close gripper Close gripper
Right Trigger (RT) Open gripper Open gripper

6.3 Special Functions

6.3.1 Gripper Control

6.3.2 Speed Control

6.3.3 Position Memory

Notes

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/remote-control-of-robotic-arms-using-a-standard-gamepad/53550

ROS Discourse General: FusionCore, which is a ROS 2 Jazzy sensor fusion package (robot_localization replacement)

Hey everyone,
I’ve been working on FusionCore for the last few months… it’s a ROS 2 Jazzy sensor fusion package that aims to bridge the gap left by the deprecation of robot_localization.

There wasn’t anything user-friendly available for ROS 2 Jazzy. It merges IMU, wheel encoders, and GPS/GNSS into a single, reliable position estimate at 100Hz. No need for manual covariance matrices…. just one YAML config file.

GitHub: https://github.com/manankharwar/fusioncore

I respond to issues within 24 hours. If you’re working on a wheeled robot with GPS on ROS 2 Jazzy and hit problems….. open an issue or reply here.

6 posts - 3 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/fusioncore-which-is-a-ros-2-jazzy-sensor-fusion-package-robot-localization-replacement/53502

ROS Discourse General: ROSCon Global 2026: Call for Sponsors

ROSCon Global 2026: Call for Sponsors

Hi Everyone,

The ROSCon executive committee is happy to announce that sponsorship opportunities are now available for ROSCon Global 2026 in Toronto (September 22-24)!

If you would like to get your product or service in front of over a thousand robot application developers, decision makers, and students, ROSCon Global is the place to be!

This year we are aiming for over 1,000 attendees, and if this event is anything like ROSCon 2025, our attendees will represent:

This year we will be offering our largest number of sponsorship opportunities yet, including the chance to:

Our full ROSCon Global 2026 sponsorship prospectus is now available on the ROSCon website, and you can start your ROSCon journey by emailing roscon-2026-ec@roscon.org. We recommend you start your sponsorship conversation as soon as possible, as ROSCon booths and sponsorship opportunities tend to sell out quickly!

2 posts - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/roscon-global-2026-call-for-sponsors/53498

ROS Discourse General: iRoboCity2030 Summer School 2026: ROS 2, AI and Field Robotics

International iRoboCity2030 Summer School 2026: ROS 2, AI and Field Robotics

Madrid, Spain, 22–26 June 2026

Web: iRoboCity2030 Summer School 2026 – ROS 2, AI and Field Robotics
Email: irobocity2030@gmail.com

Registration deadlines:

MOTIVATION AND DESCRIPTION

The iRoboCity2030 Summer School 2026, entitled “ROS 2: AI and Field Robotics”, offers undergraduate and graduate students from all over the world an intensive one-week experience focused on the technologies driving the new generation of autonomous and intelligent robots. The program combines theoretical and practical training in ROS 2 (Robot Operating System 2), Artificial Intelligence, and Field Robotics, guided by researchers from leading universities and technological centers in Madrid. Over five days, participants will advance both theoretical knowledge and practical skills, from the fundamentals of ROS 2 to the application of AI techniques in different field robotics domains such as autonomous driving, quadrupedal robots, agricultural robotics, aerial robotics.

In addition to the academic program, the summer school will feature two plenary lectures delivered by internationally recognized leaders in the ROS 2 ecosystem. The first will be given by Steve Macenski (OpenNavigation), lead developer of the Nav2 system, widely regarded as the reference standard for autonomous robot navigation in ROS 2. The second will be delivered by Davide Faconti, creator of BehaviorTrees.CPP and Groot, tools that are extensively used for developing robotics applications based on Behavior Trees.

The school’s pedagogical approach is strongly practical and collaborative: participants will learn by doing, combining knowledge of artificial intelligence, control, and perception with their direct application in ROS 2, both in simulation environments and on real robotic platforms. Beyond its technical dimension, the school promotes intercultural collaboration and international teamwork, creating a dynamic environment for learning and experimentation.
This summer school is part of the iRoboCity2030 initiative, the robotics innovation network of the Community of Madrid, and represents a joint effort by the region’s leading universities and research centers to promote advanced training and knowledge transfer in robotics and artificial intelligence.

LIST OF SPEAKERS AND INSTRUCTORS

Steve Macenski (OpenNavigation) — “Nav2 & ROS 2 Overview: Techniques & Applications Powering an Industry”
Davide Faconti (BehaviorTrees.CPP / Groot) — “Being a roboticist in the era of AI: what changed and what didn’t”

Carlos Balaguer, UC3M
Francisco Martín Rico, URJC
José M. Cañas, URJC
Luis Miguel Bergasa, UAH
Fabio Sánchez, UAH
Miguel Antunes, UAH
Santiago Montiel, UAH
Rodrigo Gutiérrez, UAH
Christyan Cruz, UPM
Roemi Fernández, CSIC
Raúl Fernández, UCM

ORGANIZATION

This summer school is part of the iRoboCity2030 initiative, the Robotics Innovation Network of the Madrid Region. It represents a joint effort by leading universities and research institutions to promote advanced training and knowledge transfer in robotics and artificial intelligence.

SOCIAL EXPERIENCE

The Summer School will take place in the city centre of Madrid and well connected by public transport. The city is famous for its lively atmosphere, outdoor cafés, cultural events, and late-evening social life, providing countless opportunities to meet people and enjoy experiences beyond the classroom. With its warm climate, rich culture, excellent food, and safe, walkable neighborhoods, Madrid combines academic learning with an unforgettable social experience.

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/irobocity2030-summer-school-2026-ros-2-ai-and-field-robotics/53487

ROS Discourse General: Polka: A unified node for all pointcloud pre-processing/merging

Hello folks,

Point cloud pre-processing including deskewing, merging, and filtering traditionally requires a chain of nodes working in tandem, many of which are no longer actively maintained. Setting up these individual filtering stages often consumes excessive CPU cycles and precious DDS bandwidth.

What if you had a single, low-latency node that could voxellize, deskew, downsample, and merge scans in one go? By passing only mission-critical features to your odometry nodes and downstream, you significantly reduce lag and bandwidth usage across your entire navigation or SLAM stack. A single node to accomplish this.

I developed Polka to solve this. It’s a drop-in replacement for multiple pre-processing nodes and if you need to save CPU, you can run the entire pipeline on your GPU.

Latency across both being ~40ms.

Current features:

I’d love your feedback, and if you find the project useful, please consider leaving a star on GitHub!

GitHub - Pana1v/polka

4 posts - 2 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/polka-a-unified-node-for-all-pointcloud-pre-processing-merging/53457

ROS Discourse General: TechSolstice '26 (Annual Technical Fest of MIT Bengaluru)

Hello ROS Community,

Tech Solstice 2026 is the annual technology festival hosted by the Manipal Institute of Technology (MIT), Bengaluru, featuring a diverse lineup of competitive robotics events.

We invite students, robotics enthusiasts, and builders to participate in a series of hands-on challenges designed to test speed, control systems, autonomous navigation, and combat robotics.

Total Prize Pool: ₹2.6 Lakhs+

Robotics Events (further details can be found on the website)
• Robo Race
• Cosmo Clench
• Maze Runner
• Line Follower
• Robo Wars

Format & Timeline
Event Dates: 27 March – 29 March 2026

Participants will compete on-site across multiple rounds depending on the event format, with final winners determined through performance-based evaluation.

Participants are encouraged to utilize embedded systems, ROS-based architectures, simulation tools, and custom-built hardware where applicable.

Further details and registration:
https://techsolstice.mitblr.in

We look forward to participation from the robotics community.

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/techsolstice-26-annual-technical-fest-of-mit-bengaluru/53405

ROS Discourse General: Transitive Robotics Tryout | Cloud Robotics WG Meeting 2026-03-23

Please come and join us for this coming meeting at Mon, Mar 23, 2026 4:00 PM UTCMon, Mar 23, 2026 5:00 PM UTC, where we plan to try out Transitive Robotics. Transitive Robotics is a service that allows users to deploy and manage robots, including giving full-stack robotic capabilities. Capabilities include data capture and storage, which makes Transitive Robotics a useful case study for our focus on Logging & Observability.

Last session, we continued our tryout of the Canonical Observability Stack (COS) from the previous meeting. We were successful in hosting the full stack and viewing the public pages, as well as connecting a simulated robot to the stack. We could view logs and system statistics from the simulated robot. If you’re interested to watch the recorded part of the meeting, it is available on YouTube.

The meeting link for next meeting is here, and you can sign up to our calendar or our Google Group for meeting notifications or keep an eye on the Cloud Robotics Hub.

Hopefully we will see you there!

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/transitive-robotics-tryout-cloud-robotics-wg-meeting-2026-03-23/53385

ROS Discourse General: Mastering Nero – MoveIt2 Part II

Mastering Nero – MoveIt2 Part II

In the previous session, we built a complete MoveIt2 package from a URDF model using the MoveIt Setup Assistant, and realized motion planning and visual control of the robotic arm.

In this session, we will explain how to set up a co-simulation environment for MoveIt2 and Isaac Sim. By configuring the ROS Bridge, adjusting hardware interface topics, and integrating the URDF model, we will achieve seamless connection between the simulator and motion planning, providing a complete practical solution for robot algorithm development and system integration.

Abstract

Co-simulation of MoveIt2 and Isaac Sim

Tags

ROS2, MoveIt2, robotic arm, Nero

Repositories

Operating Environment

System: Ubuntu 22.04
ROS Version: Humble
Isaac Sim Version: 5.1

Download USD Model

We use the Nero USD model provided by AgileX Robotics:

cd ~/nero_ws/src
git clone https://github.com/agilexrobotics/agx_arm_sim

If you haven’t installed Isaac Sim or want to import your own URDF model, refer to:

Isaac_Sim Import PiPER URDF

Launch Isaac Sim

Navigate to the Isaac Sim folder, use the script to launch the ROS Bridge Extension, then click Start to launch Isaac Sim:

cd isaac-sim-standalone-5.1.0-linux-x86_64/
./isaac-sim.selector.sh

Then drag and drop the newly downloaded USD model into Isaac Sim to open it:

In the USD file, you need to add an ActionGraph for communication with the ROS side. The ActionGraph is as follows:

Configure ActionGraph

articulation_controller

Modify targetPrim according to actual conditions; targetPrim is generally /World/nero_description/base_link:

ros2_subscribe_joint_state

Modify topicName according to actual conditions; topicName must correspond to the URDF, here it is isaac_joint_commands:

ros2_publish_joint_state

Modify targetPrim and topicName according to actual conditions; targetPrim is generally /World/nero_description/base_link; topicName must correspond to the URDF, here it is isaac_joint_states:

After starting the simulation, use ros2 topic list in the terminal; the following topics can be viewed:

Modify MoveIt Package

Open nero_description.ros2_control.xacro and add topic parameters:

gedit nero_ws/src/nero_moveit2_config/config/nero_description.ros2_control.xacro

            <hardware>
                <!-- By default, set up controllers for simulation. This won't work on real hardware -->
                <!-- <plugin>mock_components/GenericSystem</plugin> -->
                <plugin>topic_based_ros2_control/TopicBasedSystem</plugin>
                <param name="joint_commands_topic">/isaac_joint_commands</param>
                <param name="joint_states_topic">/isaac_joint_states</param>
            </hardware>

Then save and compile the code, then launch MoveIt2:

cd ~/nero_ws
colcon build
source install/setup.bash
ros2 launch nero_moveit2_config demo.launch.py

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/mastering-nero-moveit2-part-ii/53369

ROS Discourse General: NWO Robotics API `pip install nwo-robotics - Production Platform Built on Xiaomi-Robotics-0

My name is Ciprian Pater, and I’m reaching out on behalf of PUBLICAE (formerly a student firm at UiA Nyskaping Incubator) to introduce you to NWO Robotics Cloud (nworobotics.cloud) - a comprehensive production-grade API platform we’ve built that extends and enhances the capabilities of the groundbreaking Xiaomi-Robotics-0 model. While Xiaomi-Robotics-0 represents a remarkable achievement in Vision-Language-Action modeling, we’ve identified several critical gaps between a research-grade model and a production-ready robotics platform. Our API addresses these gaps while showcasing the full potential of VLA architecture.

(Attaching some screenshots below for UX reference).

Technical whitepaper at https://www.researchgate.net/publication/401902987_NWO_Robotics_API_WHITEPAPER

NWO Robotics CLI COMMAND GROUPS

Install instantly via pip and start in seconds:

pip install nwo-robotics

Quick Start: nwo auth login → Enter your API key from: nworobotics.cloud → nwo robot “pick up the box”

═══════════════════════════════

• nwo auth - Login/logout with API key

• nwo robot - Send commands, health checks, learn params

• nwo models - List models, preview routing decisions

• nwo swarm - Create swarms, add agents

• nwo iot - Send commands with sensor data

• nwo tasks - Task planning and progress tracking

• nwo learning - Access learning system

• nwo safety - Enable real-time safety monitoring

• nwo templates - Create reusable task templates

• nwo config - Manage CLI configuration etc:

NWO ROBOTICS API v2.0 - BREAKTHROUGH CAPABILITIES

═══════════════════════════════════════

FEATURE | TECHNICAL DESCRIPTION

-------------------------|------------------------------------------

Model Router | Semantic classification + 35% latency

                     | reduction through intelligent LM selection

-------------------------|------------------------------------------

Task Planner | DAG decomposition with topological

                     | sorting + checkpoint recovery

-------------------------|------------------------------------------

Learning System | Vector database + collaborative filtering

                     | for parameter optimization

-------------------------|------------------------------------------

IoT Fusion | Kalman-filtered multi-modal sensor

                     | streams with sub-10cm accuracy

-------------------------|------------------------------------------

Enterprise API | SHA-256 auth, JWT sessions, multi-tenant

                     | isolation

-------------------------|------------------------------------------

Edge Deployment | 200+ locations, Anycast routing, <50ms

                     | latency, 99.99% SLA

-------------------------|------------------------------------------

Model Registry | Real-time p50/p95/p99 metrics + A/B testing

-------------------------|------------------------------------------

Robot Control | RESTful endpoints with collision detection

                     | + <10ms emergency stop

-------------------------|------------------------------------------

═════════════════

INTELLIGENT MODEL ROUTER (v2.0)

═════════════════

Our multi-model routing system analyzes natural language instructions

in real-time using semantic classification algorithms, automatically

selecting the optimal language model for each specific task type.

For OCR tasks, the router selects DeepSeek-OCR-2B with 97% accuracy;

for manipulation tasks, it routes to Xiaomi-Robotics-0. This

intelligent selection reduces inference latency by 35% while

improving task success rates through model specialization.

═════════════════

TASK PLANNER (Layer 3 Architecture)

═════════════════

The Task Planner decomposes high-level natural language instructions

into executable subtasks using dependency graph analysis and

topological sorting. When a user requests “Clean the warehouse,”

the system generates a directed acyclic graph of subtasks

(navigate→identify→grasp→transport→place) with estimated durations

and parallel execution paths. This hierarchical planning reduces

complex mission failure rates by implementing checkpoint recovery

at each subtask boundary.

═════════════════

LEARNING SYSTEM (Layer 4 - Continuous Improvement)

═════════════════

Our parameter optimization engine maintains a vector database of

task execution outcomes, using collaborative filtering algorithms

to recommend optimal grip forces, approach velocities, and grasp strategies based on historical performance data.

For fragile object manipulation, the system has learned that 0.28N grip force with

12cm/s approach velocity yields 94% success rates across 127 similar

tasks, automatically adjusting robot parameters without human

intervention.

═════════════════

IOT SENSOR FUSION (Layer 2 - Environmental Context)

═════════════════

The API integrates multi-modal sensor streams (GPS coordinates,

LiDAR point clouds, IMU orientation, temperature/humidity readings)

into the inference pipeline through Kalman-filtered sensor fusion.

This environmental awareness enables context-aware decision making -

for example, automatically reducing grip force when temperature

sensors detect a hot object, or adjusting navigation paths based

on real-time LiDAR obstacle detection with sub-10cm accuracy.

═════════════════

ENTERPRISE API INFRASTRUCTURE

═════════════════

We’ve implemented a complete enterprise API layer including X-API-Key

authentication with SHA-256 hashing, JWT token-based session

management, per-organization rate limiting with token bucket

algorithms, and comprehensive audit logging. The system supports

multi-tenant deployment with complete data isolation between

organizations, enabling commercial deployment scenarios that raw

model weights cannot address.

═════════════════

EDGE DEPLOYMENT (Global Low-Latency)

═════════════════

Our Cloudflare Worker deployment distributes inference across 200+

global edge locations using Anycast routing, achieving <50ms response

times from anywhere in the world through intelligent geo-routing.

The serverless architecture eliminates cold start latency entirely

while providing automatic DDoS protection and 99.99% uptime SLA -

critical capabilities for production robotics deployments that

require sub-100ms control loop response times.

═════════════════

MODEL REGISTRY & PERFORMANCE ANALYTICS

═════════════════

The Model Registry maintains real-time performance metrics including

per-model success rates, p50/p95/p99 latency percentiles, and

cost-per-inference calculations across different hardware

configurations. This telemetry enables data-driven model selection

and automatic A/B testing of model versions, ensuring optimal

performance as your Xiaomi-Robotics-0 model evolves.

═════════════════

ROBOT CONTROL API

═════════════════

We provide RESTful endpoints for real-time robot state querying

(joint angles, gripper position, battery telemetry) and action

execution with safety interlocks. The action execution pipeline

includes collision detection through bounding box overlap

calculations, emergency stop capabilities with <10ms latency, and

execution confirmation through sensor feedback loops - essential

safety features absent from the base model inference API.

MULTI-AGENT COORDINATION

Enable multiple robots to collaborate on complex tasks. Master

agents break down objectives and distribute work to worker agents

with shared memory and handoff zones.

→ Swarm intelligence, task delegation, conflict resolution

FEW-SHOT LEARNING

Robots learn new tasks from just 3-5 demonstrations instead of

programming. Skills adapt to user preferences and improve

continuously from execution feedback.

→ Learn from demonstrations, skill composition, personalisation.

ADVANCED PERCEPTION

Multi-modal sensor fusion (camera, depth, LiDAR, thermal) with

6DOF pose estimation. Detect humans, recognize gestures, predict

motion, and calculate optimal grasp points.

→ 3D scene understanding, human detection, gesture recognition

SAFETY LAYER

Continuous safety validation with 50ms checks. Force/torque

limits, human proximity detection, collision prediction,

configurable safety zones, and full audit logging for compliance.

→ Real-time monitoring, emergency stop, collision prediction

GESTURE CONTROL

Real-time hand gesture recognition for intuitive robot control.

Wave to pause/stop, point to direct attention, draw paths for

navigation. Works from 0.5-3 meters with 95%+ accuracy.

→ Wave to stop, point to indicate location

VOICE WAKE WORD

Always-listening voice activation with custom wake words.

Natural language command parsing with intent extraction. Supports

multiple languages and voice profiles for personalised interactions.

→ “Hey Robot, [command]”

PROGRESS UPDATES

Real-time task progress reporting with time estimation.

Subscribable WebSocket streams for live updates. Milestone

notifications when tasks reach defined checkpoints.

→ “Task 60% complete, 2 minutes remaining”

FAILURE RECOVERY

Intelligent error recovery with strategy adaptation. If grasp

fails, automatically try different angles, grip forces, or

approaches. Escalates to human operator only after exhausting

recovery options.

→ Auto-retry with different angles/strategies

TASK TEMPLATES

Pre-configured task sequences for common workflows. Schedule-based

activation with variable substitution. Templates can be nested,

parameterized, and shared across robot fleets.

→ “Morning routine”, “Closing procedures”

PHYSICS-AWARE PLANNING

Motion planning with real-world physics simulation. Detects

impossible trajectories, unstable grasps, and collision risks

before execution. Integrates with MuJoCo and Isaac Sim.

→ Simulate before execute, avoid physics violations

REAL-TIME SAFETY

Runtime safety monitoring with microsecond latency. Dynamically

adjusts robot speed based on proximity to humans. Emergency stop

with guaranteed response time under 10ms.

→ Continuous monitoring, dynamic speed adjustment

SEMANTIC NAVIGATION

Navigate using natural language landmarks instead of coordinates.

Understand spatial relationships (“next to the table”, "behind

the sofa"). Dynamic path recalculation when obstacles appear.

Thank you in advance for your consideration and feedback.

Sincere Regards

Ciprian Pater

PUBLICAE / NWO Robotics

+4797521288

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/nwo-robotics-api-pip-install-nwo-robotics-production-platform-built-on-xiaomi-robotics-0/53349

ROS Discourse General: JdeRobot Google Summer of Code 2026

Hi folks,

we at JdeRobot org are partipating in Google Summer of Code 2026. All our proposed projects are on open source Robotics, and most of them (7/8) in ROS 2 related software. They are all described at our ideas list for GSoC-2026, including their summary and illustrative videos.

Motivated candidates are welcome :slight_smile: Please check the Application Instructions, as we request a Technical Challenge and some interactions in our GitHub repositories before talking to our mentors and submitting your proposal.

Cheers,

JoseMaria

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/jderobot-google-summer-of-code-2026/53344

ROS Discourse General: Introducing the Connext Robotics Toolkit for ROS 2

Hi ROS 2 Community,

I’m pleased to announce that RTI released enhanced support for ROS 2 and rmw_connextdds today. The new Connext Robotics Toolkit makes it much easier for ROS users to take advantage of Connext and DDS features to improve their development experience.

As many of you know, RTI has supported ROS 2 since the very beginning by providing our core DDS implementation at no charge for non-commercial use. The Connext Robotics Toolkit extends that support to our full Connext Professional product. This includes our broader platform around DDS – things like network tuning and debugging tools, system observability, and diverse network support, from shared memory to WAN.

In addition, we’re expanding our free license to include commercial prototyping. This means startups and other product teams building ROS-based systems can now take advantage of Connext at no charge. Starting with production-grade communication infrastructure will make it easier to scale from prototype to deployment.

The Connext Robotics Toolkit is currently available for Kilted Kaiju and will be available for Lyrical Luth upon its release. If you’re exploring ways to leverage ROS in commercial systems or looking at RMW options beyond the default, you can find more details and installation instructions here: Connext Robotics Toolkit for ROS | RTI

Happy to answer questions or discuss with anyone interested.

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/introducing-the-connext-robotics-toolkit-for-ros-2/53311

ROS Discourse General: Per-robot economic settlement for industrial ROS2 fleets

As ROS2 fleets move into commercial deployments serving external clients, one infrastructure gap is shared economic verification between the fleet operator and their customer. The operator’s internal logs don’t give the client independent verification of what work was completed, leading to manual reconciliation and disputes as fleets scale.

Built a settlement layer that monitors ROS2 lifecycle events and generates verified timestamped records per robot per completed task. Both operator and client can verify independently. Each robot builds a portable work history over time useful for service billing, equipment valuation, and proving utilization to potential customers.

Already compatible with standard ROS2 lifecycle management. Integration details here:https://github.com/FoundryNet/foundry_net_MINT/blob/main/FoundryNet%20API%20Client/foundry-client.py

Interested in feedback from anyone deploying ROS2 fleets commercially and dealing with the billing side of multi-client operations.

Cheers!

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/per-robot-economic-settlement-for-industrial-ros2-fleets/53268

ROS Discourse General: [Show and Tell] ROS 2 Blueprint Studio: Visual Node Editor & Boilerplate Generator (Alpha)

Hi everyone!

Like many of us, I appreciate the power and flexibility of ROS 2, but I’ve always found the amount of manual boilerplate to be a bottleneck for rapid development. Keeping track of all the configuration details making sure CMakeLists.txt and package.xml are perfectly synced, or manually wiring launch files and topic connections takes a significant amount of time. I wanted to find a way to automate this infrastructure setup so I could focus purely on writing the actual robotics logic.

To solve this, I started building ROS 2 Blueprint Studio a visual node-based editor (inspired by Unreal Engine Blueprints) designed to take the routine off your shoulders.

Under the Hood (Architecture) I tried to avoid any “black magic” and stick entirely to standard ROS 2 practices:

1. Code Generation & Build System The studio doesn’t compile the code itself; it acts as a smart templating engine. Creating a standard node generates a base C++ template. If you duplicate a node (from the palette or canvas), it creates an independent file with a new name and copied code. Modifying the copy doesn’t break the parent. For the actual build, it relies on standard colcon build under the hood.

2. File Watcher & Dependency Tree To build the dependency tree, I wrote a custom FileWatcher. Before building, it scans the files to check for includes and node communication. For performance, it only parses files that have been modified. (I realize this might theoretically cause “phantom connections” on massive graphs, so I plan to add a forced full-rebuild mode in the future).

3. Topic Routing (Two Approaches) Node linking currently works in two modes:

0316

4. Runtime Environment (Docker) I chose Docker (osrf/ros:humble-desktop) as the execution environment. Why?

The Ask: Roast My Architecture The project is currently in early alpha. Honestly, my biggest doubts right now are around the core architecture and the automated build system (package and launch file generation).

I would be incredibly grateful if experienced ROS architects could take a look at the repo, point out my blind spots, and give me some harsh architectural critique. I’d much rather rebuild the foundation now than drag architectural flaws into a full release.

Source code here: GitHub - NeiroEvgen/ros2-blueprint-studio · GitHub

Any feedback is highly appreciated!

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/show-and-tell-ros-2-blueprint-studio-visual-node-editor-boilerplate-generator-alpha/53251

ROS Discourse General: mcp-ros2-logs — let AI agents debug your ROS2 logs across nodes

mcp-ros2-logs is an open-source MCP server that merges ROS2 log files from multiple nodes into a unified timeline and exposes query tools for AI agents like Claude, GitHub Copilot, and Cursor.

The problem: ROS2 writes each node’s logs to a separate file. Debugging a cascading failure across sensor_driver -> collision_checker -> motion_planner means manually correlating timestamps across 3+ files.

What this does: Install it with pipx install mcp-ros2-logs, register it with your AI assistant, and ask natural language questions like:

Features:

Example workflow: Point the agent at a run where a lidar USB connection dropped. It loads the logs, correlates the errors with bag topic data, and reconstructs the full causal chain: USB timeout → /scan messages stopped → collision_checker failed → motion_planner aborted. The whole analysis takes about 10 seconds.

GitHub: GitHub - spanchal001/mcp-ros2-logs: Give AI agents the ability to debug ROS2 logs across nodes — MCP server, no ROS2 install required · GitHub
PyPI: pipx install mcp-ros2-logs

Would love feedback from anyone doing multi-node debugging or working with bag files.

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/mcp-ros2-logs-let-ai-agents-debug-your-ros2-logs-across-nodes/53236

ROS Discourse General: Rewire — stream ROS 2 topics to Rerun with zero ROS 2 build dependencies

Title: Rewire — stream ROS 2 topics to Rerun with zero ROS 2 build dependencies

Hi all,

I’ve been working on Rewire, a standalone bridge that streams live ROS 2 topics to
Rerun for real-time visualization. I wanted to share it here and get feedback from the
community.

The problem it solves

Setting up visualization tooling in ROS 2 often means pulling in dependencies,
building packages, and dealing with middleware configuration. I wanted something that just works — point it at a DDS/Zenoh network and start visualizing.

How it works

Rewire is a single Rust binary that speaks DDS and Zenoh wire protocols directly. It’s not a ROS 2 node —
it doesn’t join the ROS graph or require any ROS 2 installation. It acts as a passive observer.

curl -fsSL https://rewire.run/install.sh | sh
rewire record -a    # subscribe to all topics

What’s supported

Platforms

Linux (x86_64, aarch64) and macOS (Intel + Apple Silicon).

Install options

I’d love to hear your thoughts — especially around which message types or workflows you’d want supported next. If you run into issues, feedback is very welcome.

Website: https://rewire.run

6 posts - 3 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/rewire-stream-ros-2-topics-to-rerun-with-zero-ros-2-build-dependencies/53233

ROS Discourse General: A proposal for a LidarScan sensor message

Hello ROS community

When working with Lidar data users are usually referred to using PointCloud2 objects that represent the lidar data as a list of 3d points with additional attributes. While this nicely mirrors the PCL representation and fits the majority of applications working with 3D point cloud data this isn’t how modern lidar sensors represent data.

Problem Statement

This has several drawbacks that are highlighted in the following list (not a comprehensive list):

The proposal

We are proposing the addition of a new ROS sensor message that mirror that native format of the majority of Lidar sensors (whether spinning or solid-state), in this proposal we would like to invite other lidar vendors to also contribute to make sure that this format encompasses the entire spectrum of Lidar sensors.

A quick draft of a LidarScan message could look like this:

std_msgs/Header header

# Dimensions of the scan (e.g., 128 channels x 2048 columns)
uint32 height
uint32 width

# --- Geometry Metadata ---
# Horizontal and Vertical FOV/Resolution info to allow projection to 3D 
# without needing a full PointCloud2 blob.
float32 vertical_fov_min
float32 vertical_fov_max
float32 horizontal_fov_min
float32 horizontal_fov_max

# --- Channel Data (The "Image" approach) ---
# Each channel (Range, Intensity, Reflectivity, etc.) is stored in this list.
# This mirrors the 'PointField' logic but at a 2d-grid level.
LidarChannel[] channels

# The actual raw buffer containing all interleaved or planar channel data.
# Using uint8[] allows for Zero-Copy compatibility.
uint8[] data

# --- Scaling and Metrics ---
# Different venders have different units
# Ouster (mm) vs. Velodyne (m) vs. Hesai (cm) problem.
# Range = (raw_value * multiplier) + offset
float64 range_multiplier
float64 range_offset

And the definition of LidarChannel:

string name        # "range", "intensity", "reflectivity", "ambient", "near_ir"
uint32 offset      # Offset from start of data row
uint8  datatype    # uint8, uint16, uint32, float32, etc.

While this works for sensors with uniform distributions of laser beams not all vendors have that formation including Ouster sensors making the section on Geometry Metadata insufficient:

float32 vertical_fov_min
float32 vertical_fov_max
float32 horizontal_fov_min
float32 horizontal_fov_max

Ouster spinning sensors vertical beams don’t have uniform distribution due to the calibration process. Which means we need to extend the previous definition to include the beam angels in the LidarScan message body:

# --- Non-Uniform Geometry Metadata ---
# These arrays allow the receiver to project Range -> 3D.
# vertical_angles[height]: The elevation angle for each ring (in radians).
float32[] vertical_angles

# other attributes might also be needed
# horizontal_angles[width]: [optional] The azimuth angle for each column (in radians).
# int32[] beam_time_offset: [optional] To handle "staggered" firing patterns within a single column.

This solves the problem and allows users to project the range data into 3D but adds a bit of overhead increasing the message size. These arrays basically essentially define the intrinsics of the Lidar sensor, however, transporting them with every LidarScan message reduces or eliminates most of the gains attained by transporting the raw range data vs using the projected xyz points. A better approach would be to break down the beam information and the lidar data into two separate messages in which the lidar sensor info is only transported once earlier during the connection phase. This is not a new pattern to ROS as it already has `sensor_msgs/CameraInfo` which describes the intrinsics of the camera link: sensor_msgs/CameraInfo Documentation .

By moving these intrinsic values fields into a separate message we can retain the same gains and keep the LidarScan message lean. The definition for a sensor_msgs::LidarInfo message would be something like:

std_msgs/Header header

float32[] vertical_angles
float32[] horizontal_angles
int32[] beam_time_offsets

# --- Scaling and Metrics ---
float64 range_multiplier
float64 range_offset

# Plus other static factory data (intrinsic/extrinsic)

And the revised LidarScan message becomes:

std_msgs/Header header
uint32 height
uint32 width
LidarChannel[] channels
uint8[] data

NOTES:

20 posts - 7 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/a-proposal-for-a-lidarscan-sensor-message/53225

ROS Discourse General: Call for Proposals: Global ROSCon 2026 in Toronto

ROSCon Global 2026 Call for Proposals Now Open!

The ROSCon call for proposals is now open! You can find full proposal details on the ROSCon 2026 website.

ROSCon Global 2026 will be held in Toronto, Canada, from September 22nd to September 24th, 2026. This year, we are officially adopting the “Global” moniker to reflect our growing international community and the many regional ROSCons happening worldwide.

Submission Deadlines

Important Dates

Diversity Scholarship Program

If you require financial assistance to attend ROSCon Global and meet the qualifications, please apply for our Diversity Scholarship Program. Thanks to our sponsors, scholarships include complimentary registration, four nights of hotel accommodation, and a travel stipend.

The deadline for the scholarship is Sun, Mar 22, 2026 12:00 AM UTC, which is well before the CFP deadlines to allow for travel planning and visa processing.

What are we looking for?

The core of ROSCon is community-contributed content. We are looking for:

We want to see your robots! Whether it is maritime robots, lunar landers, or industrial factory fleets, we want to hear the technical lessons you learned. We encourage original content, high-impact ideas, and, as always, a focus on open-source availability.

How to Prepare

If you are new to ROSCon we recommend reviewing the archive of previous talks. You are also welcome to use this Discourse thread to workshop your ideas and find collaborators.

Questions and concerns can be directed to the ROSCon Executive Committee (roscon-2026-ec@openrobotics.org) or posted in this thread. We look forward to seeing the community in Toronto!

5 posts - 4 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/call-for-proposals-global-roscon-2026-in-toronto/53171

ROS Discourse General: PlotJuggler Bridge Released

I’m happy to introduce PlotJuggler Bridge, a lightweight server that exposes ROS 2 or DDS topics over WebSocket, allowing remote tools like PlotJuggler to access telemetry without directly participating in the middleware network.

In many robotics setups, accessing telemetry from another computer is harder than it should be. DDS discovery over WiFi can be unreliable, opening DDS networks outside the robot can create configuration issues, and installing a full ROS 2 environment on every machine used for debugging is often inconvenient.

PlotJuggler Bridge solves this by acting as a gateway between the middleware network and external clients.
It runs close to the robot, reads the topic data, and exposes it through a simple WebSocket endpoint that any client can connect to.

This approach keeps the ROS/DDS network local while making telemetry easily accessible from other machines.

The project is available here:


Why it is useful

This is especially helpful in scenarios such as:

Because the bridge performs runtime schema discovery, clients can access topics even if they use custom ROS messages, without requiring those message packages to be installed on the client machine.

The bridge also aggregates and optionally compresses data, which helps reduce bandwidth usage and improves stability when streaming telemetry over wireless networks.


Main features

PlotJuggler Bridge includes several features designed for real-world robotics workflows:


How it works

ROS 2 / DDS -> PlotJuggler Bridge -> WebSocket -> PlotJuggler

The bridge subscribes to topics in the ROS/DDS network and exposes them through a WebSocket server.
External tools can connect and receive the streamed telemetry without joining the middleware network.


Quick to start

The bridge can typically be up and running in less than 5 minutes.

Setup instructions are available in the repository README:

You will need PlotJuggler 3.16 or newer, which includes the WebSocket client plugin:


Basic usage

Once the bridge is running, the workflow is straightforward:

  1. Start the bridge on the machine connected to the ROS/DDS network.
  2. Open PlotJuggler on any computer.
  3. Connect to the WebSocket Client using the bridge address.

The available topics will be discovered automatically and can be inspected immediately.


About the work

My name is Álvaro Valencia, and I am currently working on PlotJuggler as an intern while finishing the last months of my Robotics Software Engineering degree.

I collaborate closely with @facontidavide on this project. PlotJuggler clearly reflects years of work, effort and passion, and contributing to it is a great experience.

Together we are developing the components required to make this new Robot → PlotJuggler connection workflow simple and practical to use. The goal is to make remote telemetry access easier while keeping the system flexible for future extensions that will appear in upcoming PlotJuggler developments.


And stay tuned… more interesting things are coming soon for PlotJuggler.

18 posts - 6 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/plotjuggler-bridge-released/53143

ROS Discourse General: Control NERO’s 7-DoF Effortlessly with MoveIt 2 (Part I)

Let’s Explore Nero – Moveit2 Edition (Part I)

As a next-generation robot operating system, ROS2 provides powerful support for the intelligent and modular development of robotic arms. As the core motion planning framework in the ROS2 ecosystem, MoveIt2 not only inherits the mature functions of MoveIt but also achieves significant improvements in real-time performance, scalability, and industrial applicability.

Taking a 7-DoF robotic arm as an example, this document provides step-by-step instructions for configuring and generating a complete MoveIt2 package from a URDF model using the MoveIt Setup Assistant, enabling motion planning and visual control. This guide offers a clear, practical workflow for both beginners and developers looking to quickly integrate models into MoveIt2.

Abstract

Exporting MoveIt Package from URDF

Tags

ROS2, moveit2, Robotic Arm, nero

Repository

Environment

OS: Ubuntu 22.04
ROS Distro: Humble

Introduction to MoveIt2

MoveIt2 is the next-generation robotic arm motion planning and control framework developed based on the ROS2 architecture. It can be understood as a comprehensive upgrade of MoveIt in the ROS2 ecosystem. Inheriting the core capabilities of MoveIt, it has made significant improvements in real-time performance, modularity, and industrial application scenarios.

The main problems solved by MoveIt2 include:

Installing Moveit2

You can directly install using binary packages; use the following commands to install all components related to moveit:

sudo apt install ros-humble-moveit*

Downloading the URDF File

First, create a new workspace and download the URDF model:

mkdir -p ~/nero_ws/src
cd ~/nero_ws/src
git clone https://github.com/agilexrobotics/piper_ros.git -b humble_beta1
cd ..
colcon build 

After successful compilation, use the following command to view the model in rviz:

cd ~/nero_ws/src
source install/setup.bash
ros2 launch nero_description display_urdf.launch.py 

Exporting the MoveIt Package Using Setup Assistant

Launch the moveit_setup_assistant:

roslaunch moveit_setup_assistant setup_assistant.launch

Select Create New Moveit Configuration Package to create a new MoveIt package, then load the robotic arm.

Calculate the collision model; for a single arm, use the default parameters.

Skip selecting virtual joints and proceed to define planning groups. Here, we need to create two planning groups: the arm planning group and the gripper planning group. First, create the arm planning group; set Group Name to arm, use KDL for the kinematics solver, and select RRTstar for OMPL Planning.

Setting the Kin.Chain

Add the control joints for the planning group, select joint1~joint7, click >, then save.

Planning group creation completed.

Setting the Robot Pose; you can pre-set some actions for the planning group here.

Skip End Effectors and Passive Joints, and add interfaces in the URDF.

Setting the controller, here we use position_controllers.

Simulation will generate a URDF file for use in Gazebo, which includes physical properties such as joint motor attributes.

After configuration, fill in your name and email.

Set the package name, then click Generate Package to output the function package.

Launching the MoveIt Package

cd ~/nero_ws/src
source install/setup.bash
ros2 launch nero_moveit2_config demo.launch.py

After successful launch, you can drag the marker to preset the arm position, then click Plan & Execute to control the robotic arm movement.

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/control-nero-s-7-dof-effortlessly-with-moveit-2-part-i/53123

ROS Discourse General: ros2_info — A fastfetch-like system info tool for ROS2

Hey Open Robotics folks :waving_hand:

So I built a small tool called ros2_info.
The idea was simple: what if fastfetch, but for your entire ROS2 environment?

One command → instant snapshot of everything happening in your ROS2 setup.

What it shows:
• ROS2 distro + whether it’s LTS or nearing EOL
• Live nodes, topics, services, and actions
• Auto-detects which DDS middleware you’re running
• All detected colcon workspaces + their build status
• Installed ROS2 packages grouped by category
• System stats (CPU, RAM, Disk)
• Pending ROS2-related apt updates
• A small web dashboard at localhost:8099

Basically the stuff I kept checking with 10 different commands… now in one place :sweat_smile:

Works across ROS2 distros: Foxy → Humble → Iron → Jazzy → Rolling

GitHub:
https://github.com/zang7777/ros2_info

Install

cd ~/ros2_ws/src
git clone https://github.com/zang7777/ros2_info.git
cd ~/ros2_ws && colcon build --symlink-install
source install/setup.bash
(best recommended) ros2 run ros2_info ros2_info --interactive
or just
ros2 run ros2_info ros2_info 

Always fun building little dev tools for the ecosystem :robot:

~"Created by roboticists, for roboticists "

3 posts - 2 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/ros2-info-a-fastfetch-like-system-info-tool-for-ros2/53105

ROS Discourse General: ROS 2 Rust Meeting: March 2026

The next ROS 2 Rust Meeting will be Mon, Mar 9, 2026 2:00 PM UTC

The meeting room will be at https://meet.google.com/rxr-pvcv-hmu

In the unlikely event that the room needs to change, we will update this thread with the new info!

2 posts - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/ros-2-rust-meeting-march-2026/53066


2026-03-28 12:18