If you are a ROS developer/user and you blog about it, ROS wants those contributions on this page ! All you need for that to happen is:

• have an RSS/Atom blog (no Tweeter/Facebook/Google+ posts)
• open a pull request on planet.ros tracker indicating your name and your RSS feed/ATOM url. (You can just edit the file and click "Propose File Change" to open a pull request.)
• make your ROS related posts tagged with any of the following categories: "ROS", "R.O.S.", "ros", "r.o.s."

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

Planet ROS is one of the public faces of ROS and is read by users and potential contributors. The content remains the opinion of the bloggers but Planet ROS reserves the right to remove offensive posts.

Blogs should be related to ROS but that does not mean they should be devoid of personal subjects and opinions : those are encouraged since Planet ROS is a chance to know more about ROS developers.

Posts can be positive and promote ROS, or constructive and describe issues but should not contain useless flaming opinions. We want to keep ROS welcoming :)

ROS covers a wide variety of people and cultures. Profanities, prejudice, lewd comments and content likely to offend are to be avoided. Do not make personal attacks or attacks against other projects on your blog.

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

Hi, I’ve been working on building our software stack using only release mode and not building any packages which are test_depend. The problem I’m having is colcon scoops up all the dependencies no matter how they’re marked in the package.xml. I do not use rosdep as I don’t necessarily trust every dev out there chose wisely when building their package.xml anyways, so I’m trying to do this in a more manual way. I don’t believe I should have to build something like ament_cmake_pep257 if I have no plan to build any tests. I also shouldn’t be installing *-dev debian packages in release builds. E.g. a package I have depends on libglib2.0-dev for building, but only needs libglib2.0-0 at runtime, so the process I want is to build the package in release mode, then create a new image with only the release dependencies, and copy over the install/ space to that new image. Colcon though won’t let me separate out those packages that I don’t want to build, even though they are only <test_depend>. Does anyone else do this or have thoughts?

1 post - 1 participant

Read full topic

Please come and join us for this coming meeting at Wed, Nov 19, 2025 4:00 PM UTC→Wed, Nov 19, 2025 5:00 PM UTC, where we plan to read through the talks from ROSCon 2025 and note down any talks relevant to Logging & Observability, which has been an ongoing topic of research for the group.

Last meeting we had a general catch-up, including reviewing the last few sessions with guest talks and deciding on some meetings to have going forwards. If you’re interested to see 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

Hi!

Thought I would share the news with the community. At Foxglove, we just raised a $40M series B. You can read our announcement here: Robots are eating the world that software could not.

We are looking forward to our continued ROS support and growing together with the community!

2 posts - 2 participants

Read full topic

The next ROS 2 Rust Meeting will be Mon, Nov 10, 2025 2:00 PM UTC

The meeting room will be at https://meet.google.com/rxr-pvcv-hmu

In the unlikely event that the room needs to change, we will update this thread with the new info!

2 posts - 1 participant

Read full topic

I found out intrinsic hosts their own bzlmod registry for ros2 core packages.

Will intrinsic supports ros2 on bazel with bzlmod officially?

2 posts - 2 participants

Read full topic

I’ve just had a very confusing time with a dockerfile

I wonder if it’s related to the cert error I see here

https://packages.ros.org/ros2/ubuntu/pool/main/r/ros-humble-image-transport-plugins/ros-humble-image-transport-plugins_2.5.4-1jammy.20251017.031841_amd64.deb

5 posts - 4 participants

Read full topic

Hello ROS community!

The Space ROS team is excited to announce Space ROS Jazzy 2025.10.0 was released last week and is available as osrf/space-ros:jazzy-2025.10.0 on DockerHub. Additionally, builds Move It 2 and Navigation 2 built on the jazzy-2025.10.0 underlay are also available to accelerate work using these systems as osrf/space-ros-moveit2:jazzy-2025.10.0 on DockerHub and osrf/space-ros-nav2:jazzy-2025.10.0 on DockerHub respectively.

Release details

Beyond the addition of the Moveit and Navigation stacks to DockerHub, this release adds a demo of JAXA’s RACS2 communications bridge by @yuyuqq showing interoperability between Space ROS and NASA’s cFS flight software - check it out in the Demos repository! For an exhaustive list of all the issues addressed and PRs merged, check out the GitHub Project Board for this release here.

Code

Current versions of all packages released with Space ROS are available at:

• GitHub - space-ros/space-ros: The Space ROS meta operating system for space robotics.

• GitHub - space-ros/docker: Docker images to facilitate Docker-based development.

• GitHub - space-ros/demos: Various Space ROS demos.

• GitHub - space-ros/simulation: Simulation assets of space-ros demos

• GitHub - space-ros/process_sarif: Tools to process and aggregate SARIF output from static analysis.

What’s Next

This release comes 3 months after the last release. The next release is planned for January 31, 2026. If you want to contribute to features, tests, demos, or documentation of Space ROS, get involved on the Space ROS GitHub issues and discussion board.

All the best,

The Space ROS Team

1 post - 1 participant

Read full topic

Physical AI requires DNN inference for learned policies, which in turn requires accelerators. Accelerators have their own memory and compute models that need to be surfaced in ROS 2 under abstractions, similar to how tensors are surfaced in PyTorch (accelerator aware, accelerator agnostic). This abstraction would need to be available at all layers of the ROS stack (client libraries, IDL, rmw), be vendor agnostic (CUDA, ROCm, etc.), allow for runtime graphs of heterogeneous accelerators, and enable RMW implementations to handle transport of externally managed memory efficiently. Developers who implement these concepts in their packages should have CPU backwards compatibility when specified accelerators are not available at runtime.

We propose forming a working group with other vendors hosted by the ROS PMC to introduce the concept of externally managed memory and asynchronous compute that enables accelerated graphs into ROS 2 Lyrical. Tensor semantics and DNN inference standards layered on top of what is proposed here would be designed by the Physical AI SIG.

Our design sketch is a more targeted native buffer type that maps to supplied implementations in client libraries, like rclcpp::buffer. This native type only represents a memory handle for a block that could optionally be managed externally.

namespace rclcpp { 
class buffer {
  protected:
    std::unique_ptr<BufferImplBase> impl;
    std::string device_type;
};
}  // namespace rclcpp

The client library interface does not expose its underlying buffer directly, but manages all access through vendored interfaces that add support for particular frameworks or hardware architectures. For example, an implementation for Torch in a hypothetical torch_support library as shown in the example below.

By doing so, buffer is a more fundamental type that is focused on data storage abstraction, while semantics like tensors or image buffers can then be layered on top of it.

# MessageWithTensor.msg
#
# a message containing only a buffer that is to be interpreted as a tensor

buffer tensor

// sample callback that receives a messages containing a 
// buffer, interprets it as a tensor, performs an operation 
// on it, and publishes a new message with the output, with 
// all operations performed in the Torch-chosen accelerator
// backend
void topic_callback(const msg::MessageWithTensor & input_msg) {
    torch::Tensor input_tensor =
        torch_support::from_buffer(input_msg.tensor);

    auto result = input_tensor.some_operation();

    auto output_msg = msg::MessageWithTensor();
    output_msg.tensor = torch_support::to_buffer(result);

    publisher_.publish(output_msg);
}

A default implementation for CPU backed buffers would be provided as part of the base ROS distribution, while system vendors and framework designers would provide implementations for their respective memory types. All custom implementations would always provide support to convert to and from CPU backed buffers, such that compatibility across implementations is guaranteed.

Relevant tensor type discussion can be found in the other post here: Native rcl::tensor type

3 posts - 3 participants

Read full topic

Workshop: Industrial deployment of ROS applications with Siemens ROSie (ROS↔PLC connector)

Hi everyone!

At ROSCon FR+DE 2025 in Strasbourg (Nov 18), together with Florian Gramß (@flo), we’ll host a hands-on workshop on connecting ROS to industrial PLCs using Siemens ROSie:
developer.siemens.com/rosie/overview.html

You’ll get to work with a ROS application talking live to a Siemens PLC and explore practical deployment aspects.
Workshop info

I’ll also present my template app ManyMove, sharing some of the challenges I’ve faced while bringing it toward production.

Would love to see some of you there and hear your experiences with industrial ROS integration!

5 posts - 3 participants

Read full topic

I would like to share an ongoing development of a fiducial marker with recursive feature. The marker would be useful to multi-range applications.

1 post - 1 participant

Read full topic

Hey all! From the announcement in my ROSCon talk “Escape Velocity: How to be good at launch” - here is the launch of the new working group!

If you’re just in it for the slides & launch snippets, you can find them at GitHub - emersonknapp/roscon2025_launch_snippets: Slides and code snippets for ROSCon 2025 presentation "Escape Velocity: Smarter, Cleaner ROS 2 Launch Patterns, a.k.a How to write good launchfiles"

Otherwise if you’re still with me… Come start the conversation about launch, declarative node interfaces, health monitoring, and more - the tooling that will help us reason holistically about ROS applications and their structure.

Initial meeting is next Tuesday, November 11.

If you join the mailing list https://groups.google.com/u/1/g/rosgraph-wg you will receive the calendar invite.

Key links:

• Mailing list (same as above)
• agenda and notes document
• Project board

I’m working on the official processes to put up a charter and get onto shared calendars, but for now we can, as Kat said, “just do things” - let’s get started!

I’ll note that this is the continuation/evolution of “Robograph Project” that I discussed earlier this year Declarative ROS presentation slides & the Robograph project kickoff - just a slightly new framing to continue on the same work.

7 posts - 4 participants

Read full topic

ROS Users and Developers in Asia Pacific region

As I announced at ROSCon 2025 Singapore Lightening Talk, we will have 1st ROS Asia Pacific Developer Meeting on this Friday 7th.Nov Convert Your Time.

ROS_APAC_Developer_Meeting-LT.pdf (3.6 MB)

If you are willing to start the contribution to ROS open source projects, please come and join us

ROS APAC Developer Meeting #1
Friday, November 7 · 17:00 – 17:50 Japan Standard Time
Time zone: Asia/Tokyo Convert Your Time
Google Meet joining info
Video call link: https://meet.google.com/miv-whfs-yjy

Please join https://groups.google.com/g/ros-apac-developer-meeting, so you won’t miss the meeting.

looking forward to e-meeting you all

Best,
Tomoya

1 post - 1 participant

Read full topic

As spoiled at ROSCon Singapore: We have another developer room for Robotics and Simulation at FOSDEM! FOSDEM arguably the largest open source software developer conference in the world (and it’s free!).

It full event takes place on 2026 Jan 31th - Feb 1th (Sat, Jan 31, 2026 8:00 AM UTC→Sun, Feb 1, 2026 5:00 PM UTC) and it is all on the ULB Solbosch Campus, Brussels, Belgium.

Thanks to the success last year, we will have a full day assigned this time, namely on the Saturday (31th). We now have a call for participation open, in which you can find more information about what kind of talks/projects we are looking for! Deadline for proposal submission is 1th of December!

In the true spirit of FOSDEM, everyone is welcome from any robotics community working in open source. Of course, we would love many of the ROS community to join this time as well, as many of you showed up for the last year edition!

Here is some pictures of last year:

If you want inspiration you check out the recorded talks of last year. Make sure that it needs to be about an open source work, preferably project based, and focus on the sharing of knowledge.

Also make sure that you see any other interesting accepted devrooms you’d like to attend during the event! We will be doing the same ourselves on Sunday, being fueled on club mate.

See you in Brussels!

Arnaud, Mat, Fred, Lucas and Kim

2 posts - 2 participants

Read full topic

I have a repo and YouTube demo of NAV2 running on a real robot.

This will not interest experienced NAV2 users. Also if you are interested in NAV2 in simulation there are better tutorials for this out there.

This is aimed at home hobbyists, who have got their mobile robot working under manual control (e.g. ROS2 Control), but may have struggled to get NAV2 working well. That was me!

YouTube link: https://youtu.be/xmR9_JrH2SY

Repo link: GitHub - jfrancis71/ros2_nav2_demo: Demonstration of how to use the ROS2 Nav2 stack for navigation

Hope this is of interest to some…

Julian.

1 post - 1 participant

Read full topic

New ROS 2 Features - Mini Pupper 2

Hello everyone,

I’m Kishan Grewal, a Robotics and AI student at University College London (UCL). Over the summer, I interned at MangDang in Hong Kong, where I extended the ROS 2 software stack for the Mini Pupper 2 quadruped robot.

My work broadened the Mini Pupper 2’s ROS 2 ecosystem with additional packages that work across different hardware configurations. Depending on your setup, you can now explore person tracking, autonomous navigation, or multi-robot coordination - all through ROS 2.

Vision-Based Tracking

I developed a tracking node that performs real-time person detection and tracking using a YOLO11n ONNX model with multi-object detection and IMU feedback for stable control.

If you have a Mini Pupper 2 with a compatible Pi camera, this package lets the robot visually follow a person while maintaining orientation. The system includes a lightweight Flask web interface and RViz visualization.

Demo - Vision Tracking

Code - mini_pupper_tracking package

Multi-Robot Fleet Coordination

I created a fleet package that uses ROS 2 namespacing and synchronised state estimation to enable cooperative motion, shared heading control, and distributed communication.

So if you have access to multiple Mini Pupper 2 robots, try out coordinated multi-robot teleoperation.

Demo - Fleet Coordination

Code - mini_pupper_fleet package

Navigation and SLAM

If you’ve fitted your Mini Pupper 2 with a LiDAR sensor, the navigation stack now allows you to use SLAM Toolbox and Nav2 to perform reliable map-based localization and path planning. The configuration is currently tuned for table-area navigation but can be altered for other environments.

This setup enables a Mini Pupper 2 with LiDAR to perform autonomous indoor navigation and mapping.

Demo - Navigation and SLAM

Code - mini_pupper_navigation package

All of these developments have been pushed upstream to the MangDang Robotics Club ROS repository and are available for anyone to explore with their own Mini Pupper 2.

I’d be happy to discuss implementation details or hear from others experimenting with ROS 2 on small quadruped platforms.

Best regards,

Kishan Grewal

GitHub | LinkedIn

5 posts - 3 participants

Read full topic

Hello fellow ROS 2 users,

I wanted to use asyncio with ROS 2 for a while, but didn’t find anything good enough. So I made a library: asyncio_for_robotics: https://github.com/2lian/asyncio-for-robotics

I am looking for feedback from the community, especially as this is my first release . What would you like to see? What is missing? What do you find confusing? What should I put forward?

VVV About the project VVV

Why asyncio?

• Asyncio (native python) syntax is easier, with extensive support and documentation.
• My lab sees many short term students, enable to grasp the Future/Callback and executor of ROS 2.
  • I am very used to it, but what is it the point if the people I code with never understand it?
• We work on multi-robots coordination and synchronization.
  • The ROS 2 syntax becomes bloated and unreadable fast.
  • I for example need to wait for a set of robots (or motors) to reach their target, adding a timeout on top of that.
• Asyncio does not have dependencies, is usable with other communication systems. So I can for example, ask a team to process images using RTSP transport (no ROS code), while I work with ROS transport, and we can merge our work.

Other solutions

I’ve seen several discussions, and people asking for asyncio+ROS 2. Many good solution have been proposed! However, I feel none was polished and reliable enough, usually they increase the barrier of entry instead of lowering it:

• ros2-asyncio: Fantastic read.. This is similar to this solution
• ros2_asyncio: This solution is very good, but necessitates calling executor.create_task(...) and the code is executed by the ros executor not asyncio. I have actually used this one a lot.
• rclpy_async: Incredible work! However it replaces the ROS node, instead of interfacing with one. I want to be able to call Node.get_parameters() and such, just like normal ros. It is also missing the Publisher and Service Server.

How asyncio_for_robotics works? What’s different?

I spin the ROS node in a background thread (similarly to rclpy_async). The user can directly provide a – possibly custom – node to spin in the background, and the user can still interact with the node object – it is just a standard ros node.

This background node sends data onto the main asyncio thread. I provide the user with only a subscription object that exposes several ways to wait for data: wait for data, wait for new data, wait for next data, async for loop to process all data. This object exposes the data stream of ROS objects: Timer, Subscriber, Service Server (Action Server is not implemented yet). On the other hand, Publisher doesn’t need to be implemented, because the user can directly use the node to create one. Service Client has a very small implementation returning an asyncio future of the call.

Finally, it is named asyncio_for_robotics because it can be used with other transport protocol (like zenoh), if you make an interface for it – there’s a quick tutorial on how to do that.

3 posts - 2 participants

Read full topic

Please come and join us for this coming meeting at Wed, Nov 5, 2025 4:00 PM UTC→Wed, Nov 5, 2025 5:00 PM UTC, where we will have a general catch-up, including reviewing the last few sessions with guest talks and how they contribute to our overall goal of building a Logging & Observability community guide.

Last meeting,Sergi Grau-Moya, Co-founder and CEO of INSAION, and Victor Massagué Respall, Co-founder and CTO of INSAION, presented the INSAION platform to the group. This platform is an observability platform for your robot fleet, allowing users to optimise robot operations and explore advanced robot diagnostics. It also has some very impressive visualisations! If you’re interested to see 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

ROSCon 2025 Live Stream is up!

The ROSCon 2025 Live Stream is up!

We’ve got two channels, one for each session.

• Primary Stream
• Secondary Stream

You can follow the schedule here.

3 posts - 2 participants

Read full topic

We’re excited to announce the latest official release of rclrs, right on time for ROSCon ‘25 in Singapore! This new release includes support for two long awaited features: timers and actions!

And not only that, but the Rust code generator is now one of the core generators in Rolling rosidl_core/rosidl_core_generators/package.xml at rolling · ros2/rosidl_core · GitHub

Join us on our Matrix channel if you want to talk about the future of Rust in ROS

I’ll be giving a talk about the ros2-rust project at ROSCon, if your’re around, come say hi!

This release has been possible thanks to the work of these amazing people:

• Agustin Alba Chicar
• Esteve Fernández
• Jesús Silva
• Kimberly N. McGuire
• Michael X. Grey
• Nathan Wiebe Neufeldt
• Sam Privett

1 post - 1 participant

Read full topic

Have you ever run colcon graph --dot | dot -Tpng -o graph.png, waited a few minutes, and looked at unhelpful pngs?

Have you ever asked thought-provoking questions like:

• What package is depended on the most?
• Who maintains the most packages in this workspace?
• What is the predominant language used in this workspace?

Introducing: colcon_gephi

A colcon plugin to generate rich dependency graphs for a ROS 2 workspace that are compatible with graph visualization tools!

Below is an example graph of the workspace for the ros2 rolling repos. For details on what the graph actually is showing, see Example Graph Details.

Features

Currently supports exporting in:

• DOT (default, for Graphviz and other generic graph tools)
• GML (human-readable text format, supported by many graph libraries)
• GEXF (ideal for Gephi, preserves complex attributes)

Unlike colcon graph, this extension preserves extra package metadata (e.g., maintainers, repository info, build type) as node attributes. This makes it easier to analyze dependency relationships visually in Gephi.

• Generates a graph file from your ROS 2 workspace using the same package descriptors as colcon graph.
• Automatically includes the following as node attributes:
  • Package path
  • Build type
  • Maintainers
  • Version
  • Git repository name and remote URL (if applicable)
  • Lines of Code (LOC) stats (see Optional Dependencies)
• Includes edges for build, run, and test dependencies between packages in the workspace.
• Produces output ready to open in Gephi — no manual attribute editing required.

Usage

cd ros2_rolling/ 
colcon gephi_graph

The generated .dot file will have the name of the directory the command was run in. So in this case, it is ros2_rolling.dot.

To change the file format, pass the --format flag.

colcon gephi_graph --format gml

Notes

Graph Visualization Tools

As you can probably guess based on the plugin name, I primarily use Gephi as my graph visualization tool of choice. However, there are more out there which might work with some of the supported output formats. Cytoscape and Argo Lite are two examples although I do not test with these.

Example Graph Details

The graph generated at the top of this post was laid out by following this video. Larger nodes are nodes with more “in-degree” edges (i.e. edges pointing into them), which gives a visual representation of how many packages depend on them. Finally, the colors are based on the package build_type (i.e. ros.ament_cmake, ros.ament_python, etc).

1 post - 1 participant

Read full topic

I’m new to the world of robotics, and I’ve been learning ROS2 for a while. I really enjoy it, but to be honest — I’m very confused right now about how to move forward and how to start building real projects.

I’ve studied the basics of ROS2, URDF, and simulation (Gazebo), but I feel stuck when it comes to applying what I’ve learned to something practical.

I’m looking for a mentor — someone with real experience in robotics and ROS2 — who can guide me, help me gain confidence, and point me in the right direction for building real applications.

If you’re open to sharing advice or mentoring someone who’s eager to learn and work hard, I’d be really grateful to connect with you

Thank you in advance for any guidance or suggestions!

3 posts - 2 participants

Read full topic

Hey everyone,

I wanted to share my new LiDAR-Inertial Odometry system, RKO-LIO:

Below is an example of the results on data from different platforms and environments.

One of the main goals was to make the odometry run with little to no configuration, out of the box. The only real requirement for the system is the extrinsic calibration between the IMU and LiDAR. If that’s available, the defaults should just work. If tuning is needed, the parameters are straightforward and their number minimal.

Supported ROS distros: Humble, Jazzy, Kilted, and Rolling.
The package is already released, so you can simply install it with:

sudo apt install ros-${ROS_DISTRO}-rko-lio
ros2 launch rko_lio odometry.launch.py

For a quick test, there’s also a Python interface you can install via pip (no ROS setup needed)

pip install rko_lio rosbags rerun-sdk
rko_lio -v /path/to/your/rosbag

If your bag includes a TF tree, the extrinsics will be automatically extracted.

Documentation is also available and being updated over time, at

Note that the docs there may trail a few days behind the main repo (as and when the ROS build farm runs the doc job).

I’d really appreciate it if the community could try it out, and share any feedback.

Best,
Meher

1 post - 1 participant

Read full topic

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

2 posts - 2 participants

Read full topic

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:

• 10:00: Deployment & Launch Tooling, by Emerson Knapp

• 15:00: Tools for Environment Isolation, by Nathan Brooks

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!

10 posts - 8 participants

Read full topic

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

• Function calls instead of macros: logger.info("Hello, {}!", name) instead of RCLCPP_INFO(logger, "Hello, %s", name.c_str())
• Additional .on_change() method for logging changes in values
• chrono syntax for throttling: logger.warn_throttle(1s, "Warning: {}", value)
• backwards compatible with the macros, so easy to start using in existing projects without a full rewrite of the current log statements

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

• Why not use std::format?
  • fmt is still more powerful, like when printing ranges. Also rclcpp already depends on it indirectly, so it’s kind of free.
• Isn’t this why we have _STREAM macros?
  • Yes, but it’s longer

    double progress = 0.756;
    logger.info("Progress: {:.1} %", progress);
    RCLCPP_INFO_STREAM(logger, "Progress: " << std::setprecision(1) << progress << " %");
    

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

3 posts - 2 participants

Read full topic