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."

For security reasons, html iframe, embed, object, javascript will be stripped out. Only Youtube videos in object and embed will be kept.

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.

If you find any bug or have any suggestion, please file a bug on the planet.ros tracker.

Hi all,

Please join us on Thursday 25 September, 2025 at 11 am EST (3 PM GMT) for:

ROS-powered robots *can* be safe: practical advice on how to do it for medical robots

OK, so the robot works… But how to make it safe? In this talk, we’ll look at how to layer “safety” into robots built on ROS, without derailing your roadmap. We’ll use medical robotics hazards as a worked example to explore practical methods for fault-tolerant control and sensor integration needed to turn your research prototype into something suitable for clinics/regulators, while balancing innovation speed with safety. Plus real lessons from someone who’s actually architected and implemented core safety components herself, in practice! Especially useful for others who are also looking to build medical robots “the startup way”. That is, pragmatic safety without cutting corners, while in a small team, and leveraging the open source robotics community the whole way.

this is the zoom link!

About the speaker:

Deanna Hood is leading robotics software development at Vexev, where the team is building one of the first medical robots openly based on ROS 2: an ultrasound imaging system that uses robotic automation to scan vasculature. As you saw from her ROSCon keynote, Deanna’s work as a core developer on ROS 2 has since evolved into hands-on experience turning various research prototypes into medical devices designed under FDA / IEC 63404 standards. She brings a pragmatic, startup-driven perspective to safety, focused on how to ship life-saving innovation quickly leveraging open source, while still meeting the demands of medical standards.

1 post - 1 participant

Read full topic

Hello, I’m Ilia, I’m building the first apps marketplace for consumer robots.

I’m looking for a cofounder. Please feel free to contact me.

The apps platform I’m building sits on top of ROS2. If you are interested, please visit my page Remake.ai

I will be launching first app-enabled (early beta!) ROS2-based robots later this year on my page here makerspet.com

I’m physically located in California. I hope that finding a cofounder will increase our chances applying to YC.

Thank you for reading this post.

1 post - 1 participant

Read full topic

Organization: Open Robotics
Mentor: Christophe Bedard
Student: Deva Shravan Kumar (Github, LinkedIn)
Link to GSoc Project: https://summerofcode.withgoogle.com/programs/2025/projects/quKpaaVA

Hello everyone,

I am Shravan, a 3rd year Electronics Engineering student at Indian Institute of Technology Roorkee and a member of the ROS development vertical at MaRS, our student robotics society. This summer, I was selected as a Google Summer of Code 2025 student developer to work on ros2_tracing with Open Robotics.

Over the past 4 months, I worked on implementing new features, adding tests, and updating documentation under the guidance of my mentor Christophe.

Project Overview

ros2_tracing provides developers with tracing tools built on LTTng tracer to help them understand what is happening inside their applications and ROS 2 itself. This visibility helps uncover bugs and performance bottlenecks in complex, resource-constrained robotics systems.

However, ros2_tracing had a significant limitation: meaningful trace data could only be captured if recording the trace was started before application launch. Due to how ROS 2 tracepoints are designed, starting to record after launch meant missing critical initialization phase data, resulting in runtime trace data being essentially useless (see issue #44). This constraint created workflow challenges for developers. When uncertain whether they would need trace data later, they were forced to start recording before application launch, often resulting in accumulating unused trace files on disk. Moreover, if developers noticed an issue on an already (possibly long) running system, it was too late to get useful trace data, either from that point forward or starting from some time before the problem started.

The main goal of this project was to solve this problem. With some pre-configuration, developers can now decide at runtime whether or not to record trace data, significantly improving their debugging workflow and eliminating unnecessary disk usage.

Repository link: https://github.com/ros2/ros2_tracing
LTTng documentation: https://lttng.org/docs/v2.13/

Implementation and Challenges

We identified a few potential solutions to enable runtime tracing:

Solution 1: ROS 2 State Dump
We explored implementing a ROS 2 state dump mechanism similar to LTTng’s state dump feature, which would collect initialization information about currently-active objects at the time tracing starts, rather than at application startup.

However, this approach faced a significant obstacle: there was no mechanism to trigger state dumps when recording starts (unlike LTTng’s internal capability).

Due to this fundamental limitation, we rejected this approach.

Solution 2: Add new tracepoints
Instrument the ROS 2 source code with new tracepoints that collect initialization information from within runtime code, alongside existing runtime tracepoints. This would ensure initialization data is captured even when tracing starts after application launch.

However, this approach presented significant challenges:

1. Due to ROS 2’s layered architecture (rclcpp, rcl, rmw), some initialization data exists in one layer while runtime code executes in another, making it difficult to capture all necessary initialization information
2. Even if we managed to get all the required initialization data, these new tracepoints would trigger repeatedly throughout the runtime phase, significantly increasing overhead

Due to these challenges, we decided to implement the third solution.

Solution 3: Dual Session Tracing:

This approach uses two separate tracing sessions: An initialization session configured in LTTng’s snapshot mode, which stores initialization data in memory and writes to disk on-demand, and a normal runtime session for ongoing events.

Users configure their launch files to automatically start the snapshot session. When they decide to record at runtime, the snapshot session dumps its contents to disk while the runtime session begins recording new events. This guarantees the final trace contains both initialization and runtime data. One major challenge in implementing this solution was to determine how users would interact with this feature throughout their entire workflow and to ensure it supported all their use cases.

During the process, we also added the ability to configure any tracing session in snapshot mode, enabling a “flight recorder” capability that maintains a rolling history of events and can dump data when something interesting occurs.

Links to pull requests made during the project:

1. Add support for starting tracing at runtime (PR #191, PR #196)
2. Allow creating snapshot sessions (PR #195, PR #206)
3. Add dual session tests (PR #205)
4. Add documentation for snapshot mode and dual session tracing (PR #207)

(other miscellaneous contributions)

5. Fix Clang warnings by using proper function prototypes in macros (PR #179)
6. Make trace action parameters substitutable (PR #187, PR #188)

Future Work

The implemented features can be further improved by addressing the following issues:

1. Allow creating multiple channels in a tracing session (issue #199)

   • Ability to create multiple channels allows to separate initialization and runtime events into two different channels, reducing the risk of high frequency runtime events overwriting the initialization events

2. Allow pre-configuring a dual session using ros2 trace command (issue #198)

Conclusion

This project was successful in addressing the “runtime tracing” limitation of ros2_tracing, therefore improving the developer experience and laying the basis for future developments.

This summer was truly a remarkable learning experience for me. Being part of the Open Robotics community and contributing to ROS 2 has been incredibly rewarding. I am looking forward to continuing my contributions to the open source robotics ecosystem.

I would like to express my sincere gratitude to my mentor @christophebedard for his invaluable guidance and support throughout the project and to Open Robotics for giving me this opportunity.

5 posts - 4 participants

Read full topic

This handy utility monitors key data from your ROS2 system. It brings together what exist individually in tools like ros2 topics, ros2 nodes, tf_utilities and more in one display. It’s fully terminal based so in your terminal emulator and even via ssh. It’s highly configurable via a json config file.

I hope you try it and post questions or issues in GitHub or here. I am interested in your installation experience, whether the numbers displayed are accurate, and also whether it itself is not a resource hog. Any other feedback of course is welcome as well.

Take a look here: GitHub - pitosalas/ros2sysmon

p.s. I know there must be something like this out there (in fact more than one) but I got tired of looking and it seemed like a fun little project. I hope someone tries it. And post issues if you want and I will look at them. It is open source (MIT).

6 posts - 2 participants

Read full topic

Hi everyone!
We’re excited to announce the open-source release of the ROS MCP Server.
With this server, you can control existing ROS 1 & 2 robots using natural language with LLMs like Claude, GPT, and Gemini—no changes to the robot’s code required!
Key Features:

• Connect any LLM to ROS robots via the Model Context Protocol (MCP)

• Supports Linux, Windows, and macOS

• Natural language → ROS topics, services, and actions (including custom messages!)

• Works without modifying robot source code

GitHub: https://github.com/robotmcp/ros-mcp-server
Demo Videos:

• Debugging an industrial robot: https://youtu.be/SrHzC5InJDA

• Controlling Unitree Go2 with natural language: https://youtu.be/RW9_FgfxWzs

We’d love to hear your feedback or suggestions if you get a chance to try it out!

3 posts - 3 participants

Read full topic

Hello

Here is the improved Fusion 360 to URDF for ROS 2 project with new enhancements to make it even easier and more robust for your robotics workflows.

What’s new in this release:

�������� ������������� – Clearer setup instructions and usage guidelines for developers at all levels.

��� � Jazzy ������� – Generated ROS 2 URDF package supports ROS Jazzy distribution with new Gazebo Sim.

��� ����� – Stability improvements and resolved issues from previous versions.

������ ��������� ������ – Choose between Gazebo Classic and Gazebo Sim with a simple option, streamlining your simulation setup.

�������� ��� ����� ����� �������

Check out the repo and get started with better Fusion 360 to ROS 2 integration today!

GitHub - runtimerobotics/fusion360-urdf-ros2: A Fusion 360 Script to export URDF for ROS 2, mentioned in the book Mastering ROS 2 for Robotics Programming

Feel free to report issues, suggest enhancements, and contribute new features or bug fixes via pull requests (PRs).

Regards
Lentin Joseph

1 post - 1 participant

Read full topic

Hi everyone,
we’d like to share a small project using the AgileX PiPER robotic arm combined with a depth camera to achieve simple teleoperation.
The core idea is to use hand gesture recognition to control the end effector position of PiPER (only Cartesian position, not orientation).
This is a lightweight, low-cost demo that may help inspire gesture-based human-robot interaction projects.

Abstract

This repository implements a low-cost, simple teleoperation function using a depth camera (position control only).

Tags: Gesture Recognition, Coordinate Mapping, AgileX PiPER

Code Repository: AgileX-College GitHub

Function Demonstration:

Control a Robot Arm… With Just Your Hand?!

Pre-use Preparation

Hardware

• Orbbec Petrel (aligned depth + RGB, 640×400@30fps)
• (Optional) Intel RealSense D435 (aligned depth + RGB, 640×480@30fps)
• AgileX Robotics PiPER robotic arm

Software Environment

1. Install required ROS packages:

sudo apt install -y ros-noetic-sensor-msgs ros-noetic-image-transport ros-noetic-cv-bridge ros-noetic-vision-msgs ros-noetic-image-geometry ros-noetic-pcl-conversions ros-noetic-pcl-ros ros-noetic-message-filters

2. Install gesture recognition library:

pip3 install mediapipe

3. Clone & build:

cd your_ws/src
git clone https://github.com/agilexrobotics/AgileX-College.git
cd ..
catkin_make
source devel/setup.bash

Operation Steps

1. Start the Robotic Arm

Follow the PiPER driver deployment:

• piper_sdk README
• piper_ros README

Insert CAN module → find bus → activate:

./find_all_can_port.sh
./can_activate.sh

Launch driver:

roslaunch piper start_single_piper.launch

Start IK library (pinocchio):

python piper_pinocchio.py

Start camera (example: D435):

roslaunch realsense2_camera rs_aligned_depth.launch 

Start gesture detection:

rosrun handpose_det handpose_det.py

2. Start Teleoperation

Define custom Home position (different from driver’s built-in Home):

self.endPosX = -0.344
self.endPosY = 0.0
self.endPosZ = 0.110

Publish to /pos_cmd:

rostopic pub /pos_cmd piper_msgs/PosCmd "{
x: -0.344, y: 0.0, z: 0.110,
roll: 0.0, pitch: 0.0, yaw: 0.0,
gripper: 0.0, mode1: 1, mode2: 0
}"

Run detection:

rosrun handpose_det handpose_det.py

RViz shows:

• Red dots = finger points
• Green dots = palm center

3. Define Teleoperation Base Frame

• Gesture OPEN_HAND → change to FIST → hold for 3s
• Publishes /base_frame_origin pose
• Maps hand’s relative motion to PiPER motion

Full Code

#!/usr/bin/env python3
# _*_ coding:utf-8 _*_

import rospy
import cv2
import mediapipe as mp
import numpy as np
from sensor_msgs.msg import Image
from cv_bridge import CvBridge
from visualization_msgs.msg import MarkerArray, Marker
from geometry_msgs.msg import PoseStamped
from piper_msgs.msg import PosCmd

class HandPoseTeleop:
    def __init__(self):
        rospy.init_node('handpose_teleop', anonymous=True)
        self.bridge = CvBridge()
        self.image_sub = rospy.Subscriber("/camera/color/image_raw", Image, self.image_callback)
        self.marker_pub = rospy.Publisher("/hand_markers", MarkerArray, queue_size=1)
        self.base_pub = rospy.Publisher("/base_frame_origin", PoseStamped, queue_size=1)
        self.cmd_pub = rospy.Publisher("/pos_cmd", PosCmd, queue_size=1)

        # Custom home point
        self.endPosX = -0.344
        self.endPosY = 0.0
        self.endPosZ = 0.110

        # Mediapipe
        self.mp_hands = mp.solutions.hands
        self.hands = self.mp_hands.Hands(min_detection_confidence=0.7,
                                         min_tracking_confidence=0.5)
        self.mp_draw = mp.solutions.drawing_utils

        rospy.loginfo("HandPoseTeleop initialized.")

    def image_callback(self, msg):
        cv_image = self.bridge.imgmsg_to_cv2(msg, "bgr8")
        img_rgb = cv2.cvtColor(cv_image, cv2.COLOR_BGR2RGB)
        results = self.hands.process(img_rgb)

        marker_array = MarkerArray()
        if results.multi_hand_landmarks:
            for hand_landmarks in results.multi_hand_landmarks:
                # Publish markers
                for i, lm in enumerate(hand_landmarks.landmark):
                    marker = Marker()
                    marker.header.frame_id = "camera_link"
                    marker.type = Marker.SPHERE
                    marker.action = Marker.ADD
                    marker.scale.x = marker.scale.y = marker.scale.z = 0.01
                    marker.color.a = 1.0
                    marker.color.r = 1.0
                    marker.pose.position.x = lm.x
                    marker.pose.position.y = lm.y
                    marker.pose.position.z = lm.z
                    marker_array.markers.append(marker)

                # Compute palm center (average of landmarks)
                palm_center = np.mean([[lm.x, lm.y, lm.z] for lm in hand_landmarks.landmark], axis=0)
                marker = Marker()
                marker.header.frame_id = "camera_link"
                marker.type = Marker.SPHERE
                marker.action = Marker.ADD
                marker.scale.x = marker.scale.y = marker.scale.z = 0.02
                marker.color.a = 1.0
                marker.color.g = 1.0
                marker.pose.position.x = palm_center[0]
                marker.pose.position.y = palm_center[1]
                marker.pose.position.z = palm_center[2]
                marker_array.markers.append(marker)

                # Send position command
                pos_cmd = PosCmd()
                pos_cmd.x = self.endPosX + palm_center[0]
                pos_cmd.y = self.endPosY + palm_center[1]
                pos_cmd.z = self.endPosZ + palm_center[2]
                pos_cmd.roll = 0.0
                pos_cmd.pitch = 0.0
                pos_cmd.yaw = 0.0
                pos_cmd.gripper = 0.0
                pos_cmd.mode1 = 1
                pos_cmd.mode2 = 0
                self.cmd_pub.publish(pos_cmd)

        self.marker_pub.publish(marker_array)

if __name__ == '__main__':
    try:
        teleop = HandPoseTeleop()
        rospy.spin()
    except rospy.ROSInterruptException:
        pass

Summary

This demo shows how the AgileX PiPER robotic arm can be controlled via hand gesture recognition and a depth camera, achieving real-time position teleoperation.

We’d love to hear your feedback!

• How would you extend this (e.g. orientation, multi-modal input)?
• Anyone interested in integrating this with VR/AR or haptics?

Full repo & details: AgileX-College on GitHub

AgileX Robotics
https://global.agilex.ai/

2 posts - 2 participants

Read full topic

We’ve currently been running into some issues that look like reaching the maximum number of DDS entities (i.e. nodes are started without error, but do not appear in ros2 node list, neither do their topics appear). If we shut down a few other nodes, than the same node runs well.

Overflowing into other domains should not be an issue according to The ROS_DOMAIN_ID — ROS 2 Documentation: Galactic documentation (we don’t use any other domains than 0). We don’t yet have 120 nodes, but I guess we’ll get there.

However, with the changes from Switch to one participant per context by ivanpauno · Pull Request #189 · ros2/rmw · GitHub , I got a bit confused about the number of participants created and needed by ROS 2.

Now it should be the case that there is 1 DDS participant per Context. However, the explanation of what Context currently is is a bit vague.

Is it the case that the simple single-node process creates exactly 1 participant?

How is it with component container? Does it have 1 participant for the whole container, or does it have one per loaded component?

How is it with the weird transform_listener_impl_* nodes automatically created by TransformListener? Do they “eat” a participant?

And last - I guess the 120 participant limit is per PC, right? This isn’t directly mentioned in the design doc, but I think it follows from the design…

To resolve our current problem, I’ll try switching to discovery server, but I’d like to have a clear view on the other mentioned questions.

Thanks for ideas!

3 posts - 3 participants

Read full topic

ROSCon 2025 Birds of Feather Sessions Now Open!

Hi Everyone,

Want to host a Birds of a Feather (BoF) session at ROSCon? We just posted the sign up form for BoF sessions at ROSCon. This year ROSCon will have eight dedicated BoF slots available on the workshop day, October 27th. Submissions will be reviewed as they come in, and the form will close once all eight slots are filled, so don’t delay proposing a session.

Sign up here for an official BoF slot!

You are also more than welcome to propose a BoF at another time / location as long as it doesn’t interfere with the main ROSCon program. We suggest using the Whova app onsite to organize your BoF session. A winning strategy is to organize a BoF dinner / meetup after the main program.

Full details are up on the ROSCon 2025 website.

2 posts - 1 participant

Read full topic

Model-driven development (MDD) has long proven its value in software engineering, but they have struggled to gain traction in robotics. Why? Because we already have ROS and ROS 2. Their development methodology - centered on writing code by hand - doesn’t align well with traditional MDD. For years, ROS became the de facto standard thanks to its advantages and strong community, so there was little motivation to “reinvent the wheel” with new approaches.

But robotics has changed. Nowadays, robotic systems are increasingly complex and modular, which is why MDD can provide significant benefits.

As someone who strongly believes in the ROS ecosystem, I’ve been exploring ways to bridge the gap between ROS and MDD. My approach allows developers to keep building components in the usual way while using introspection and static code analysis to automatically transform those components into models. These models can then be composed at the system level, validated, and used to generate ROS deployment artifacts. In other words, let the programmer focus on the complex logic, while automating the generation of package.xml, CMakeLists, launch files, documentation, and similar artifacts.

I’ve also conducted an evaluation study to show when this approach is most useful and what concrete benefits it brings.

This study was recently published, and it is available online at https://journals.sagepub.com/doi/pdf/10.1177/17298806251363648

From all the data collected, you can see these two graphs showing the reduction in development time as the complexity of the system increases, and how the number of lines of code written is reduced, and more importantly, the files (and languages) to be implemented.

The most relevant positive outcomes os this study are:

• MDD reduces testing time and error correction effort.
• Once learned and supported by a model base, development time is significantly reduced.
• Code generation reduces manual coding and lowers the risk of errors.
• Developers only need to learn one modeling language instead of multiple programming languages.
• MDD improves portability, which is especially beneficial for modular robots and serial production.

The following repository collects all the files and data: GitHub - ipa-nhg/MDD_Evaluation_Study.github.io: This repository collects data from the study carried out to evaluation the use of MDD techniques over ROS

I hope this information is useful. If you would like to collaborate on this line of research or get more information about what I have done, please do not hesitate to contact me.

https://www.linkedin.com/in/nadiahg/

1 post - 1 participant

Read full topic

Is there a way to identify which network card the ros2 program data goes through (network port or WIFI)?

7 posts - 3 participants

Read full topic

The group will not be holding its regular meeting this coming Monday 8th September 2025. Meetings will resume as normal from the 22nd September.

Last meeting, the CRWG discussed the similarities and differences between the tech of the companies that had come to talk about Logging & Observability. The group agreed that we need to talk to consumers of these technologies, so effort will be made to contact some of the companies with large fleets to request they talk to us. If you’d like to see the meeting, the recording is available on YouTube.

1 post - 1 participant

Read full topic

The next ROS 2 Rust Meeting will be Mon, Sep 8, 2025 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 - 2 participants

Read full topic

Hi everyone,

We’d like to share a simple program we developed for color block recognition and 3D curve extraction using the AgileX PIPER robotic arm. The project leverages OpenCV with depth and color data from a depth camera, enabling 3D coordinate extraction of color targets that can be applied to basic robotic grasping and trajectory tracking tasks.

We hope this example can serve as a starting point for anyone exploring computer vision–based manipulation with lightweight robotic arms. Feedback, improvements, and pull requests are always welcome!

Abstract

A simple program for color block recognition and 3D coordinate extraction, utilizing the OpenCV library. It performs recognition using depth information and color data from a depth camera, and the extracted 3D coordinates of color blocks can be applied to simple robotic arm grasping tasks.

Keywords: Color Recognition, 3D Curve Extraction, Curve Fitting, Curve Interpolation, AgileX PIPER

Code Repository

GitHub link: AgileX-College/piper/cubeAndLineDet

Function Demonstration

Teaching a Robot Arm to Spot Colors & Draw Curves

Preparation Before Use

Hardware Preparation

• Orbbec Petrel (with aligned depth images and RGB images: 640×400@30fps)
• (Optional) Intel RealSense D435 (with aligned depth images and RGB images: 640×480@30fps)
• AgileX PIPER Robotic Arm

Software Environment Configuration

1. Compile and install the PCL point cloud library. For Linux compilation examples, refer to the official documentation. The on_nurbs option needs to be specified during compilation.
2. For PIPER manipulator driver deployment, refer to: piper_sdk
3. For PIPER manipulator ROS control node deployment, refer to: piper_ros

Functional Operation Steps

1. Start the Color Block Detection Node

1. Start the depth camera ROS driver node (example: Orbbec Petrel):

roslaunch astra_camera dabai_dc1.launch

2. Start the color block detection node. Two image windows will pop up: hsv_image and origin_image. Adjust HSV parameters in hsv_image to find specific colors, or click in origin_image to extract the target color automatically:

rosrun cube_det cube_det

3. Example of automatic color search:
   

   

4. The 3D coordinate information of the detected point will be visualized in rviz:
   

   

2. Start the Curve Detection

1. Start the depth camera driver:

roslaunch astra_camera dabai_dc1.launch

2. Start the curve detection node. It uses a built-in curve fitter and interpolator to make the output curve continuous and smooth:

rosrun cube_det line_det

3. Click the target curve in origin_image to extract and search automatically.

4. Open rviz to view the converted point cloud curve:
   

   

5. Start the manipulator’s ROS control node:

# Find the robotic arm CAN port
./find_all_can_port.sh
# Connect to the CAN port
./can_activate.sh

6. Start the manipulator motion node:

roslaunch piper start_single_piper.launch

7. Start inverse kinematics. Reference: piper_ros Pinocchio README

python piper_pinocchio.py

8. Set a manipulator home position:

rostopic pub /pos_cmd piper_msgs/PosCmd "{
x: -0.344,
y: 0.0,
z: 0.110,
roll: 0.0,
pitch: 0.0,
yaw: 0.0,
gripper: 0.0,
mode1: 1,
mode2: 0
}"

9. Visualize the generated end-effector control path /line_path in rviz:
   

   
   
   
   

10. Start the manipulator motion path loading and end-effector control program:

rosrun cube_det path_confer.py

path_confer.py supports three operations:

• r: Record the current frame point cloud, transform to arm_base coordinates, and generate a path.
• s: Send the recorded path point by point.
• p: Publish the entire path cyclically.

11. After recording (r), the transformed path /transformed_cloud will be shown in rviz:
    

    

12. Press s or p to control the manipulator to follow the generated trajectory.

Conclusion

This project demonstrates how the AgileX PIPER robotic arm can be combined with depth cameras and OpenCV to achieve:

• Color-based object detection
• 3D coordinate extraction
• Curve fitting and interpolation
• Trajectory execution with inverse kinematics

All source code and setup instructions are available in the GitHub repository.

If you try this out or extend the functions, we’d love to hear your feedback and results. Please feel free to share your experiences or raise issues in the repo.

Thanks for reading, and happy coding!

1 post - 1 participant

Read full topic

Hi everyone! I’d like to let you know that I dove into ROS earlier this year and have been working on a “Getting Started” video series for DigiKey’s YouTube channel. There will be 12 videos, and they should be released weekly on DigiKey’s channel. I start off with basic communication between nodes (as you do) before diving into parameters, launch files, and some TF2. I mention talking to microcontrollers at the end, but I don’t get into micro-ROS (as I feel that should probably be its own series). I welcome feedback and suggestions for future videos!

The first video is here:

Introduction to ROS Part 1: What is the Robot Operating System? | DigiKey

2 posts - 2 participants

Read full topic

I’m setting up a lab environment for my students and have replaced the Raspberry Pi 4 on the TurtleBot3 with a Raspberry Pi 5, so all logic now runs directly on the robot.

The challenge: most of my students use Windows PCs. I’d like to use WSL2 and a Docker container to connect to the TurtleBot3 via USB or over a Wi-Fi access point. However, I haven’t been able to get communication working between the TurtleBot3 and WSL2.

Is this even possible? Has anyone managed to get this setup running? I’d appreciate any guidance or tips.

2 posts - 2 participants

Read full topic

Hi!

We are releasing yet another MCP server for rosbags, and an MCP Lab UI so that you can see which LLMs (closed or open) are able to properly use the available tools.

Quick demos

With Claude Desktop

With MCP Lab running locally

rosbags-mcp

The rosbags-mcp server allows LLMs to pull data from your rosbags and plot it in interactive plots with plotly. It is a pure Python package with no ROS dependencies (based on the rosbags library).

Some of the features include:

• listing bags in a directory, and getting their info

• searching messages (based on conditions)

• filtering bags

We also believe that there is value in creating domain-specific tools that are useful across ROS robots. We started with basic functionality:

• trajectory analysis (e.g., with spatial subsampling)

• laserscan data analysis

• logs from /rosout

• tf tree

We also decided to add a few tools to visualize data (even though we’d love to have foxglove integration, for example!)

• time series data plots

• 2D plots

• laserscan polar plots

Finally, you can also return an image with an LLM (if you are using a multi-modal model).

All this is not entirely new. For example, Bagel is an amazing tool that has been posted already here (release), here (update), and here (DuckDB update). However, we started working on this before we became aware of Bagel and thought it might have a place out there! We are working on other ROS-related MCP servers and hope to release more soon. We see a lot of potential, for example, in the DuckDB integration from Bagel.

MCP Lab Web UI

Together with the rosbags MCP server, we are releasing MCP-Lab, a Web UI where you can choose OpenAI, Anthropic, or open-source models provided by Groq (for now), to test their ability to call tools in any MCP server.

You can also run MCP Lab on your robot and access it remotely.

Benchmarking

We will release a short technical paper. In the meantime, here’s a preview of selected queries and whether different LLMs are able to use the MCP server properly or not:

Any feedback is welcome!
The MCP server and MCP Lab are both projects under active development so not everything will be working perfectly.

Contributors: @sahars93, @sisqui, @jopequ

1 post - 1 participant

Read full topic

TL; DR I am of the opinion that some of the performance bottlenecks we still see in ROS 2 can be traced back to rosidl design. There are benefits to language-specific runtime representations and vendor-specific serialization formats, but efficiency is not one of them. Other designs may be better suited to the kind of data streams that are common in robotics. In that sense, GitHub - Ekumen-OS/flatros2 may be an interesting conversation starter.

Howdy! I don’t post often on ROS Discourse but I thought this may be worthwhile. The Physical AI rebranding of robotics is drawing attention and resources, and in that whirlwind I keep seeing new libraries and frameworks showcasing performance figures that seemingly obliterate those
of ROS 2 (like dora-rs/dora-benchmark, but there are others). Why? The total amount of engineering resources invested by this community in ROS 2 far exceeds that of any other new project and yet I still find myself second guessing ros2 topic hz output. Well, I’ve been around and about for a good while now, and I have a hypothesis.

rosidl is one the oldest corners of ROS 2. C and C++ message generators were first released with Alpha 1, each with their own runtime representations: simple enough, language-specific. The first few DDS based middlewares (like opensplice) had their own vendor-specific IDL to comply with, for interoperability and full feature support, and so type support code and internal runtime representations had to be generated. A decade later ROS 2 is still bound by this design.

Zero-copy transports cannot cross the language boundary because there’s no common runtime representation, and because in-memory layouts are nonlocal, even for the same language their scope of application is extremely narrow (so narrow not even standard messages qualify). Middlewares (de)serialize messages to vendor-specific formats that keep them traceable on their domain and afford us features like keyed topics, whether that makes sense for a given form of data or not. Repeated (de)serialization of images and pointclouds (and other forms of multi-dimensional data) certainly does not help speed.

I honestly didn’t know if there was a way out of this. Some of these shortcomings cannot be fixed out of tree. So I started Ekumen-OS/flatros2 with some Ekumen colleagues as an experiment. It turns out there are lots of pitfalls and limitations but there is a way. Ekumen-OS/flatros2 is NOT it, however. A true solution (I believe) must be a core solution, and Ekumen-OS/flatros2 is just an exercise on how that future solution may look like i.e. messages as language-specific views to contiguous memory layouts, bounded on write, unbounded on read. The choice of flatbuffers and iceoryx2 was informed but arbitrary. Both have interesting properties nonetheless.

Hope this helps kickstart a discussion. There’s no fundamental reason why ROS 2 cannot perform near I/O limits. And who knows, maybe there’s enough momentum to sort out message compabitility too while we are at it (and I’d very much appreciate backwards and forward compatible bags).

12 posts - 6 participants

Read full topic

Hello ROS 2 community,

We are excited to announce the upcoming release of Fast DDS Pro, the new commercial edition of Fast DDS.

Fast DDS Pro extends the capabilities of the community edition with advanced networking features designed for industrial and defense-grade deployments. These features can be used directly from ROS 2, or through Vulcanexus, our all-in-one ROS 2 toolset.

Key features at launch:

• Low Bandwidth Plugins – Optimized DDS communication for constrained or unstable links (e.g., radio, satellite, IoT).

• TSN Support – Deterministic communication with guaranteed latencies.

• IP Mobility – Seamless connectivity across changing networks (vehicles, mobile robots).

• Congestion Control (coming soon) – Adaptive traffic management under heavy network load.

Release planned for September 2025.

Learn more and sign up for updates here.

We believe this new edition will provide the ROS 2 community with tools to tackle more demanding networking challenges in production systems, while continuing to support the community with the open-source Fast DDS.

We’d love to hear your feedback and discuss use cases where these features could bring value to your projects.

3 posts - 2 participants

Read full topic

Hello ROS Developers,

We’re excited to announce that we’ll be hosting another Virtual ROS Meetup in Nigeria!

Whether you’re just starting and want to learn how to set up a ROS 2 development environment without changing your PC’s OS, or you’re an enthusiast or expert eager to dive deeper into advanced topics like Kalman filters for robot localization, this session is for you.

We’ll be joined by two amazing speakers, who are contributors to the great Nav2 project with extensive experience in using and applying ROS2:

Sakshay Mahna will demonstrate how to quickly set up a ROS 2 development environment using the ros2env VS Code Extension, which he developed .

Stevedan Ogochukwu Omodolor will guide us through the application of Kalman filters to fuse multiple sensors for improved robot localization .

Kindly Register here: Robot Operating System (ROS) Meetup, Lagos

We look forward to seeing you there!

Venue: Virtual only

Date: Sat, Sep 13, 2025 11:00 AM UTC→Sat, Sep 13, 2025 1:00 PM UTC

Contact Email Address: rosnaija.ng@gmail.com

1 post - 1 participant

Read full topic

I launched a new iOS app, “Robot Steering,” using the web_video_server & rosbridge_suite libraries.
Please download this free app to control your robot with video streaming features.

More description on Github

2 posts - 2 participants

Read full topic

Added “Create custom world” tool based on Dynamic World Generator repo. It let you create Gazebo world with static and dynamic obstacles directly in RobotCAD.

RobotCAD - Dynamic world creating — Video | VK - video demo

1 post - 1 participant

Read full topic

ManyMove, an open-source framework built on ROS 2, MoveIt 2, and BehaviorTree.CPP, is now enabled to interact with NVIDIA Isaac Sim 5.0.

With this integration, you can:
Execute behavior-tree–based motion control directly to physics simulation.
Prototype and validate manipulation tasks like pick-and-place in a high-fidelity digital twin.
Streamline the path from simulation to real-world deployment.

ManyMove is designed for industrial applications and offers a wide range of examples with single or double robot configuration.
Its command structure is similar to industrial robot languages, easing the transition from classic robotics frameworks to ROS 2.
Behavior Trees power the logic cycles for flexibility and clarity.

Demos:

• Pick-and-place BTs demo
• Dynamic pose interaction

Combining ManyMove, Isaac Sim’s physics and rendering and Isaac ROS reference workflows aims to allow easier deployment of GPU-accelerated packages for perception-driven manipulation.

How to run the examples

1. Install & source the Humble or Jazzy version of ManyMove by following the instructions in the GitHub README.

2. Install Isaac Sim 5.0 and enable the ROS2 Simulation Control extension.

3. Launch the example:

   ros2 launch manymove_bringup lite_isaac_sim_movegroup_fake_cpp_trees.launch.py
   

4. Load .../manymove/manymove_planner/config/cuMotion/example_scene_lite6_grf_ros2.usd and start the simulation.

5. Press START on ManyMove’s HMI

Tested on Ubuntu 22.04 with ROS 2 Humble and on Ubuntu 24.04 with ROS2 Jazzy.

Feedback welcome!

1 post - 1 participant

Read full topic

Hey everyone!

I noticed that SWITCH Conference is happening the same week as ROSCon in Singapur. It is a major deep‑tech innovation and startup event that brings together founders, investors, corporates, and researchers focused on research commercialization…

I’d love to know if anyone in the ROS community has been there before, and if so, would you recommend me going (as an robotics enthusiasts or entrepreneurs wannabe)?

Also, is anyone here planning to attend this year?

Thanks in advance for any thoughts or advice!

1 post - 1 participant

Read full topic

Hi there,

I am currently working on a project which has similarities to something showcased on the Nav2 website landing page. I would be after recommendations of global planner and local planner/controller plugins to execute a trajectory made of parallel passes spaced by a given constant offset distance. It is similar to what is visible below (visible on Nav2) website:

I was not sure in the example above which type of localization method was employed (GPS based for outdoor application, as it seem close to an agricultural outdoor application?). Unsure also who or which company would be behind (I could have given them credit for the illustration above), so would be thankful if the community would know who or which company is behind this illustration.

On my case, at the end of each straight pass (in blue), the robot could reposition via a curved trajectory or pause and execute two turns in place for the repositioning pass. I do not need to maintain speed during the turns.

So far I have explored the straight line global planner plugin as shown in the Nav2 example and trialed the Regulated Pure Pursuit and Vector Pursuit as local planner / controller. Is there other local planner I should consider for this type of application (straight line then repositioning to next straight line)? The goal is to be able to maintain a precise trajectory for the straight passes while going on an acceleration, cruise, deceleration speed profile on the straight lines. I am currently trialing those in Gazebo simulating the environment where the robot will be deployed. I am able to generate the required waypoints via the simple commander API and using AMCL for now as my application is indoor.

Using Gazebo and AMCL, here are the kind of things I obtain via PlotJuggler:

First of, there are differences between ACML and groundtruth, so AMCL would require some improvements, but I can see the AMCL goes by each corner which are waypoints, so the robot from its perception goes to all waypoints. Second the trajectory followed (groundtruth) is within +/-10cm of the target. Not sure if other or better tuned controller can improve the order of magnitude of the accuracy, I would be aiming to about +/-1cm at 1m/s. This is a combination of localization + control method. Open to discuss if I need to improve localization first (AMCL or other, such as Visual + IMU odometry, UWB, …). I am also using Humble which does not have the python API driveOnHeading, to trial a pure straight line command (maybe similar to broadcasting in /cmd_vel a positive x component).

Thank you very much for your help and guidance,

Nicolas

PS: first post on my side, so apologies if this is the wrong platform, I was trying to find out about a specific Nav2 platform but could not join the Nav2 slack.

2 posts - 2 participants

Read full topic