[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: Questions to intrinsic and extrinsic calibration. Any help?

Hi folks,

I am planning to build a calibration station for intrinsic and extrinsic parameters using a monitor as the target.
Has anyone here tried using a monitor for calibration before?
Any tips on which type of monitor works best for this setup?

Cheers,
Your Calibration man :slight_smile:

2 posts - 2 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/questions-to-intrinsic-and-extrinsic-calibration-any-help/50687

ROS Discourse General: Blog post: Reproducible cross-platform ROS installation with Pixi

Hey all,

We’ve seen a big increase in the interest on making ROS supported on multiple platforms. And in general easier to install. This is not the first time I post on this forum about this, but seeing it’s a recurring topic, I would like to cross-post our latest blog post on the matter.

Blog post: Pixi: Modern package management for Robotics | prefix.dev

I’ve included a few of short videos to showcase what it could look like if you use ROS through Pixi.

I’m really looking forward to discussing the topic further at ROSCon2025. There will be two related BOF’s on Monday:

And @KimMcG and myself will present on the topic on Wednesday starting at 14:00.

Please try it out and let me know what you think!

Let’s make it easy and quick to install ROS anywhere and bring ROS to a new level of users it can reach!

5 posts - 4 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/blog-post-reproducible-cross-platform-ros-installation-with-pixi/50683

ROS Discourse General: Introducing: `ros2_fmt_logger`

Tired of fixing compile issues like:

warning: format ‘%d’ expects argument of type ‘int’, but argument has type ‘std::vector<int>::size_type’ {aka ‘long unsigned int’} [-Wformat=]

when you want to print a vector size?

Or writing .c_str() when printing an std::string?

Confused when using milliseconds to throttle?[1]

Introducing:

ros2_fmt_logger

A modern, ROS 2 logging library that provides fmt-style formatting as a replacement for RCLCPP logging macros.

Features

Examples

Once-only logging

logger.info_once("This message will only appear once, no matter how many times called");

Throttled logging

using std::chrono_literals::operator""s;
logger.warn_throttle(1s, "This warning appears at most once per second: {}", value);

Change-based logging

// Log only when the value changes
logger.info_on_change(sensor_value, "Sensor reading changed to: {}", sensor_value);

// Log only when change exceeds threshold
logger.error_on_change(temperature, 5.0, "Temperature changed significantly: {:.1f}°C", temperature);

Format String Syntax

Uses the powerful fmt library format syntax:

// Basic formatting
logger.info("Hello, {}!", name);

// Positional arguments
logger.info("Processing {1} of {0} items", total, current);

// Format specifiers
logger.info("Progress: {:.1%}", progress);  // Percentage with 1 decimal
logger.info("Value: {:08.2f}", value);     // Zero-padded floating point
logger.info("Hex: {:#x}", number);         // Hexadecimal with 0x prefix

// Container formatting (requires fmt/ranges.h)
logger.info("Values: {}", std::vector{1, 2, 3, 4});

See demo_ros2_fmt_logger.cpp for more examples.

NAQ

  1. This is a direct violation of REP-103 ↩︎

3 posts - 2 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/introducing-ros2-fmt-logger/50665

ROS Discourse General: Gamepad Teleoperation for Robotic Arm—A New Intuitive Control Experience

Hi everyone! :waving_hand:

I’d like to share a project that enables intuitive control of the PiPER robotic arm using a standard gamepad. This might be useful for those working on robotic arm teleoperation or looking for a ready-to-use control interface.

Overview

This project provides precise and intuitive control of the PiPER robotic arm through a conventional game controller in a visual environment. It supports multiple kinematics libraries and offers both joint-space and task-space control modes.

Control a Robotic Arm Like a Game! �

Key Features:

Repository: GitHub - kehuanjack/Gamepad_PiPER: This project implements the functionality of teleoperating a PiPER robotic arm using a gamepad.
Organization: GitHub - agilexrobotics/Agilex-College: Agilex College

image

Environment Setup

Requirements:

Installation:

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

Choose your kinematics library (cuRobo recommended):

Option 1: pinocchio library (Python 3.9) (click for more details) Option 2: PyRoKi library (Python ≥ 3.10) (click for more details) Option 3: cuRobo library (Python ≥ 3.8, CUDA 11.8 recommended) � (click for more details)

Quick Start

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

  1. Connect gamepad via USB or Bluetooth

  2. Launch control service:

   python3 main_virtual.py  # Recommended for first-time testing
   # or
   python3 main.py  # For real robot control
  1. Open web interface: Navigate to http://localhost:8080 for visualization

Gamepad Control Mapping

Button Functions

Button Short Press Long Press
HOME Connect/Disconnect arm -
START Switch upper control mode (Joint/Pose) Switch lower control mode
BACK Switch command mode (0x00/0xAD) -
Y Return to zero position -
A Save current position Clear saved position
B Restore last saved position -
X Toggle playback order Clear all positions
LB Increase speed factor Decrease speed factor
RB Increase movement speed Decrease movement speed

Joysticks & Triggers

Control Joint Mode Pose Mode
Left Stick J1 (Left/Right), J2 (Up/Down) End-effector X/Y movement
Right Stick J3 (Up/Down), J6 (Left/Right) End-effector Z & rotation around Z
D-pad J4 (Left/Right), J5 (Up/Down) End-effector rotation around X/Y
LT Close gripper Close gripper
RT Open gripper Open gripper

Additional Features

:warning: Safety Warnings

Contributing & Feedback

Feel free to try it out and share your feedback! Issues and pull requests are welcome on the GitHub repository.

Has anyone else worked on similar gamepad teleoperation projects? Would love to hear about your experiences!

Cheers! :robot:

2 posts - 2 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/gamepad-teleoperation-for-robotic-arm-a-new-intuitive-control-experience/50664

ROS Discourse General: Announcing rosetta: a ROS 2 ⇄ LeRobot bridge

Announcing rosetta: a ROS 2 ⇄ LeRobot bridge

LeRobot is great for experimenting with state-of-the-art policies and sharing datasets/pretrained models. But actually using or fine-tuning those models on ROS 2 robots isn’t easy.

I’m working on rosetta, a ROS 2 package that helps LeRobot models play nicely with ROS 2 robots.

What’s inside

A simple example to start

I’ve posted a TurtleBot3 demo dataset (53 short episodes) and a lightweight ACT checkpoint trained on that data for a couple hours on a laptop. It’s far from a great dataset (I crash during training in places and kept the episode count modest), but it should help you get going—then swap in your robot by editing the contract and start iterating.

What’s next

I’ve got a backlog I’m actively working through:

I’d love feedback

Thanks for taking a look!

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/announcing-rosetta-a-ros-2-lerobot-bridge/50657

ROS Discourse General: Extending meta-ros with ros2 + openembedded (yocto)

Hey all,

not sure if this is the right place for it or if I should jump over to discord. We have our own ros2 workspace extending kilted that we’d like to include in our yocto image. Is there a preferred way for creating the receipes - and if so how? After a bit of looking around it seems there’s superflore but I’m not sure if it is intended for use outside of meta-ros.
It seems like the other option is to manually create the receipes for each package in our workspace based off the autogenerated ones?
Is there a third option I am missing?

Thanks in advance,
Nico

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/extending-meta-ros-with-ros2-openembedded-yocto/50650

ROS Discourse General: Announcing GitHub syntax highlighting for ROS msg files

Hi folks – wanted to share that msg/srv/action files are now highlighted with pretty colors on GitHub! :tada::rainbow: This works via a new ROS tmLanguage grammar that I added to GitHub Linguist.

For example, Imu.msg now looks like this:

image

You can also get highlighting in multi-line code blocks by tagging them with ```rosmsg.

The same syntax highlighting support is also available for Visual Studio Code via the Robotics Development Extensions maintained by @ooeygui.

Enjoy! I hope this makes your life just a little bit easier :smiling_face:

6 posts - 4 participants

Read full topic

[WWW] https://discourse.openrobotics.org/t/announcing-github-syntax-highlighting-for-ros-msg-files/50642

ROS Discourse General: Come Join Me At ROSCon 2025 in Singapore

Can’t wait to see you all at ROSCon 2025 in Singapore! :waving_hand:

I’ll be there with my NVIDIA colleagues, and we’re excited to connect with you at our workshops and talks—an awesome chance to learn directly from the experts.

:date: Here are some talks you won’t want to miss:

Monday, October 27th - 8am-12pm SST: Scalable Multi-Robot Scene Workflows Using ROS Simulation Interfaces Standard in Isaac Sim

The new ROS Simulation Interfaces standard (developed in collaboration with O3DE, NVIDIA Isaac Sim, and Gazebo) provides a unified approach to interacting with simulation environments, regardless of the engine used. This workshop highlights the practical implementation of Simulation Interfaces within NVIDIA Isaac Sim and will showcase how this standard facilitates multi robot scene generation, deployment and environmental manipulation, in a reproducible manner suited for automated testing. Isaac Sim’s support offers photorealistic simulation and is GPU-accelerated. By harnessing the capabilities of the new Simulation Interfaces standard, researchers and developers in perception, navigation, and manipulation can benefit by quickly building workflows, switching between simulators, or using multiple simulators in parallel.

Monday, October 27th - 12:30pm-1:30pm SST: Evolving ROS 2 for Real-Time Control of Learned Policy-Driven Robots

Advancing the state of the art in robotics today requires tackling the challenges of physical AI. For humanoids, this requires running computationally intensive AI models with extensive sets of sensors and actuators all with the strictest demands of real-time performance. There is a clear opportunity for a collaborative effort to grow ROS 2 as the ideal platform and ecosystem for enabling embodied AI agents. This talk will explore a vision for enhancing the ROS 2 core to become accelerator-aware yet accelerator-agnostic, where accelerated compute becomes a first-class partner in learned, real-time control. We will discuss open, vendor-neutral strategies for this integration, aiming to provide the entire community with a more powerful and reliable foundation for developing and deploying intelligent robots.

Tuesday, October 28th - 11:10am SST: On Use of Nav2 Route Server

We introduce Nav2’s newest server, Nav2 Route. It performs sparse route graph-based planning and progress tracking to enable routing across massive regions in real-time, enforcing deterministic execution, and/or performing operations throughout task execution leveraging arbitrary graph-defined metadata. This fills a broad need in the community for production capabilities in indoor logistics, massive outdoor spaces, and placing limits on navigable regions. This package uses several unique plugin interfaces to allow use-case specific behaviors to create bespoke applications easily. This talk will go over the key points of the server, demonstrations, and how to enable it in user applications.

Tuesday, October 28th - 15:50-16:00 SST: SWAGGER: Sparse Waypoint Graph Generation for Efficient Routing

SWAGGER (Sparse WAypoint Graph Generation for Efficient Routing) automatically generates sparse waypoint graphs from occupancy grid maps, enabling efficient path planning through pre-computed connectivity.

image

Using a multi-stage approach combining skeleton extraction and strategic node placement, SWAGGER creates optimized graphs that reduce computational complexity from O(n²) grid-based search to O(k²) graph search where k << n. Beyond single-robot navigation, these sparse graphs enable efficient large-scale multi-robot planning. We demonstrate practical integration as a drop-in ROS 2 Nav2 global planner plugin and show how the same graphs can guide neural navigation systems like NVIDIA’s COMPASS. This lightning talk will present the core algorithm, showcase integration patterns, and provide actionable insights for immediate adoption in existing ROS 2 navigation stacks.

Wednesday, October 29th - 17:00-17:10 SST: Building Foundation Models for Generalist Robots: Insights and Challenges in Robot Learning

This session focuses on the recent advancements in robot learning, specifically the development of foundation models for general-purpose robots. Key areas will be explored, including imitation learning, reinforcement learning, and vision-language-action (VLA) models. A highlight will be our NVIDIA’s GR00T with open-source VLA models. We will discuss the research work, infrastructure, ROS implementation, and challenges encountered in the domain. Finally, we will discuss the future of robotics enhanced by learning-based systems.

Wednesday, October 29th - 17:00-17:20 SST: Introducing the New ROS Simulation Standard

This talk brings forward simulation interfaces package, a new standard for ROS, and its implementation in popular simulators. There are multiple simulators with ROS integrations. Each has unique strengths; none is best for everyone. Still, the way they are used is often very similar. The new standard makes it easier to build integrations, switch between simulators, or even use multiple simulators in parallel. You will learn how to use its highly useful features such as spawning robots and other objects, moving things around for testing, stepping through simulation, and querying the virtual world for ground truth data.

Looking forward to connecting at ROSCon. Hope to see you there!

To learn more about NVIDIA at ROSCon go here > https://www.nvidia.com/en-us/events/roscon/

Full ROSCon Singapore details here :right_arrow: ROSCon 2025

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/come-join-me-at-roscon-2025-in-singapore/50637

ROS Discourse General: ManyMove v0.2.0 - Setup with Docker container and unified main branch

Hi!
I just created a new branch main for ManyMove: this represents a unified codebase that compiles on both Humble and Jazzy while retaining all previous functionalities.

To make testing ManyMove easier, I also created docker builds that will prepare a container ready to run examples.The most complete container is the one that also sets up xarm_ros2, so you’ll be able to run all examples.

Here’s an even shorter startup than the one in the docs for a quick setup for humble. Change
MANYMOVE_ROS_WS to your desired folder:

export MANYMOVE_ROS_WS=~/workspaces/dev_ws
mkdir -p ${MANYMOVE_ROS_WS}/src
cd ${MANYMOVE_ROS_WS}/src
git clone https://github.com/pastoriomarco/manymove.git -b main
${MANYMOVE_ROS_WS}/src/manymove/manymove_bringup/docker/run_manymove_xarm_container.sh humble

Then, inside the container, for Panda example:

ros2 launch manymove_bringup panda_moveitcpp_fake_cpp_trees.launch.py

Still inside the container, for UFactory dual robot example:

ros2 launch manymove_bringup dual_moveitcpp_fake_app.launch.py

I’m not sure this unified humble/jazzy approach is a good one, but I was investing too much time propagating the development on both branches. At least now I have some simple CI and tests to keep it checked, and I need to update just one branch. The dev branch will be the one where I keep developing, merging to main when the new code is stable and checked.

If anyone finds trouble setting up or running ManyMove let me know!

PS: I mainly tested it in Ubuntu 22.04 and 24.04, but it seems it works on WSL2 on Win11 too, just make sure to install docker following ubuntu instructions, including linux postinstall

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/manymove-v0-2-0-setup-with-docker-container-and-unified-main-branch/50630

ROS Discourse General: Join My Workshop at ROSCon Singapore

Excited to head to Singapore next week for ROSCon!

Join me Monday at 12:30 SST for my workshop:
Evolving ROS 2 for Real-Time Control of Learned Policy-Driven Robots

We’ll explore how ROS 2 can evolve to power the next generation of embodied AI and how we can make it both accelerator aware and accelerator agnostic to drive physical AI forward together.
See you there! :robot:
More about ROSCon Singapore :right_arrow: ROSCon 2025

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/join-my-workshop-at-roscon-singapore/50629

ROS Discourse General: New packages for Humble Hawksbill 2025-10-20

Package Updates for humble

Added Packages [61]:

Updated Packages [475]:

Removed Packages [2]:

Thanks to all ROS maintainers who make packages available to the ROS community. The above list of packages was made possible by the work of the following maintainers:

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/new-packages-for-humble-hawksbill-2025-10-20/50628

ROS Discourse General: RclGo v0.4.1 Release

:rocket: rclgo v0.4.1 Released - ROS 2 Filesystem Logging & CLI Parameter Overrides

I’m excited to announce rclgo v0.4.1, a Go client library for ROS 2 Humble! This release brings two critical features for production robotics deployments.

What’s New

:white_check_mark: ROS 2 Filesystem Logging

rclgo nodes now properly write logs to ~/.ros/log/ with full ROS 2 formatting, matching rclcpp/rclpy behavior:

:white_check_mark: CLI Parameter Overrides

Full support for command-line parameter overrides, a critical feature for dynamic configuration:
ros2 run my_package my_node --ros-args -p camera.fps:=60 -p exposure:=0.05

Why rclgo?

rclgo enables writing ROS 2 nodes in Go, bringing:

Current Feature Support

:white_check_mark: Publisher/Subscriber​:white_check_mark: Services​:white_check_mark: Parameters (declare, get, set, YAML, CLI overrides):white_check_mark: QoS Policies​:white_check_mark: ROS Time & /use_sim_time​:white_check_mark: Named loggers with filesystem output

:construction: Coming soon: Actions, Lifecycle nodes, Multi-threaded executor

Installation

go get github.com/merlindrones/rclgo@v0.4.1

Full documentation and examples: GitHub - MerlinDrones/rclgo: Go bindings for ROS2. Forked from https://github.com/tiiuae/rclgo

Feedback Welcome

This project targets ROS 2 Humble and aims for production-grade parity with rclcpp/rclpy. Feedback, bug reports, and contributions are very welcome!

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/rclgo-v0-4-1-release/50619

ROS Discourse General: SDF2MAP → Generate ROS 2D Maps Directly from GzSim Worlds

SDF2MAP — SDF to Occupancy Map Converter

SDF2MAP is a lightweight desktop tool that converts Gazebo SDF / World files into 2D occupancy grid maps compatible with the ROS navigation stack.

It automates generating .pgm and .yaml maps directly from simulation environments — eliminating the need for manual map creation.

Download & Run:

Get the latest release and instructions from GitHub:

Screenshot from 2025-10-18 20-31-19

Screenshot from 2025-10-18 23-22-50

Screenshot from 2025-10-18 23-22-58

1 post - 1 participant

Read full topic

[WWW] https://discourse.openrobotics.org/t/sdf2map-generate-ros-2d-maps-directly-from-gzsim-worlds/50598

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

5 posts - 4 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

2025-10-25 12:17