Planet ROS
Planet ROS - http://planet.ros.org
Planet ROS - http://planet.ros.org http://planet.ros.org
ROS Discourse General: Wanted your feedback on an Agentic ROS Robotics development platform
Hey everyone,
I’ve been working with my team on a project that might interest those here who spend time with ROS, Gazebo, or general robotics tooling.
We recently opened up an early version of OORB Studio, a browser-based environment where you can build and test robots directly from your browser using natural language commands.
You can see a quick demo video here: LinkedIn post
It’s still very raw, plenty of bugs, rough edges, and missing features, but we’re sharing it early to get feedback from people who actually use ROS in practice.
If you’ve ever found yourself juggling too many tools just to get a basic prototype running, I’d love for you to give it a spin and tell us what works, what doesn’t, and what’s confusing.
You can try it out here: oorb.io
We also recently joined the Blueprint Residency program in San Francisco, where we’re focusing on improving the system architecture and learning from other robotics builders.
Any insights or feedback from this community would mean a lot, especially from those teaching, experimenting, or deploying with ROS2. The goal isn’t to promote anything, just to learn from real users and keep improving.
Thanks for reading, and I’m looking forward to your thoughts.
1 post - 1 participant
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: Hector Recorder: A terminal-based rosbag UI
Hi everyone,
I’d like to share our Hector Recorder with you, a terminal-based UI for recording ROS2 bags.
It can be used just like ros2 bag record
, but also displays live statistics - topics, message count, bandwidth, …
In addition, you can load all settings from a YAML file, allowing for convenient configuration and reproducible recording setups.
Optionally, the statistics can be published on a topic for further live inspection.
This tool is part of Team Hector’s default onboard logging setup and has been used in the creation of multiple datasets. We hope it proves useful for the community!
On a related note, I also made a small Nautilus extension that lets you view ROS 2 bag metadata right in your file browser: https://github.com/JoLichtenfeld/nautilus_ros2_bag_info
Best,
Jonathan Lichtenfeld
1 post - 1 participant
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: ROS2 support for Daheng Imaging VEN's cameras
Hi to everyone again! I‘ve recently dropped ROS2 package for Daheng Imaging VEN’s cameras. Take a look, if you have one or you are interested in
2 posts - 2 participants
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: INSAION with Sergi Grau-Moya and Victor Massagué Respall | Cloud Robotics WG Meeting 2025-10-22
The CRWG is pleased to welcome Sergi Grau-Moya, Co-founder and CEO of INSAION, and Victor Massagué Respall, Co-founder and CTO of INSAION, to our next meeting at Wed, Oct 22, 2025 4:00 PM UTC→Wed, Oct 22, 2025 5:00 PM UTC. INSAION provides an observability platform for your robot fleet, allowing users to optimise robot operations and explore advanced robot diagnostics. Sergi and Victor will share the purpose of the company and show some of the capabilities of the software, to add to the group’s research of Logging & Observability.
Last meeting, Carter Schultz of AMP joined the CRWG to discuss how AMP manages large deployments, and the pain points they see from doing so. If you would like to see the talk for yourself, is it 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
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: Announcing DepthAI ROS 2 Kilted Driver Release for Luxonis OAK cameras
Big update for ROS developers!
We’ve just released new DepthAI ROS packages - now built for ROS 2 Kilted and powered by DepthAI V3.
Highlights include:
RVC4 support – works with new OAK4 devices
Streamlined NN creation & renamed parameters for cleaner configs
New RGBD & Pointcloud nodes for faster, colored pointclouds
Thermal node support for thermal-equipped devices
Improved Camera nodes with undistorted stream options
Experimental VIO node (RVC4 support coming soon!)
We’ve also refined socket/frame naming, simplified examples, and added updated Rviz configs.
See the release blogpost: Luxonis Forum
Dive into the details and full changelog in our docs: Driver
2 posts - 2 participants
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: How do you access changelogs for ROS 2 releases?
Back in the times of ROS 1, I was used to read the “New packages for Turtly Turtle” post, click on the packages I’m interested in, which usually led to ROS wiki, and directly there, I could look at the changelog for that particular distro.
I haven’t found anything like that in ROS 2. The links usually lead either to external doc sites (like nav2 or ros control), or to github (if lucky, they lead directly to the correct branch). Then I have to go to commit history, find the changelog-updating commit and look around (or open the one package and check its CHANGELOG.rst). There is also an attempt at changelogs at index.ros.org, but it apparently doesn’t work: nav2_planner - ROS Package Overview . The changelog is empty. And even if it worked correctly, there’s no direct link from the news post to the package’s page at index.ros.org (but this shouldn’t be that difficult, right?).
Is there something more comfortable?
3 posts - 2 participants
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: Announcing Robot Lock: coordinate work on dev robots
Announcing a tiny but useful new Transitive capability!
Robot Lock
Indicate to others that you are working on a robot, and, optionally, what you are doing.
Most robotics companies suffer from a lack of development robots to test on. As a result, team members spend time tracking down robots that are available for testing, often checking Slack and other free-form communication channels to find out whether anyone else is using a particular robot or not. This is a waste of time.
Robot Lock solves this by giving members the ability to “lock” a robot, optionally adding a note describing what they are doing. Once locked, only they are able to unlock the robot again. Like with all Transitive capabilities, the front-end UI, showing the locked status and toggle, can be embedded in any web page, showing either the status of just one specific robot, or the locks of all robots in the fleet. In addition, the shell on the robot itself can be configured to show the lock status directly in the prompt itself (PS1
).
Demo
Getting Started
Setting this up on your robots only takes a few minutes:
- create an account on https://transitiverobotics.com,
- add your robot to your account by installing the agent using the provided curl command or run the docker image we provide, and
- add the Robot Lock capability from your Device page.
If you prefer to self-host, follow Setup | Transitive Robotics.
This capability is open-source.
About Transitive
Transitive is an open-source framework for building full-stack robotic capabilities that combine functionality on robot, cloud, and web. Transitive provides data-synchronization, deployment, and sandboxing, making it easy to build components for fleet management and operation that are accessible to anyone over the web – no VPN required. Transitive Robotics operates a hosted offering of Transitive and offers a number of ready-to-go, commercially supported capabilities such as low-latency video streaming, remote teleoperation, live map display, a React ROS SDK, and configuration management.
1 post - 1 participant
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: 【PIKA】Achievement of PIKA SDK for Teleoperating UR Robotic Arm
Hi everyone!
I’m excited to share our beginner-friendly guide on implementing teleoperation for UR robotic arms using PIKA Sense. This tutorial walks through the complete setup process, from environment configuration to running your first teleoperation session.
Check out the demo video to see it in action:
https://youtu.be/TNB1lPitM4Y?si=LIw0abAQMvbngZ4C
A Beginner’s Guide to PIKA Teleoperation (UR Edition)
Before starting, it is recommended to read Methods for Teleoperating Any Robotic Arm with PIKA first.
Now that you understand the principles, let’s start building a teleoperation program step by step. To quickly implement the teleoperation function, we will use the following tools:
- PIKA SDK: It enables quick access to all data from PIKA Sense and easy control of the gripper.
- Various conversion tools: Such as tools for converting XYZRPY (X/Y/Z coordinates + Roll/Pitch/Yaw angles) to a 4x4 homogeneous transformation matrix, converting XYZ coordinates and quaternions to a 4x4 homogeneous transformation matrix, and converting RPY angles (rotation around X/Y/Z axes) to a rotation vector.
- UR robotic arm control interface: This interface mainly uses the ur-rtde library. It realizes real-time control by sending target poses (XYZ coordinates and rotation vectors), speed, acceleration, control interval cycle (frequency), look-ahead time, and proportional gain.
Environment Setup
1. Clone the Code
git clone --recursive https://github.com/RoboPPN/pika_remote_ur.git
2. Install Dependencies
cd pika_remote_ur/pika_sdk
pip3 install -r requirements.txt
pip3 install -e .
pip3 install ur-rtde
UR Control Interface
Let’s start with the control interface. For teleoperation, we first need to create a proper control interface. For example, the original control interface of UR requires input of XYZ coordinates and a rotation vector, but the data we usually send in the teleoperation code is XYZRPY. This means we need to perform a conversion, which can be done either in the control interface or the main teleoperation program. Here, we choose to do the conversion in the main teleoperation program. The following is the control interface code for the UR robotic arm, and the code file is located at pika_remote_ur/ur_control.py
:
import rtde_control
import rtde_receive
class URCONTROL:
def __init__(self,robot_ip):
# Connect to the robot
self.rtde_c = rtde_control.RTDEControlInterface(robot_ip)
self.rtde_r = rtde_receive.RTDEReceiveInterface(robot_ip)
if not self.rtde_c.isConnected():
print("Failed to connect to the robot control interface.")
return
if not self.rtde_r.isConnected():
print("Failed to connect to the robot receive interface.")
return
print("Connected to the robot.")
# Define servoL parameters
self.speed = 0.15 # m/s
self.acceleration = 0.1 # m/s^2
self.dt = 1.0/50 # dt for 50Hz, or 1.0/125 for 125Hz
self.lookahead_time = 0.1 # s
self.gain = 300 # proportional gain
def sevol_l(self, target_pose):
self.rtde_c.servoL(target_pose, self.speed, self.acceleration, self.dt, self.lookahead_time, self.gain)
def get_tcp_pose(self):
return self.rtde_r.getActualTCPPose()
def disconnect(self):
if self.rtde_c:
self.rtde_c.disconnect()
if self.rtde_r:
self.rtde_r.disconnect()
print("UR disconnected")
# example
# if __name__ == "__main__":
# ur = URCONTROL("192.168.1.15")
# target_pose = [0.437, -0.1, 0.846, -0.11019068574221307, 1.59479642933605, 0.07061926626169934]
# ur.sevol_l(target_pose)
This code defines a Python class named URCONTROL
for communicating with and controlling the UR robot. The class encapsulates the functions of the rtde_control
and rtde_receive
libraries, and provides methods for connecting to the robot, disconnecting from it, sending servoL
commands, and obtaining the TCP (Tool Center Point) pose.
Core Teleoperation Code
The teleoperation code is located at pika_remote_ur/teleop_ur.py
.
From Methods for Teleoperating Any Robotic Arm with PIKA, we know that the principle of teleoperation can be generally divided into four steps:
- Acquire 6D pose data.
- Align coordinate systems.
- Implement incremental control.
- Map the 6D pose data to the robotic arm.
Acquiring Pose Data
The code is as follows:
# Get tracker device pose data
def get_tracker_pose(self):
logger.info(f"Starting to get pose data from {self.target_device} device...")
while True:
# Get pose data
pose = self.sense.get_pose(self.target_device)
if pose:
# Extract position and rotation data for further processing
position = pose.position # [x, y, z]
rotation = self.tools.quaternion_to_rpy(pose.rotation[0],pose.rotation[1],pose.rotation[2],pose.rotation[3]) # [x, y, z, w] quaternion
self.x,self.y,self.z, self.roll, self.pitch, self.yaw = self.adjustment(position[0],position[1],position[2],
rotation[0],rotation[1],rotation[2])
else:
logger.warning(f"Failed to get pose data from {self.target_device}, waiting for next attempt...")
time.sleep(0.02) # Get data every 0.02 seconds (50Hz)
This code acquires the pose information of the tracker named “T20” every 0.02 seconds. There are two types of tracker names: one starts with “WM” and the other starts with “T”. When the tracker is connected to the computer with a wire, the first connected tracker is named “T20”, the second one is “T21”, and so on. When connected wirelessly, the first tracker connected to the computer is named “WM0”, the second one is “WM1”, and so on.
The acquired pose data needs to be processed further. The adjustment
function is used to adjust the coordinates so that we match the coordinate system of the UR robotic arm’s end effector, achieving alignment between the two.
Coordinate System Alignment
The code is as follows:
# Adjustment matrix function
def adjustment(self,x,y,z,Rx,Ry,Rz):
transform = self.tools.xyzrpy2Mat(x,y,z, Rx, Ry, Rz)
r_adj = self.tools.xyzrpy2Mat(self.pika_to_arm[0],self.pika_to_arm[1],self.pika_to_arm[2],
self.pika_to_arm[3],self.pika_to_arm[4],self.pika_to_arm[5],) # Adjust coordinate axis direction pika--->robot arm end
transform = np.dot(transform, r_adj)
x_,y_,z_,Rx_,Ry_,Rz_ = self.tools.mat2xyzrpy(transform)
return x_,y_,z_,Rx_,Ry_,Rz_
The functions of this function are as follows:
- Convert the input pose
(x, y, z, Rx, Ry, Rz)
to a transformation matrix. - Obtain the adjustment matrix that transforms the PIKA coordinate system to the robotic arm end-effector coordinate system.
- Combine the two transformations by matrix multiplication.
- Convert the final transformation matrix back to pose parameters and return them.
Through this function, we can obtain the pose information that has been converted to match the robotic arm’s coordinate system.
Incremental Control
In teleoperation, the pose data provided by PIKA Sense is an absolute pose. However, we do not want the robotic arm to jump directly to this absolute pose. Instead, we hope that the robotic arm can follow the relative movement of the operator, starting from its current position. In short words, it means converting the change in the absolute pose of the operating device into the relative pose command that the robotic arm needs to execute.
The code is as follows:
# Incremental control
def calc_pose_incre(self,base_pose, pose_data):
begin_matrix = self.tools.xyzrpy2Mat(base_pose[0], base_pose[1], base_pose[2],
base_pose[3], base_pose[4], base_pose[5])
zero_matrix = self.tools.xyzrpy2Mat(self.initial_pose_rpy[0],self.initial_pose_rpy[1],self.initial_pose_rpy[2],
self.initial_pose_rpy[3],self.initial_pose_rpy[4],self.initial_pose_rpy[5])
end_matrix = self.tools.xyzrpy2Mat(pose_data[0], pose_data[1], pose_data[2],
pose_data[3], pose_data[4], pose_data[5])
result_matrix = np.dot(zero_matrix, np.dot(np.linalg.inv(begin_matrix), end_matrix))
xyzrpy = self.tools.mat2xyzrpy(result_matrix)
return xyzrpy
This function uses the operation rules of transformation matrices to implement incremental control. Let’s break down the code step by step:
Input Parameters
- base_pose: This is the reference pose at the start of teleoperation. When teleoperation is triggered, the system records the pose of the operating device at that moment and stores it as
self.base_pose
. This pose serves as the “starting point” or “reference zero point” for calculating all subsequent increments. - pose_data: This is the real-time pose data received from the operating device (PIKA Sense) at the current moment.
Matrix Conversion
The function first converts three key poses (represented in the [x, y, z, roll, pitch, yaw]
format) into 4x4 homogeneous transformation matrices. This conversion is usually completed by the tools.xyzrpy2Mat
function.
- begin_matrix: Converted from
base_pose
, it represents the pose matrix of the operating device at the start of teleoperation, denoted asT_begin
. - zero_matrix: Converted from
self.initial_pose_rpy
, it represents the pose matrix of the robotic arm’s end-effector at the start of teleoperation. This is the “starting point” of the robotic arm’s movement, denoted asT_zero
. - end_matrix: Converted from
pose_data
, it represents the pose matrix of the operating device at the current moment, denoted asT_end
.
Core Calculation
This is the most critical line of code:
result_matrix = np.dot(zero_matrix, np.dot(np.linalg.inv(begin_matrix), end_matrix))
We can analyze it using matrix multiplication:
The formula is expressed as: Result = T_zero * (T_begin)⁻¹ * T_end
np.linalg.inv(begin_matrix)
: Calculates the inverse matrix ofbegin_matrix
, i.e.,(T_begin)⁻¹
. In robotics, the inverse matrix of a transformation matrix represents the reverse transformation.np.dot(np.linalg.inv(begin_matrix), end_matrix)
: This step calculates(T_begin)⁻¹ * T_end
. The physical meaning of this operation is the transformation required to go from thebegin
coordinate system to theend
coordinate system. In other words, it accurately describes the relative pose change (increment) of the operating device from the start of teleoperation to the current moment, denoted asΔT
.np.dot(zero_matrix, ...)
: This step calculatesT_zero * ΔT
. Its physical meaning is to apply the previously calculated relative pose change(ΔT)
to the initial pose(T_zero)
of the robotic arm’s end-effector.
Result Conversion and Return
xyzrpy = tools.mat2xyzrpy(result_matrix)
: Converts the calculated 4x4 target pose matrixresult_matrix
back to the[x, y, z, roll, pitch, yaw]
format that the robot controller can understand.return xyzrpy
: Returns the calculated target pose.
Teleoperation Trigger
In fact, there are many ways to trigger teleoperation:
- Voice trigger: The operator can trigger teleoperation using a wake-up word.
- Server request trigger: Teleoperation is triggered by sending a request.
However, neither of the above methods is very convenient to operate. For voice trigger, an additional voice input module is required, and there is the problem of inaccurate wake-up word recognition. Sometimes, you have to say the wake-up word many times to trigger teleoperation successfully, and your mouth may get dry before teleoperation even starts. For the server request trigger, you need to use a control computer to send the request. It works well if there are two people to cooperate, but it becomes a hassle when there is only one person.
The method we use is to trigger teleoperation by detecting the state change of PIKA Sense. The operator only needs to hold PIKA Sense and double-click it quickly to reverse its state, thereby triggering teleoperation. The code is as follows:
# Teleoperation trigger
def handle_trigger(self):
current_value = self.sense.get_command_state()
if self.last_value is None:
self.last_value = current_value
if current_value != self.last_value: # State change detected
self.bool_trigger = not self.bool_trigger # Flip bool_trigger
self.last_value = current_value # Update last_value
# Execute corresponding operations based on new bool_trigger value
if self.bool_trigger :
self.base_pose = [self.x, self.y, self.z, self.roll, self.pitch, self.yaw]
self.flag = True
print("Start teleoperation")
elif not self.bool_trigger :
self.flag = False
#-------------------------------------------------Option 1: When teleoperation ends, robot stops at current pose, next teleoperation starts from current pose---------------------------------------------------
self.initial_pose_rotvec = self.ur_control.get_tcp_pose()
temp_rotvec = [self.initial_pose_rotvec[3], self.initial_pose_rotvec[4], self.initial_pose_rotvec[5]]
# Convert rotation vector to Euler angles
roll, pitch, yaw = self.tools.rotvec_to_rpy(temp_rotvec)
self.initial_pose_rpy = self.initial_pose_rotvec[:]
self.initial_pose_rpy[3] = roll
self.initial_pose_rpy[4] = pitch
self.initial_pose_rpy[5] = yaw
self.base_pose = self.initial_pose_rpy # Target pose data
print("Stop teleoperation")
#-------------------------------------------------Option 2: When teleoperation ends, robot returns to initial pose, next teleoperation starts from initial pose---------------------------------------------------
# # Get current robot arm pose
# current_pose = self.ur_control.get_tcp_pose()
# # Define interpolation steps
# num_steps = 100 # Can adjust steps as needed, more steps = smoother transition
# for i in range(1, num_steps + 1):
# # Calculate current interpolation point pose
# # Assumes initial_pose_rotvec and current_pose are both in [x, y, z, Rx, Ry, Rz] format
# interpolated_pose = [
# current_pose[j] + (self.initial_pose_rotvec[j] - current_pose[j]) * i / num_steps
# for j in range(6)
# ]
# self.ur_control.sevol_l(interpolated_pose)
# time.sleep(0.01) # Small delay between interpolations to control speed
# # Ensure final arrival at initial position
# self.ur_control.sevol_l(self.initial_pose_rotvec)
# self.base_pose = [self.x, self.y, self.z, self.roll, self.pitch, self.yaw]
# print("Stop teleoperation")
This code continuously obtains the current state of PIKA Sense through self.sense.get_command_state()
, which can only output two states: 0 or 1. When the program starts, bool_trigger
is set to False
by default. When the first state reversal occurs, bool_trigger
is set to True
. At this time, the pose of the tracker is set as the zero point, self.flag
is set to True
, and the control data is sent to the robotic arm to control it. To stop teleoperation, double-click quickly again to reverse the state. At this point, the robotic arm will stop at the current pose, and the next teleoperation will start from this pose. The above is the control method for the robotic arm when teleoperation stops in Option 1. In Option 2, when teleoperation stops, the robotic arm returns to the initial pose, and the next teleoperation starts from the initial pose. You can choose the appropriate teleoperation stop method according to your specific situation.
Mapping PIKA Pose Data to the Robotic Arm
The code for this part is as follows:
def start(self):
self.tracker_thread.start() # Start thread
# Main thread continues with other tasks
while self.running:
self.handle_trigger()
self.control_gripper()
current_pose = [self.x, self.y, self.z, self.roll, self.pitch, self.yaw]
increment_pose = self.calc_pose_incre(self.base_pose,current_pose)
finally_pose = self.tools.rpy_to_rotvec(increment_pose[3], increment_pose[4], increment_pose[5])
increment_pose[3:6] = finally_pose
# Send pose to robot arm
if self.flag:
self.ur_control.sevol_l(increment_pose)
time.sleep(0.02) # 50Hz update
In this part of the code, the increment_pose
calculated through incremental control is used. The RPY rotation in increment_pose
is converted to a rotation vector, and then the resulting data is sent to the robotic arm (the UR robotic arm is controlled by receiving XYZ coordinates and a rotation vector). Only when self.flag
is True
(i.e., teleoperation is enabled) will the control data be sent to the robotic arm.
Practical Operation
The teleoperation code is located in pika_remote_ur/teleop_ur.py
.
Step-by-Step Guide
-
Power on the UR robotic arm and enable the joint motors. If the end of the robotic arm is equipped with an actuator such as a gripper, enter the corresponding load parameters.
-
Configure the robot IP address on the tablet.
-
Set up the tool coordinate system.
Important: It is crucial to set the end-effector coordinate system such that the Z-axis points forward, the X-axis points downward, and the Y-axis points to the left. In the code, we rotate the PIKA coordinate system 90° counterclockwise around the Y-axis. After this rotation, the PIKA coordinate system has the Z-axis forward, X-axis downward, and Y-axis to the left. Therefore, the end-effector (tool) coordinate system of the robotic arm must be set to match this; otherwise, the control will be chaotic.
-
For the first use, adjust the speed to 20-30%, and then enable the remote control of the robotic arm.
-
Connect the tracker to the computer using a USB cable, and calibrate the tracker and the base station.
Navigate to the
~/pika_ros/scripts
directory and run the following command:bash calibration.bash
After the positioning calibration is completed, close the program.
-
Connect PIKA Sense and PIKA Gripper to the computer using a USB 3.0 cable.
Note: First, plug in PIKA Sense, which should be recognized as the
/dev/ttyUSB0
port. Then, plug in the gripper (the gripper requires 24V DC power supply), which should be recognized as the/dev/ttyUSB1
port. -
Run the code:
cd pika_remote_ur python3 teleop_ur.py
The terminal will output a lot of logs. Most of the initial logs will be:
teleop_ur - WARNING - Failed to get pose data from T20, waiting for next attempt...
Wait until the above log stops appearing and the following log is output:
pika.vive_tracker - INFO - New device update detected: T20
At this point, you can double-click PIKA Sense to start teleoperation.
Wrapping Up
That’s it! You should now have a working teleoperation setup for your UR arm. If you run into any issues or have questions, feel free to drop a comment below. I’d also love to hear about your experiences and any improvements you make to the code.
The full repository is available on GitHub – contributions and feedback are always welcome!
Happy teleoperating!
1 post - 1 participant
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: :new: ROSCon 2025 Mini-Workshops
Hi everyone,
I have some exciting news about ROSCon 2025! We’ve just added ten mini-workshops to the schedule.
These free, one-hour workshops are organized by our OSRA members and sponsors. They will take place on Mon, Oct 27, 2025 12:00 AM UTC→Mon, Oct 27, 2025 9:00 AM UTC, the first full day of ROSCon. No workshop registration is required—just show up with your standard ROSCon registration!
I’ve included the list of workshops and organizers below. Full details are available on the ROSCon website.
- “Hands-On Robot Arm Control with ROS 2 and MoveIt Pro” with PickNik.
- “Zenoh Drakes of a Flame” with Angelo Corsaro, Julien Enoch, and Yu-Yuan Yuan from Zettascale.
- “Automate Your ROS Bag Analysis: Getting Started with Roboto” with Yves Albers and Benji Barash from Roboto AI.
- “Demonstrating the Canonical Observability Stack for Devices” with Guillaume Beuzeboc from Canonical.
- “Hands-on ROS 2 with Rubik Pi 3” with Qualcomm Technologies.
- “Evolving ROS 2 for Real-Time Control of Learned Policy-Driven Robots” with Hemal Shah from NVIDIA.
- “b-controlled Box - a real-time ROS 2 gateway for industrial 24/7 applications” with Denis Stogl and Yara Shahin from b-robotized (Stogl Robotics).
- “Simulate. Verify. Improve: ROS 2 Sim↔Real for Environmental Robotics in Tropical Cities” with David Tan and Daniel Wong of NETATECH.
- “ROS 2 Native IMU Sensors with AI-Powered Sensor Fusion in Mobile Robotics” with M. Leox Karimi and Edwin Babaians from Olive Robotics.
- “ROS-Industrial Scan-N-Plan” with Michael Ripperger from ROS-Industrial / Southwest Research Institute.
1 post - 1 participant
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: NVIDIA's Greenwave Monitor - A tool for high-performance topic monitoring and diagnostics
The Isaac team at NVIDIA is open sourcing Greenwave Monitor, a tool we use internally to monitor and debug topics.
It provides the following features:
-
A node similar to a C++ based
ros2 topic hz
, i.e., subscribes to topics to determine the message rate and latency. The Greenwave node is performant, publishes Diagnostics, and offers services to manage topics and expected frequencies. -
Terminal-based dashboards that display topic rates, latency, and status, and allow you to add/remove topics and set expected frequencies.
-
A header only C++ library so you can publish compatible diagnostics directly from your own nodes for reduced overhead.
This diagram shows an overview of the architecture:
We provide two different TUI frontends for you to try. One is a fork of the excellent r2s project, it is powerful but can become slow when there are many topics, we also provide a basic, fast, lightweight curses based frontend.
This project grew out of Isaac ROS NITROS diagnostics, but is completely standalone, with no dependency on Isaac / Isaac ROS.
Try it out (instructions in the README)! Let us know if you find it useful, if there are features you would like to see, or bugs you find please raise an issue (or open a PR) on the Github page.
1 post - 1 participant
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: Paper: A Modular ROS2 Gateway for CAN-based Systems: Architecture and Performance Evaluation
Hello Open Robotics Community,
I’m excited to share my latest paper, “A Modular ROS2 Gateway for CAN-based Systems: Architecture and Performance Evaluation,” which I believe addresses a critical challenge in modern robotics: the robust integration of real-time Controller Area Network (CAN) systems with higher-level robotics frameworks like ROS 2.
The Challenge:
The paper tackles the fundamental conflict between low-level fieldbuses like CAN, which ensure data integrity and real-time control, and high-level middleware like ROS 2, which offers powerful tooling but typically runs on non-real-time operating systems. Bridging this gap is essential for creating intelligent machines.
Our Approach & Contributions:
We present a novel, modular gateway architecture designed to treat the gateway as a digital twin of the CAN system. This approach aims to abstract low-level CAN complexities while preserving safety features and data fidelity. Our key contributions are threefold:
-
A novel, modular ROS 2 gateway architecture based on the digital twin pattern, providing semantic abstraction for arbitrary CAN-based systems.
-
An open-source example implementation of this architecture, offering a practical and reusable tool for the robotics community.
-
A rigorous performance evaluation of the open-source implementation on a CAN-based mobile robot, quantifying resource usage, latency, and jitter of the system.
Key Findings:
Validated on a 1:5 scale model car (the CanEduDev Rover platform, Fig. 1 in the paper), our performance evaluation revealed:
-
Average latencies of 170.4 µs and average jitter of 74.0 µs for CAN to ROS message transmission, demonstrating sub-millisecond performance suitable for soft real-time control.
-
Bimodal latency distribution and periodic performance spikes, suggesting areas for optimization, potentially related to ROS 2 middleware (e.g., FastDDS) or OS scheduling artifacts.
-
Low CPU usage overhead for the gateway application, especially with hardware-level CAN filtering.
-
Linear scaling of memory consumption with the number of nodes, primarily due to Python-based ROS nodes running in separate processes without node composition.
System Implications & Benefits:
This integration significantly lowers the barrier for simulating entire systems with tools like Gazebo. It unlocks the full potential of ROS tooling (e.g., ROS bags for data recording and analysis). Crucially, it makes the system more accessible to individuals with a robotics or research background by abstracting away low-level CAN complexities.
Limitations & Future Work:
While providing significant benefits, the current implementation has limitations, such as the lack of robust safeguards against critical ROS node crashes and the observed bimodal latency distribution. Future work will involve C++ re-implementation for better resource efficiency, detailed root cause analysis of latency variations (e.g., using ros2_tracing), and comparative analysis with different ROS middleware implementations or a PREEMPT_RT Linux kernel.
We believe this work provides a concrete design pattern and a performance roadmap for developers bridging industrial control protocols with modern robotics frameworks.
You can read the full paper here: Resources - CanEduDev
I welcome your thoughts, questions, and feedback on the architecture, performance analysis, and broader implications of this work.
Thank you!
Hashem Hashem
Co-founder, CanEduDev
3 posts - 2 participants
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: ROSCon 2025 Exhibit Map Now Available
ROSCon 2025 Exhibit Map Now Available 
Hi Everyone,
We just posted the final exhibitor map for ROSCon 2025 in Singapore. An interactive version of the map is also available here.
Our sponsors and exhibitors help make ROSCon possible, and many of them have fantastic live demonstrations planned for the event! I’ve included a full list of sponsors and exhibitors below so you can start building your itinerary for ROSCon.
Gold Sponsors
- AMD booth 17 / 18
- Canonical booth 51/52
- Clearpath Robotics booth 37/38
- Dexory booth 21/22
- Intrinsic booth 1/2
- Kabam booth 30/45
- Lionsbot booth 14/29
- National Robotics Program booth 12/13
- Netatech booth 41/42
- NVidia
- Qualcomm booth 39/40
- Robotis booth 35/36
- Roboto AI booth 19/20
- ROS-Industrial booth 25/26
- Zettascale booth 23/24
Silver Sponsors
- AgileX booth 7
- Botsync booth 27
- Clutterbot booth 50
- dConstruct booth 9
- EYS3D booth 16
- Foxglove booth 34
- Hope Technik booth 31
- Huawei booth 49
- JFrog booth 47
- Main Street Autonomy booth 32
- Megazo booth 15
- Peppermint Robotics booth 48
- Picknik booth 43
- Sony booth 3
- Stereolabs booth 46
- UVIfy booth 4
- Xnergy booth 10
- XSquare booth 8
Bronze Sponsors
- Aliciabots
- Amazon
- Apex
- Autoware
- b-robotized (Stogl Robotics)
- Ekumen
- eSOL
- IEEE RAS
- Locus Robotics
- Nokia Bell Labs
- Realsense
Startup Alley Sponsors
- Automatika booth 5/6-B
- Heex booth 5/6-C
- Kinisi Robotics booth 5/6-A
- Olive Robotics booth 5/6-E
- Prefix.dev booth 5/6-F
- ReductStore booth 5/6-D
- Smarobix booth 5/6-G
1 post - 1 participant
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: What's your stack for debugging robots in the wild?
Hi there ROS community,
My colleague and I are mapping out best practices for managing deployed robot fleets, and we’d love to learn from your real-world experience.
As robots move from the lab into the wild, the process for debugging and resolving issues gets complicated. We’re trying to move past our own ad-hoc methods and are curious about how your teams handle the entire lifecycle of an incident.
Specifically, we’re focused on these four areas:
-
Incident & Resolution Tracking
When a novel issue is solved, how do you capture that hard-won knowledge for the rest of the team? We’re curious about your process for creating a durable record of the diagnostic path and the fix, so the next engineer doesn’t have to solve the same problem from scratch six months from now. -
Hardware & Software Context
How do you correlate a failure with the specific context of the robot? We’ve found it’s often crucial to know the exact firmware of a sensor, the driver version, the OS patch level, or even the manufacturing batch of a component. How do you capture and surface this data during an investigation? -
Remote vs. On-Site Debugging
What is your decision tree for debugging? How much can you solve remotely with the data you have? What are the specific triggers that force you to accept defeat and send a person on-site? What’s the one piece of data you wish you had to avoid that trip? -
Fleet-Wide Failure Analysis
How do you identify systemic issues across your fleet? For example, discovering that a specific component fails more often under certain circumstances. What does your data analysis pipeline look like for finding these patterns—the “what, why, when, and where” of recurring failures?
We’re hoping to get a good public discussion going in this thread about the tools and workflows you’re using today. Whether it’s custom scripts, telegraf, prometheus, grafana dashboards, or something else.
On a separate note, this problem space is our team’s entire focus at INSAION. If you’re wrestling with these challenges daily and find the current tooling inadequate, we’d be very interested to hear your perspective. Please feel free to send me a DM for an honest, engineer-to-engineer conversation.
Keep your robots healthy and running!
Sergi from INSAION
1 post - 1 participant
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: Invite: How to Make the Most of ROSCon (for Women in Robotics)
WomeninRobotics.org members are encouraged to check the Slack group for an invitation to the following:
Ahead of ROSCon 2025, we’re hosting a prep session “How to Make the Most of ROSCon, as a Speaker, Regular, or First-timer” on Wednesday Oct 8th/Thursday Oct 9th depending on timezone.*
This will be a structured, facilitated session for anyone attending ROSCon.ros.org (or still considering it!).
Know someone who’d be interested? Given the relatively small intersection of the robotics community, your help reaching interested attendees would be very appreciated!
Till soon,
Deanna (2024 keynote)
1 post - 1 participant
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: ANNOUNCEMENT: October 9 7:00pm: Boston Robot Hackers Meetup
REGISTER: Eventbrite Link
Greetings! I am excited to announce the next meeting of the Boston Robot Hackers!
Date: Thursday October 9 at 7:00pm
Location: Artisans Asylum, 96 Holton Street, Boston (Allston)
REGISTER: Eventbrite Link
We’re excited that our talk this month is by David Dorf and the topic: “Affordable Biomimetic Robot Hands”. David will discuss new ways of building robot end-effectors (hands). He will share novel methods for tackling these issues with 3D printing flexible materials and biomimetic design and interfacing to ROS2.
1 post - 1 participant
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: Videos from ROSCon UK 2025 in Edinburgh 🇬🇧
Hi Everyone,
The entire program from our inaugural ROSCon UK in Edinburgh is now available ad free
on the OSRF Vimeo account. You can find the full conference website here.
1 post - 1 participant
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: DroidCam in ROS2
Hi to everyone! I‘ve recently published ROS2 package for DroidCam to ease usage of your Andoid/iPhone as a webcamera in ROS2.
1 post - 1 participant
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: ROS2 URDF language reference?
The ROS1 wiki includes a complete reference for the URDF language. The ROS2 documentation contains a series of URDF tutorials, but as far as I can see no equivalent language reference. Is the ROS1 wiki still the authoritative reference for URDF? If not, where can I find the latest reference?
1 post - 1 participant
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: Simple composable and lifecycle node creation - Turtle Nest 1.2.0 update
When developing with ROS 2, I often have to create new nodes that are composable or lifecycle nodes. Setting them up from scratch can be surprisingly tedious, which is why I added a feature to Turtle Nest that allows you to create these nodes with a single click.
Even the CMakeLists.txt
and other setup files are automatically updated, so you can run the template node immediately after creating it.
Lifecycle and composable nodes are available in Turtle Nest since the newest 1.2.0 release, which is now available for all the active ROS 2 distributions via apt installation. Since the last announcement here in Discourse, it’s possible now to to also create Custom Message Interfaces package.
Hope you find these features as useful as they’ve been for my day-to-day development!
4 posts - 2 participants
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: Update RMW Zenoh-Pico for Zenoh 1.4.0
At ROSConJP 2025 on 9/9, eSOL demonstrated the robot operation by applying micro-ROS to Zenoh-Pico.
Fortunately, @Yadunund gave an excellent presentation on integrating ROS and Zenoh-Pico, and I think many Japanese developers learned about Zenoh-Pico.
Now that the team has a decent working experience, eSOL would like to announce the update of the software we showed at ROSConJP 2025.
- RMW Zenoh-Pico: GitHub - esol-community/rmw_zenoh_pico: Zenoh-pico implementation for micro-ROS
- Latest tag: 1.4.0
- micro-ROS Setup: GitHub - esol-community/micro_ros_setup at rmw_zenoh_pico
- Supported branch: rmw_zenoh_pico
- micro-ROS PlatformIO: GitHub - esol-community/micro_ros_platformio at feature/rmw_zenoh_pico
- Supported branch: feature/rmw_zenoh_pico
- Example app: micro_ros_platformio/examples/micro-ros_zenoh_pico_publisher at feature/rmw_zenoh_pico · esol-community/micro_ros_platformio · GitHub
This update is an enhancement to the previously posted version of the following topic.
Major updates include:
- Support Zenoh and Zenoh-Pico version 1.4.0
- Support for several M5Stack (ESP32) dev kits in PlatformIO environments
- Additional patches for several Zenoh-Pico
- Micro-ROS only without ROS and Zenohd
- Confirmed that M5Stack can communicate with both Unicast and Multicast
Here’s a video at the end.
We haven’t been able to measure precisely, but it is able to send ROS messages over the ESP32 Wi-Fi at around 20msec intervals.
1 post - 1 participant
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: [Announcement] Safe DDS 3.0 is ISO 26262 ASIL D certified — ROS 2 tutorial + field deployment
Safe DDS 3.0 is now ISO 26262 ASIL D certified (renewal after 2.0). It’s compatible with ROS 2. We’re sharing a hands-on tutorial and pointing to a field-deployed device using Safe DDS.
-
ROS 2 tutorial: https://safe-dds.docs.eprosima.com/main/intro/tutorial_ros2.html
-
Field deployment (RealSense D555 PoE): https://realsenseai.com/ruggedized-industrial-stereo-depth/d555-poe/?q=%2Fruggedized-industrial-stereo-depth%2Fd555-poe%2F&
Why this might help ROS 2 teams
Many projects need deterministic communications and safety certification evidence on the path to production. Our goal with Safe DDS is to provide a certified DDS option that integrates with existing ROS 2 workflows while supporting real-world operational needs (TSN, redundancy, memory control, etc.).
Certification cadence: Safe DDS has maintained ASIL-D certification across major releases (2.0 → 3.0). For teams planning multi-year products, the ability to renew certification as versions evolve can simplify compliance roadmaps.
What’s new in Safe DDS 3.0 (highlights)
-
@optional
&@external
type support — optional members; external basic types; sequences/arrays of basic types; and strings. -
Custom memory allocators — integrate your own allocators for tighter control.
-
Channel redundancy — listen on multiple channels simultaneously for fault tolerance.
-
Manual entity decommissioning — finer control over DDS entity lifecycle.
-
TSN compatibility for UDPv4 transport — operate the ASIL-D–certified UDPv4 transport within TSN setups.
-
Ethernet transport — native IEEE 802.1Q (TSN-compatible).
-
Docs & tutorials — expanded resources (ROS 2 integration, RTEMS getting-started, board packages for NXP, STMicroelectronics, Espressif, …).
Using Safe DDS with ROS 2
The tutorial below walks through the integration model and configuration patterns with ROS 2:
Tutorial: https://safe-dds.docs.eprosima.com/main/intro/tutorial_ros2.html
For those evaluating real deployments, here’s a previously released ruggedized depth camera using Safe DDS:
Field deployment (RealSense D555 PoE):
https://realsenseai.com/ruggedized-industrial-stereo-depth/d555-poe/?q=%2Fruggedized-industrial-stereo-depth%2Fd555-poe%2F&
Open to questions
Happy to discuss ROS 2 integration details (QoS, discovery, transports), TSN/802.1Q topologies, determinism/memory considerations, and migration paths (prototype on Fast DDS → production with Safe DDS).
1 post - 1 participant
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: Rosbag2 composable record - splitting files
Hi
I have been using the rosbag2 to record topics as a composable node for a while now. Does anyone here know how I could make use of splitting the recording into several files during the recording process using the max_file_size parameter? Is this even possible in the composable node method?
3 posts - 2 participants
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: What’s the #1 bottleneck in your robotics dev workflow? (help us prioritize SnappyTool)
Hi everyone,
I’ve been consulting in robotics on and off, and one pattern keeps coming up: our development tools are still too painful.
-
Setting up projects can take days, often requiring advanced expertise just to get an environment working.
-
Teams often say, “Framework X didn’t work for us, so we built our own library.” That may solve a narrow problem, but it slows down progress for the field as a whole.
We think there must be a better way.
That’s why we’re building SnappyTool a browser-based drag-and-drop robotics design platform where you can:
-
Assemble robots visually
-
Auto-generate URDF / ROS code
-
Share designs and even buy/sell robot parts via a marketplace
-
Use it freely with a generous freemium model (not gatekeeping innovation!!)
The ask:
What’s the #1 bottleneck in your robotics workflow that, if solved, would significantly improve your productivity (enough that you or your team would pay for it)?
Examples could be:
-
Simulation setup
-
CAD → URDF conversion
-
Version control for robot models
-
Sourcing compatible hardware parts
-
Deployment and integration
We’ve have a little runway and assembled a small team to work full-time on this. We’d like to make sure we are solving real pains first, not imaginary ones.
Any input would be very much appreciated thank you!
1 post - 1 participant
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Industrial: New Tools for Robotics: RQT Frame Editor and the pitasc Framework
As robotics continues to expand into industrial and collaborative environments, researchers and developers are working on tools that make robots easier to configure, teach, and reconfigure for real-world tasks. In a recent talk, Daniel Bargmann (Fraunhofer IPA) introduced two powerful software solutions designed for exactly this purpose: the RQT Frame Editor and the pitasc Framework.
RQT Frame Editor – Simplifying TF-Frame Management
The RQT Frame Editor is a ROS plugin that makes working with TF-frames more intuitive. Instead of editing configuration files manually, users can visually create, arrange, and adjust frames within the familiar RQT and RViz environments.
Key features include:
Interactive frame manipulation – Move, rotate, or manually set values for frames.
Copy and reuse poses – Copy positions or orientations from existing frames.
Mesh visualization – Attach meshes (including custom STL files) to frames and view them in RViz.
Frame grouping and pinning – Organize frames by groups or “pin” active frames for efficient workflow.
ROS service integration – Use frame editor functionality programmatically in your own applications.
These capabilities are especially valuable for developers working on multi-robot setups, simulation environments, or applications that require frequent TF-frame adjustments.
Documentation and source code are available on GitHub
pitasc – A Skill-Based Framework for Force-Controlled Robotics
The second tool highlighted in the presentation is pitasc, a robot control framework designed for force-controlled assembly and disassembly tasks. Unlike traditional, vendor-specific robot programming approaches, pitasc uses a skill-based programming model.
In practice, this means developers do not write low-level motion code directly. Instead, they arrange and parameterize skills—reusable building blocks that range from simple movements (e.g., LIN or PTP) to advanced behaviors that combine position and force control across different dimensions.
Real-World Applications
pitasc has already been deployed across a wide variety of industrial use cases, including:
Assembly of plastic components
Riveting, screwing, and clipping tasks
Flexible robot cells with rapid reconfiguration
Dual-arm coordination, such as automated wiring of electrical cabinets
This flexibility allows pitasc to support both collaborative robots and industrial robots, bridging the gap between research and production environments.
Documentation and source code available are available here.
pitasc at a glance
Live demo of rqt frame editor and pitasc
Watch the full talk by Daniel Bargmann on YouTube to see live demos of both the RQT Frame Editor and pitasc in action, including real-world examples of assembly and disassembly tasks
![[WWW] [WWW]](./rostheme/img/moin-www.png)
ROS Discourse General: AMP With Carter Schultz | Cloud Robotics WG Meeting 2025-10-08
The CRWG is pleased to welcome Carter Schultz of AMP to our coming meeting at Wed, Oct 8, 2025 4:00 PM UTC→Wed, Oct 8, 2025 5:00 PM UTC. AMP is working to modernise global recycling infrastructure with AI‑driven robotics. Carter will share the company’s vision and, in particular, the key challenges it faces when operating a large fleet of autonomous robots.
Please note that the meeting day has changed for the CRWG. Previous meetings were on Monday; they are now on Wednesday at the same time.
Last meeting, guest speakers Lei Fu and Sahar Slimpour, from the Zurich University of Applied Sciences and University of Turku respectively, joined the CRWG to talk about their ROSBag MCP Server research (also shared in ROS Discourse). If you’re interested to watch 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
![[WWW] [WWW]](./rostheme/img/moin-www.png)