If you are a ROS developer/user and you blog about it, ROS wants those contributions on this page ! All you need for that to happen is:
have an RSS/Atom blog (no Tweeter/Facebook/Google+ posts)
open a pull request on planet.ros tracker indicating your name and your RSS feed/ATOM url. (You can just edit the file and click "Propose File Change" to open a pull request.)
make your ROS related posts tagged with any of the following categories: "ROS", "R.O.S.", "ros", "r.o.s."
Warnings
For security reasons, html iframe, embed, object, javascript will be stripped out. Only Youtube videos in object and embed will be kept.
Guidelines
Planet ROS is one of the public faces of ROS and is read by users and potential contributors. The content remains the opinion of the bloggers but Planet ROS reserves the right to remove offensive posts.
Blogs should be related to ROS but that does not mean they should be devoid of personal subjects and opinions : those are encouraged since Planet ROS is a chance to know more about ROS developers.
Posts can be positive and promote ROS, or constructive and describe issues but should not contain useless flaming opinions. We want to keep ROS welcoming :)
ROS covers a wide variety of people and cultures. Profanities, prejudice, lewd comments and content likely to offend are to be avoided. Do not make personal attacks or attacks against other projects on your blog.
Suggestions ?
If you find any bug or have any suggestion, please file a bug on the planet.ros tracker.
It’s been a while, but we’re excited to announce MoveIt Pro 9.0, the latest major release of PickNik’s manipulation developer platform built on ROS 2. MoveIt Pro includes comprehensive support for AI model training & execution, Behavior Trees, MuJoCo simulation, and all the classic capabilities you expect like motion planning, collision avoidance, inverse kinematics, and real-time control.
This release adds support for ROS 2 Jazzy LTS (while still supporting ROS Humble), along with significant improvements to teleoperation, motion planning, developer tooling, and robot application workflows. MoveIt Pro now includes new joint-space and Cartesian-space motion planners that outperform previous implementations, to improve cycle time, robustness, and industry-required reliability. See the full benchmarking comparison for details
MoveIt Pro is developed by the team behind MoveIt 2, and our goal is to make it easier for robotics teams to build and deploy real-world manipulation systems using ROS. Many organizations in manufacturing, aerospace, logistics, agriculture, industrial cleaning, and research use MoveIt Pro to accelerate development without needing to build large amounts of infrastructure from scratch.
What’s new
Improved real-time control and teleoperation with Joint Jog
MoveIt Pro now includes a new “Joint Jog” teleoperation mode for controlling robots directly from the web UI. This replaces the previous MoveIt Servo based teleoperation implementation and introduces continuous collision checking, configurable safety factors, and optional link padding for safer manual control during debugging or demonstrations.
Scan-and-plan workflows
New scan-and-plan capabilities allow robots to scan surfaces with a sensor and automatically generate tool paths for tasks like spraying, sanding, washing, or grinding. These workflows make it easier to build surface-processing applications.
New Python APIs for MoveIt Pro Core
New low-level Python APIs expose the core planners, solvers, and controllers directly, enabling developers to build custom applications outside of the Behavior Tree framework. These APIs provide fine-grained control over motion planning and kinematics, including advanced features like customizable nullspace optimization and path constraints.
Improved motion planning APIs
Several updates improve flexibility for motion generation, including: improved path inverse kinematics, orientation tracking as a nullspace cost, customizable nullspace behavior, tunable path deviation tolerances.
Developer productivity improvements
The MoveIt Pro UI and Behavior Tree tooling received a number of improvements to make debugging and application development faster, including a redesigned UI layout and improved editing workflows, Behavior Tree editor improvements such as search and node snapping, better debugging tools including TF visualization and alert history
Expanded Library of Reusable Manipulation Skills
MoveIt Pro also includes a large library of reusable robot capabilities implemented as thread-safe Behavior Tree nodes, allowing developers to compose complex manipulation applications from modular building blocks instead of writing large amounts of robotics infrastructure from scratch. See our Behaviors Hub to explore the 200+ available Behaviors.
Built for the ROS ecosystem
MoveIt Pro integrates with the broader ROS ecosystem, including standard ROS drivers and packages. PickNik has been deeply involved in the MoveIt project since its early development, and we continue investing heavily in open-source robotics such as developing many ROS drivers for major vendors.
Following up on the recent announcement regarding the Lyrical Luth release requirements, the PMC has finalized the automated enforcement protocols. To ensure our May release remains on schedule, we are providing expanded guidelines and examples for the new rhyme-lint and README.shanty checks.
Effective immediately, all pull requests targeting the rolling or lyrical branches must pass these poetic audits.
1. The rhyme-lint Mandatory CI Check
All pull requests will now trigger a rhyme-lint action. If your commit message lacks proper meter or rhyme, the build will fail with a 403: UNPOETIC_CONTRIBUTION error.
Accepted Commit Styles:
The Heroic Couplet (for Security/Bug Fixes):
fix: A buffer overflow was found in C,
We've locked the heap to keep the memory free.
Iambic Pentameter (for Feature Additions):
feat: The twenty-standard now we must embrace,
To bring C++20 speed to every space.
The Middleware Haiku (for RMW Updates):
Packets drift like leaves,
The middleware finds the path,
Silence in the logs.
2. The README.shanty Documentation Standard
Any new package added to the core must include a README.shanty file. This ensures our documentation can be easily memorized and sung during long deployment cycles or deep-sea robotics missions.
Note: Harmonies are optional but encouraged for Tier-1 platforms.
Example: README.shanty for rcl::Buffer
(To the tune of “The Wellerman”)
There once was a node that sent a frame,
Without a copy or a name,
The CPU was much to blame,
For latency so high! (HUH!)
Soon may the Zero-Copy come,
To bring us throughput, megabytes, and fun,
When the data transfer’s done,
We’ll take our leave and go!
We used the vendor’s memory backend,
A pointer sent to every friend,
The bandwidth limit met its end,
Beneath the Lyrical sky!
3. The Lyrical Luth Rhyming Dictionary
We recognize that many maintainers may find this transition challenging. To assist, the PMC has curated an initial dictionary of “Technical Rhymes” to help you pass CI.
ROS Term
Approved Rhymes
Example
Node
Code, Mode, Load, Road
“A lonely node / with heavy load.”
DDS
Success, Progress, Finesse
“Tune the DDS / with pure finesse.”
Topic
Myopic, Tropic, Microscopic
“A hidden topic / so microscopic.”
RMW
Now, How, Allow, Brow
“The RMW / we fix it now.”
Linter
Splinter, Winter, Printer
“The static linter / cold as winter.”
Pointer
Anointer, Appointer
“The null pointer / a soul-disappointer.”
Humble
Rumble, Stumble, Grumble
“Backported from Humble / without a stumble.”
Compliance and “ROS-ffice Hours”
We understand this is a significant shift in our development workflow, but we believe it is necessary to harmonize our ecosystem. To help with the transition, our upcoming “ROS-ffice Hours” sessions will be dedicated to bardic troubleshooting.
Let’s make this May the most harmonious release in robotics history.
Please come and join us for this coming meeting at Mon, Apr 13, 2026 4:00 PM UTC→Mon, Apr 13, 2026 5:00 PM UTC, where we plan to continue our Transitive Robotics tryout by trying one of the more advanced features: writing and deploying a custom capability. This feature allows customers to write their own custom code and deploy it to their robots alongside the features available directly from Transitive Robotics.
Last session, we tried running Transitive Robotics on a Turtlebot. We managed to remotely operate the robot, plus set up Maps as a capability which unfortunately didn’t work due to incompatibility with ROS 2 Jazzy (support has since been added for Jazzy). If you’re interested to watch the meeting, it is available on YouTube.
On Tue, Apr 7, 2026 6:59 AM UTC, we will freeze all RMW-related packages to prepare for the upcoming Lyrical Luth release on Fri, May 22, 2026 7:00 AM UTC.
Once this freeze takes effect, we will not accept new features to the RMW packages until Lyrical branches from ROS Rolling. This restriction applies to the following packages and vendor packages:
XSD schema for validating ROS2 XML launch files.
Catch syntax errors before runtime and get IDE support.
Why
For the package.xml we have had it for years, a scheme.
But we found my muscle memory often typing type= instead of exec=.
Or $(find my_pkg) instead of $(find-pkg-share my_pkg).
And we could unit-test the node all we wanted, these errors only popped up in integration tests or even on the robot itself.
Would it not be nice if your editor already warned about you it?
I’m working on an open standard called LSEP (Luminae Signal Expression Protocol) — a state machine specification for how robots communicate intent, awareness, and safety states to humans through light signals.
The problem it solves:
Most robotic platforms implement ad-hoc LED patterns with no shared semantics. Robot A blinks blue for “idle,” Robot B blinks blue for “navigating.” There’s no interoperability, and no way for a human in a shared workspace to learn one signal language that transfers across platforms.
LSEP defines a modular 9-state architecture: 6 Core states (IDLE, AWARENESS, INTENT, CARE, CRITICAL, THREAT) and 3 Extended states (MED_CONF, LOW_CONF, INTEGRITY) with deterministic mappings from sensor inputs like Time-to-Collision (TTC) to signal outputs. The full spec is open: https://lsep.org
Where ROS 2 comes in:
We’ve designed LSEP to run as an isolated safety node — it reads from your perception pipeline (TTC, proximity, sensor health) and publishes signal commands. It doesn’t touch your navigation stack. The architecture pattern uses lifecycle nodes to keep the signaling guardrail separate from autonomy logic.
What I’m looking for:
We’re running a free Beta program for 20 ROS 2 developers who want to stress-test the integration. No cost — your payment is brutal, unfiltered technical feedback and (optionally) a short write-up on how it fits into your stack.
The program covers:
- Translating TTC and proximity data to deterministic state machine outputs
- EU AI Act compliance layers (Art. 9 & 50) for high-risk physical AI transparency
- LSEP core & extended states: mechanics of the 9-state multimodal standard
- ROS 2 integration: isolating the LSEP safety node from your navigation stack
- Sensor fusion resilience: hysteresis and fallback patterns for sensor dropouts
Not looking for:
This isn’t a pitch. I’m not selling anything here. I’m looking for the people who actually build these systems to tell me where LSEP breaks, what’s missing, and what’s naive. The harshest feedback is the most useful.
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 Linux: Yocto‑based embedded Linux
PLCnext Runtime (tasks, data handling, Axioline integration): Provides deterministic processing and the Global Data Space
Global Data Space (GDS): Central storage for process variables accessible from PLC programs and system apps
PLCnext Apps: Packaged software components that can be installed on the controller
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:
Building the ROS Packages
Parse the IDF and generate the source code for the topic, publisher and subscribers
Build the ROS Node
Place the resulting binaries and gRPC dependencies into a Docker image with a minimal ros-core installation.
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.
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:
How do you balance between the number of chunks (count) and the buffer size for each chunk to avoid memory exhaustion without being overly wasteful?
Are there any common pitfalls when setting these values for a system with multiple subscribers?
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.
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:
Michele Rossi, Director, Industry, Qt Group
Przemysław Nogaj, Head of HMI Technology, Spyrosoft
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
Performance Monitor — real-time CPU, memory, and frequency graphs for any topic or node
Bag Recorder — multi-topic selection with custom save location
Bag Player — playback with adjustable rate (0.1x–10x) and loop controls
Bag to CSV Converter — full message deserialization via rosbag2_py to CSV
System Dashboard — CPU, memory, disk, network stats, ROS2 entities, and process monitor
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
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.
In main.py and main_virtual.py, select:from src.gamepad_trac_ik import RoboticArmController
5. Execution Steps
Connect manipulator and activate CAN interface:sudo ip link set can0 up type can bitrate 1000000
Connect gamepad:Connect the gamepad to the PC via USB or Bluetooth.
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.
Verify gamepad connection:Check console output to confirm the gamepad is recognized.
Web visualization:Open a browser and go to http://localhost:8080 to view the manipulator status.
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
Gripper opening range: 0–100%
Quick toggle: When fully open (100%) or fully closed (0%), a quick press and release of the trigger toggles the state.
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.
It uses an Unscented Kalman Filter (UKF) with a complete 3D state…. and it’s not just a port of robot_localization.
It features native GNSS fusion in ECEF coordinates, so you won’t run into UTM zone issues.
It supports dual antenna heading right out of the box….
It automatically estimates IMU gyroscope and accelerometer bias.
It includes HDOP/VDOP quality-aware noise scaling, which means bad GPS fixes are automatically down-weighted.
It’s under the Apache 2.0 license, making it commercially safe.
And it’s built natively for ROS 2 Jazzy….. not just a port.
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:
350+ companies in the field of robotics
50+ countries
60+ universities
80% filling roles as engineers or executive management
This year we will be offering our largest number of sponsorship opportunities yet, including the chance to:
Host a booth in our amazing ROSCon Global Expo hall. Booth locations are first come, first served, so do not delay.
Demonstrate your robot or device in our robot demo area.
Support our worldwide community with our free live stream and video archive, reaching thousands of viewers.
Include your stickers, one-sheet, or giveaway in our swag bag.
Support ROSCon attendees in their native language with our live captioning and translation service.
Be the life of the party by hosting our ROSCon Global reception and gala.
Feed and recharge our amazing ROSCon attendees by becoming a lunch or refreshment sponsor.
Elevate your startup’s visibility by joining our amazing ROSCon startup alley.
Connect with ROSCon attendees by supporting our award-winning and surprisingly good Whova app.
Show your support for underrepresented groups in robotics by sponsoring our inspiring ROSCon Diversity Scholars.
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!
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.
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:
Merge Pointclouds and laser scans
Input/output frame filtering.
Defined footprint, height, and angular box filters.
Voxel downsampling.
GPU acceleration support.
Deskewing Pointclouds (WIP)
I’d love your feedback, and if you find the project useful, please consider leaving a star on GitHub!
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.
Please come and join us for this coming meeting at Mon, Mar 23, 2026 4:00 PM UTC→Mon, 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.
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.
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:
<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
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).
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.
Project #1: PerceptionMetrics: GUI extension and support for standard datasets and models
Project #2: Robotics Academy: extend C++ support for more exercises
Project #3: Robotics Academy: New power tower inspection using deep learning
Project #4: RoboticsAcademy: drone-cat-mouse chase exercise, two controlled robots at the same time
Project #5: Robotics Academy: using the Open3DEngine as robotics simulator
Project #6: VisualCircuit: Improving Functionality & Expanding the Block Library
Project #7: Robotics Academy: Exploring optimization strategies for RoboticsBackend container
Project #8: Robotics Academy: palletizing with an industrial robot exercise
Motivated candidates are welcome 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.
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.
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.
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:
Hardcoded (Bottom-Up): If publisher and subscriber topic names are explicitly hardcoded in your C++ or Python files, the UI detects this and automatically draws a visual “locked” wire between them.
Visual (Top-Down): You can define the topic name only on the publisher, drag a visual wire to a subscriber, and the FileWatcher will find a special placeholder in the subscriber’s code and automatically replace it with the publisher’s topic name. (Full disclosure: the visual routing is still a bit unstable and not recommended for huge projects yet, but I’m refining it).
4. Runtime Environment (Docker) I chose Docker (osrf/ros:humble-desktop) as the execution environment. Why?
Setting up ROS 2 natively on Windows is a special kind of pain.
It provides painless deployment and saves you from dependency hell when migrating to future ROS versions.
You can send your project folder to someone who doesn’t even have ROS installed, and their system will build and run your entire architecture in just a few clicks.
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.
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:
“show me all errors with 5 messages of context around each”
“compare good_run vs bad_run — what changed?”
“detect anomalies in this run”
“correlate errors with bag topics — what was happening on /scan when the planner crashed?”
Features:
12 MCP tools: query logs, node summaries, timelines, run comparison, anomaly detection, bag file parsing, log-to-bag topic correlation, live tailing
Parses ROS2 bag files (.db3/.mcap) without ROS2 installed — extracts topic metadata for correlation with log errors
Works with Claude Code, VS Code Copilot, Cursor, and any MCP-compatible client
No ROS2 installation required — it just reads files from disk
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.
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
53 type mappings across sensor_msgs, geometry_msgs, nav_msgs, tf2_msgs, vision_msgs, std_msgs, and rcl_interfaces — including Image, PointCloud2, LaserScan, TF, Odometry, Detection2D/3DArray, and more.
Custom message mappings — map any ROS 2 message type to Rerun archetypes via a JSON5 config file, no recompilation.
URDF visualization — loads from /robot_description, resolves meshes via AMENT_PREFIX_PATH.
Full TF tree — static + dynamic transforms with coordinate frame visualization
Per-topic diagnostics — Hz, bandwidth, drops, and latency rendered as Rerun Scalars.
Linux (x86_64, aarch64) and macOS (Intel + Apple Silicon).
Install options
Install script:curl -fsSL https://rewire.run/install.sh | sh
prefix.dev:pixi global install -c rewire rewire
APT repository for Debian/Ubuntu
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.
ASL ETHZ,
Performance Monitor — real-time CPU, memory, and frequency graphs for any topic or node
Bag Recorder — multi-topic selection with custom save location
Bag Player — playback with adjustable rate (0.1x–10x) and loop controls
Bag to CSV Converter — full message deserialization via 
System Dashboard — CPU, memory, disk, network stats, ROS2 entities, and process monitor
