[Documentation] [TitleIndex] [WordIndex] 

Planet ROS

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

Planet ROS - http://planet.ros.org[WWW] 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

Read full topic

[WWW] https://discourse.openrobotics.org/t/wanted-your-feedback-on-an-agentic-ros-robotics-development-platform/50592

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.

Screenshot from 2025-10-17 11-44-16

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

Read full topic

[WWW] https://discourse.openrobotics.org/t/hector-recorder-a-terminal-based-rosbag-ui/50577

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 :slight_smile:

2 posts - 2 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/ros2-support-for-daheng-imaging-vens-cameras/50568

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

Read full topic

[WWW] https://discourse.openrobotics.org/t/insaion-with-sergi-grau-moya-and-victor-massague-respall-cloud-robotics-wg-meeting-2025-10-22/50547

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. :tada:
Highlights include:
:small_blue_diamond: RVC4 support – works with new OAK4 devices
:small_blue_diamond: Streamlined NN creation & renamed parameters for cleaner configs
:small_blue_diamond: New RGBD & Pointcloud nodes for faster, colored pointclouds
:small_blue_diamond: Thermal node support for thermal-equipped devices
:small_blue_diamond: Improved Camera nodes with undistorted stream options
:small_blue_diamond: Experimental VIO node (RVC4 support coming soon!)
We’ve also refined socket/frame naming, simplified examples, and added updated Rviz configs.
:backhand_index_pointing_right: See the release blogpost: Luxonis Forum
:backhand_index_pointing_right: Dive into the details and full changelog in our docs: Driver

2 posts - 2 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/announcing-depthai-ros-2-kilted-driver-release-for-luxonis-oak-cameras/50546

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

Read full topic

[WWW] https://discourse.openrobotics.org/t/how-do-you-access-changelogs-for-ros-2-releases/50530

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

4_demo

Getting Started

Setting this up on your robots only takes a few minutes:

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

Read full topic

[WWW] https://discourse.openrobotics.org/t/announcing-robot-lock-coordinate-work-on-dev-robots/50513

ROS Discourse General: 【PIKA】Achievement of PIKA SDK for Teleoperating UR Robotic Arm

Hi everyone! :waving_hand:

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:

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:

  1. Acquire 6D pose data.
  2. Align coordinate systems.
  3. Implement incremental control.
  4. 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:

  1. Convert the input pose (x, y, z, Rx, Ry, Rz) to a transformation matrix.
  2. Obtain the adjustment matrix that transforms the PIKA coordinate system to the robotic arm end-effector coordinate system.
  3. Combine the two transformations by matrix multiplication.
  4. 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

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.

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

Result Conversion and Return

Teleoperation Trigger

In fact, there are many ways to trigger teleoperation:

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

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

  2. Configure the robot IP address on the tablet.

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

  4. For the first use, adjust the speed to 20-30%, and then enable the remote control of the robotic arm.

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

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

  7. 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! :robot:

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/pika-achievement-of-pika-sdk-for-teleoperating-ur-robotic-arm/50508

ROS Discourse General: :new: ROSCon 2025 Mini-Workshops

SponsorWorkshops

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.

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/roscon-2025-mini-workshops/50479

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.

r2s_gw screenshot

It provides the following features:

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

  2. Terminal-based dashboards that display topic rates, latency, and status, and allow you to add/remove topics and set expected frequencies.

  3. 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:

greenwave_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

Read full topic

[WWW] https://discourse.openrobotics.org/t/nvidias-greenwave-monitor-a-tool-for-high-performance-topic-monitoring-and-diagnostics/50477

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:

  1. A novel, modular ROS 2 gateway architecture based on the digital twin pattern, providing semantic abstraction for arbitrary CAN-based systems.

  2. An open-source example implementation of this architecture, offering a practical and reusable tool for the robotics community.

  3. 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:

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

Read full topic

[WWW] https://discourse.openrobotics.org/t/paper-a-modular-ros2-gateway-for-can-based-systems-architecture-and-performance-evaluation/50461

ROS Discourse General: ROSCon 2025 Exhibit Map Now Available

ROSCon 2025 Exhibit Map Now Available :world_map:


25ROSCon_Exhibitor Map Final (1)

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.

:1st_place_medal: Gold Sponsors

:2nd_place_medal: Silver Sponsors

:3rd_place_medal: Bronze Sponsors

:seedling: Startup Alley Sponsors

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/roscon-2025-exhibit-map-now-available/50455

ROS Discourse General: What's your stack for debugging robots in the wild?

Hi there :waving_hand: 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:

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

  2. 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?

  3. 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?

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

Read full topic

[WWW] https://discourse.openrobotics.org/t/whats-your-stack-for-debugging-robots-in-the-wild/50451

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! :folded_hands:

Till soon,
Deanna (2024 keynote)

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/invite-how-to-make-the-most-of-roscon-for-women-in-robotics/50431

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

Read full topic

[WWW] https://discourse.openrobotics.org/t/announcement-october-9-7-boston-robot-hackers-meetup/50419

ROS Discourse General: Videos from ROSCon UK 2025 in Edinburgh 🇬🇧

ROSCon2025 (2)

Hi Everyone,

The entire program from our inaugural ROSCon UK in Edinburgh is now available :sparkles: ad free :sparkles: on the OSRF Vimeo account. You can find the full conference website here.


1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/videos-from-roscon-uk-2025-in-edinburgh/50390

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

Read full topic

[WWW] https://discourse.openrobotics.org/t/droidcam-in-ros2/50381

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

Read full topic

[WWW] https://discourse.openrobotics.org/t/ros2-urdf-language-reference/50377

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

Read full topic

[WWW] https://discourse.openrobotics.org/t/simple-composable-and-lifecycle-node-creation-turtle-nest-1-2-0-update/50374

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.

This update is an enhancement to the previously posted version of the following topic.

Major updates include:

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

Read full topic

[WWW] https://discourse.openrobotics.org/t/update-rmw-zenoh-pico-for-zenoh-1-4-0/50364

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.

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)

Using Safe DDS with ROS 2

The tutorial below walks through the integration model and configuration patterns with ROS 2:

:backhand_index_pointing_right: 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:

:backhand_index_pointing_right: 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

Read full topic

[WWW] https://discourse.openrobotics.org/t/announcement-safe-dds-3-0-is-iso-26262-asil-d-certified-ros-2-tutorial-field-deployment/50361

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

Read full topic

[WWW] https://discourse.openrobotics.org/t/rosbag2-composable-record-splitting-files/50360

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.

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:

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:

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

Read full topic

[WWW] https://discourse.openrobotics.org/t/what-s-the-1-bottleneck-in-your-robotics-dev-workflow-help-us-prioritize-snappytool/50359

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:

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:

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] https://rosindustrial.org/news/2025/9/30/new-tools-for-robotics-rqt-frame-editor-and-the-pitasc-framework

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

Read full topic

[WWW] https://discourse.openrobotics.org/t/amp-with-carter-schultz-cloud-robotics-wg-meeting-2025-10-08/50344

2025-10-18 12:17