December 04, 2023
:snowman: Holiday ROS By-The-Bay

:snowman_with_snow: Holiday ROS By-The-Bay :gift:

Hi Everyone,

I’ve put together a holiday ROS By-The-Bay Meetup for 2023-12-15T02:00:00Z UTC2023-12-15T05:00:00Z UTC

The event will be at the Intrinsic offices in Mountain View. I’ve asked @chfritz to come and speak, and I will be giving a quick ROSCon Recap for those who couldn’t make it. I am thinking we might also take a quick holiday photo to send to our colleagues at ROSCon India. If you have any tacky holiday sweaters or Santa hats please do wear them. If you would like to make a brief announcement at the event please reach out.

Make sure to invite your friends!

Full details are on the ROS By-The-Bay Meetup page.

image

1 post - 1 participant

Read full topic

by Katherine_Scott on December 04, 2023 11:12 PM

ImpROSter Syndrome

When I was just starting out with ROS and trying to get the robot to navigate, there are two things I wish I knew:

  • ROS is not perfect
  • You might be the right person to fix it

To some in this community, the idea that ROS is not perfect is glaringly obvious (as many Discourse threads will attest). With a community of this size though, and so many people using the code, the core repos get an air of legitimacy for beginners. When I first started with ROS, I spent a lot of time reading the nav stack source code, and I came to a false conclusion: If a package isn’t doing what I want, it’s because I don’t understand it. The authors must have had a good reason for making it this way.

I had this grand notion that Willow Garage (the company behind the origins of ROS) handed down this perfect code from on high. Robot navigation was completed and perfected at a Menlo Park utopia, and I was at fault for not understanding what they were trying to do.

The “secret” is that ROS, for all of its strengths, is a big pile of “good enough” code.* The nav code I was looking at was good enough for a particular robot to do a particular task, but the fact that it couldn’t handle what I was trying to do was an oversight from the original developers, not my own understanding. It took me a long time to understand this.

ROS is made by people. And there are always compromises. There could be a dozen reasons why the code isn’t what you want it to be.

  • Written by a software engineer with limited access to a real robot
  • Written by a robotics scientist who prioritized mathematical correctness over software maintainability
  • The code was written by someone at a company that had a particular use case
  • Designed before the advent of some piece of technology.
  • It was written by an expert robotics software engineer for your use case, but with extremely limited time to get it merged.

(And yes, many of those people work at big fancy companies, but those companies also have complex/conflicting priorities that result in compromises of their own)

Even if the code wasn’t perfect, I still had this belief that the people who wrote it were “real roboticists.” I mean, I started grad school thinking I was going to do computational genetics, who was I to try to improve this code? There can also be dozens of reasons why you believe you’re not the right person to fix it. Maybe you didn’t go to Stanford or Carnegie Mellon. Maybe you’re not in the Bay Area or another robotics hub. Maybe you haven’t even been in the field that long. And maybe when you do get your chance to work at one of the big companies, it doesn’t work out the way you expect it to.

The phenomenon of Imposter Syndrome is not exclusive to the open source robotics landscape, but I feel it is worth bringing up at this time in our community because it’s still easy to feel like there are two tiers to the ROS Community: the insiders and the outsiders. The insiders are giving ROS talks, getting elected to committees, and have fancy titles at impressive companies. Everyone else is on the outside, just trying to get their code to work and hoping for the best. But if you put in the time and work, there is no real division. It’s all just folks.**

I cannot speak for everyone. I can say this: I’m grateful to have been elected a representative of this community. I’m grateful to be the maintainer on a number of packages. However, I have stood where many of you are now: a confused grad student just trying to get a demo to work for a paper, the new member of a small software team at a startup, or the person just trying to get their one friggin PR merged. How to progress from there can take many paths, but I offer the following advice.

  • Start off humble. (Not to be confused with ROS 2 Humble). Give the code authors the benefit of the doubt, and try to understand why things are written the way they are before rushing in to change things.
  • Identify your unique voice. It can be helpful that you’re not like every bro in Silicon Valley. Your perspective can help expand the functionality beyond what the original authors ever dreamed.***
  • Do not fear going your own way. If package X is not working for you, feel free to swap it out with something else. Develop your own stack for solving the problem. Then you can come back to package X with a concrete alternative approach and possibly work on integrating.
  • Acknowledge the shoulders you’re standing on. When you come out with a new feature/package, the tendency is to go full Apple Keynote and hype it up by overstating its features and diminishing what came before. However, if you acknowledge the strengths of the prior work and admit the shortcomings of the new, that makes it that much easier for the next person to come along and build on your work. It’s not binary.
  • Be kind.

We, all of us, can change this community. We, all of us, can make it better. We, all of us, have something to contribute.




*This is arguably true of all software, except maybe Roller Coaster Tycoon.

**That’s not to say there aren’t real divisions between different groups. However, I’m going to save my thoughts on the balance between maintainers and contributors and maintainer burnout for another day.

***It is also worth noting that identifying the uniqueness of your situation can also help to find ways to be humble. You’ll get a lot further when you say “this package won’t compile” when you acknowledge that most people compile on Ubuntu and note that you’re trying to compile it on a Windows 98 web browser.

****For a long time, I believed that I couldn’t get great things done until I got to one of those utopian perfect environments. It took years of therapy and at least one great musical theatre song to make me realize that the answer to “When/Where is it best to solve this problem” is now and here.

2 posts - 2 participants

Read full topic

by DLu on December 04, 2023 08:39 PM

New Packages for Iron Irwini 2023-12-04

We’re happy to announce 32 new packages and 75 updates are now available in ROS 2 Iron Irwini :iron: :irwini: . This sync was tagged as iron/2023-12-04 .

Package Updates for iron

Added Packages [32]:

  • ros-iron-etsi-its-primitives-conversion: 1.0.0-1
  • ros-iron-event-camera-renderer: 1.2.2-1
  • ros-iron-event-camera-renderer-dbgsym: 1.2.2-1
  • ros-iron-gazebo-video-monitor-interfaces: 0.8.1-1
  • ros-iron-gazebo-video-monitor-interfaces-dbgsym: 0.8.1-1
  • ros-iron-gazebo-video-monitor-plugins: 0.8.1-1
  • ros-iron-gazebo-video-monitor-plugins-dbgsym: 0.8.1-1
  • ros-iron-gazebo-video-monitor-utils: 0.8.1-1
  • ros-iron-gazebo-video-monitors: 0.8.1-1
  • ros-iron-kinematics-interface-dbgsym: 1.0.0-1
  • ros-iron-leo-bringup: 1.4.0-1
  • ros-iron-leo-fw: 1.4.0-1
  • ros-iron-leo-fw-dbgsym: 1.4.0-1
  • ros-iron-leo-robot: 1.4.0-1
  • ros-iron-metavision-driver: 1.2.8-1
  • ros-iron-metavision-driver-dbgsym: 1.2.8-1
  • ros-iron-nao-meshes: 2.1.1-1
  • ros-iron-naoqi-bridge-msgs: 2.1.0-1
  • ros-iron-naoqi-bridge-msgs-dbgsym: 2.1.0-1
  • ros-iron-naoqi-driver: 2.1.0-1
  • ros-iron-naoqi-driver-dbgsym: 2.1.0-1
  • ros-iron-naoqi-libqi: 3.0.2-1
  • ros-iron-naoqi-libqi-dbgsym: 3.0.2-1
  • ros-iron-naoqi-libqicore: 3.0.0-1
  • ros-iron-pepper-meshes: 3.0.0-1
  • ros-iron-sick-safevisionary-base: 1.0.1-1
  • ros-iron-sick-safevisionary-base-dbgsym: 1.0.1-1
  • ros-iron-sick-safevisionary-driver: 1.0.3-1
  • ros-iron-sick-safevisionary-driver-dbgsym: 1.0.3-1
  • ros-iron-sick-safevisionary-interfaces: 1.0.3-1
  • ros-iron-sick-safevisionary-interfaces-dbgsym: 1.0.3-1
  • ros-iron-sick-safevisionary-tests: 1.0.3-1

Updated Packages [75]:

  • ros-iron-ackermann-steering-controller: 3.17.0-1 → 3.18.0-1
  • ros-iron-ackermann-steering-controller-dbgsym: 3.17.0-1 → 3.18.0-1
  • ros-iron-admittance-controller: 3.17.0-1 → 3.18.0-1
  • ros-iron-admittance-controller-dbgsym: 3.17.0-1 → 3.18.0-1
  • ros-iron-behaviortree-cpp: 4.4.0-1 → 4.4.2-1
  • ros-iron-behaviortree-cpp-dbgsym: 4.4.0-1 → 4.4.2-1
  • ros-iron-bicycle-steering-controller: 3.17.0-1 → 3.18.0-1
  • ros-iron-bicycle-steering-controller-dbgsym: 3.17.0-1 → 3.18.0-1
  • ros-iron-controller-interface: 3.21.0-1 → 3.21.1-1
  • ros-iron-controller-interface-dbgsym: 3.21.0-1 → 3.21.1-1
  • ros-iron-controller-manager: 3.21.0-1 → 3.21.1-1
  • ros-iron-controller-manager-dbgsym: 3.21.0-1 → 3.21.1-1
  • ros-iron-controller-manager-msgs: 3.21.0-1 → 3.21.1-1
  • ros-iron-controller-manager-msgs-dbgsym: 3.21.0-1 → 3.21.1-1
  • ros-iron-depthai: 2.22.0-1 → 2.23.0-1
  • ros-iron-depthai-dbgsym: 2.22.0-1 → 2.23.0-1
  • ros-iron-diff-drive-controller: 3.17.0-1 → 3.18.0-1
  • ros-iron-diff-drive-controller-dbgsym: 3.17.0-1 → 3.18.0-1
  • ros-iron-effort-controllers: 3.17.0-1 → 3.18.0-1
  • ros-iron-effort-controllers-dbgsym: 3.17.0-1 → 3.18.0-1
  • ros-iron-force-torque-sensor-broadcaster: 3.17.0-1 → 3.18.0-1
  • ros-iron-force-torque-sensor-broadcaster-dbgsym: 3.17.0-1 → 3.18.0-1
  • ros-iron-forward-command-controller: 3.17.0-1 → 3.18.0-1
  • ros-iron-forward-command-controller-dbgsym: 3.17.0-1 → 3.18.0-1
  • ros-iron-gripper-controllers: 3.17.0-1 → 3.18.0-1
  • ros-iron-gripper-controllers-dbgsym: 3.17.0-1 → 3.18.0-1
  • ros-iron-hardware-interface: 3.21.0-1 → 3.21.1-1
  • ros-iron-hardware-interface-dbgsym: 3.21.0-1 → 3.21.1-1
  • ros-iron-imu-sensor-broadcaster: 3.17.0-1 → 3.18.0-1
  • ros-iron-imu-sensor-broadcaster-dbgsym: 3.17.0-1 → 3.18.0-1
  • ros-iron-joint-limits: 3.21.0-1 → 3.21.1-1
  • ros-iron-joint-state-broadcaster: 3.17.0-1 → 3.18.0-1
  • ros-iron-joint-state-broadcaster-dbgsym: 3.17.0-1 → 3.18.0-1
  • ros-iron-joint-trajectory-controller: 3.17.0-1 → 3.18.0-1
  • ros-iron-joint-trajectory-controller-dbgsym: 3.17.0-1 → 3.18.0-1
  • ros-iron-kinematics-interface: 0.1.0-3 → 1.0.0-1
  • ros-iron-kinematics-interface-kdl: 0.1.0-3 → 1.0.0-1
  • ros-iron-kinematics-interface-kdl-dbgsym: 0.1.0-3 → 1.0.0-1
  • ros-iron-magic-enum: 0.9.3-1 → 0.9.5-1
  • ros-iron-mrpt2: 2.11.2-1 → 2.11.3-1
  • ros-iron-mrpt2-dbgsym: 2.11.2-1 → 2.11.3-1
  • ros-iron-plotjuggler: 3.7.1-1 → 3.8.0-1
  • ros-iron-plotjuggler-dbgsym: 3.7.1-1 → 3.8.0-1
  • ros-iron-position-controllers: 3.17.0-1 → 3.18.0-1
  • ros-iron-position-controllers-dbgsym: 3.17.0-1 → 3.18.0-1
  • ros-iron-range-sensor-broadcaster: 3.17.0-1 → 3.18.0-1
  • ros-iron-range-sensor-broadcaster-dbgsym: 3.17.0-1 → 3.18.0-1
  • ros-iron-robot-calibration: 0.8.0-3 → 0.8.1-1
  • ros-iron-robot-calibration-dbgsym: 0.8.0-3 → 0.8.1-1
  • ros-iron-robot-calibration-msgs: 0.8.0-3 → 0.8.1-1
  • ros-iron-robot-calibration-msgs-dbgsym: 0.8.0-3 → 0.8.1-1
  • ros-iron-ros2-control: 3.21.0-1 → 3.21.1-1
  • ros-iron-ros2-control-test-assets: 3.21.0-1 → 3.21.1-1
  • ros-iron-ros2-controllers: 3.17.0-1 → 3.18.0-1
  • ros-iron-ros2-controllers-test-nodes: 3.17.0-1 → 3.18.0-1
  • ros-iron-ros2controlcli: 3.21.0-1 → 3.21.1-1
  • ros-iron-rqt-controller-manager: 3.21.0-1 → 3.21.1-1
  • ros-iron-rqt-joint-trajectory-controller: 3.17.0-1 → 3.18.0-1
  • ros-iron-septentrio-gnss-driver: 1.3.1-3 → 1.3.2-1
  • ros-iron-septentrio-gnss-driver-dbgsym: 1.3.1-3 → 1.3.2-1
  • ros-iron-simple-launch: 1.7.2-1 → 1.9.0-1
  • ros-iron-steering-controllers-library: 3.17.0-1 → 3.18.0-1
  • ros-iron-steering-controllers-library-dbgsym: 3.17.0-1 → 3.18.0-1
  • ros-iron-topic-tools: 1.0.0-3 → 1.2.0-1
  • ros-iron-topic-tools-dbgsym: 1.0.0-3 → 1.2.0-1
  • ros-iron-topic-tools-interfaces: 1.0.0-3 → 1.2.0-1
  • ros-iron-topic-tools-interfaces-dbgsym: 1.0.0-3 → 1.2.0-1
  • ros-iron-transmission-interface: 3.21.0-1 → 3.21.1-1
  • ros-iron-transmission-interface-dbgsym: 3.21.0-1 → 3.21.1-1
  • ros-iron-tricycle-controller: 3.17.0-1 → 3.18.0-1
  • ros-iron-tricycle-controller-dbgsym: 3.17.0-1 → 3.18.0-1
  • ros-iron-tricycle-steering-controller: 3.17.0-1 → 3.18.0-1
  • ros-iron-tricycle-steering-controller-dbgsym: 3.17.0-1 → 3.18.0-1
  • ros-iron-velocity-controllers: 3.17.0-1 → 3.18.0-1
  • ros-iron-velocity-controllers-dbgsym: 3.17.0-1 → 3.18.0-1

Removed Packages [0]:

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:

  • Bence Magyar
  • Bernd Pfrommer
  • Davide Faconti
  • Denis Štogl
  • Emerson Knapp
  • Fictionlab
  • Jean-Pierre Busch
  • Jose-Luis Blanco-Claraco
  • Marvin Grosse Besselmann
  • Michael Ferguson
  • Neargye
  • Nick Lamprianidis
  • Olivier Kermorgant
  • Sachin Guruswamy
  • Tibor Dome
  • Victor Paleologue
  • Victor Paléologue

1 post - 1 participant

Read full topic

by Yadunund on December 04, 2023 03:47 AM

December 01, 2023
ROS News for the Week of November 27th, 2023

ROS News for the Week of November 27th, 2023


These past two weeks we had two ROS Meetups in Europe (Netherlands and Barcelona), one in Singapore, and a sold out ROSCon in Germany!

Our first ever ROSCon India is just two weeks away! I am informed it is already sold out!

If you want hold a ROSCon in your city or country just reach out to us at the email address community [at] openrobotics.org and we can help make it happen (we’re looking at you, South America, Australia, and Africa)!



This Tuesday was what we in the states calls “Giving Tuesday,” the day after “Black Friday,” “Small Business Saturday,” and “Cyber Monday.” If you would like to make a donation to the Open Source Robotics Foundation there is a form available here.


cover (1)

I came across this fantastic resource this week, “The Connector Book” by Davide Andrea. If you have ever struggled to pick a connector for your robot, or identify a connector for your robot this is the resource for you. The book also has a web form that lets you search for a particular connector or pick the best connector for an application.


a6
This week I came across this Unreal 5 plugin that lets you import a Gaussian Splat. Not to be outdone the fine folks at Spectacular.AI demonstrated a NeRF generator for the OAK-D depth sensor.

I’ve been saying for awhile that all I want is an open source ROS 2 package that generates NeRFs / Gaussian splats and a Gazebo pipeline that allows you to import the resulting NeRF/Splat. I want to drive a robot around a room with ROS, generate a NeRF / Splat, and then simulate the robot inside of the NeRF/Splat using Gazebo. This is the killer app and all I want for Christmas :gift:. Unfortunately I do not have time to make it happen, but I will shower you with ROS swag if you make this happen :wink:.

Events

News

ROS

ROS Questions

Got a minute to spare? Make the holidays brighter for your friends and colleagues, answer a few questions on Robotics Stack Exchange.

1 post - 1 participant

Read full topic

by Katherine_Scott on December 01, 2023 05:57 PM

November 29, 2023
Interoperability Interest Group December 11th, 2023: Advantages of Rust for software system integration

Community Page

Meeting link

Calendar link

By now you’ve certainly been exposed to some of the hype behind the Rust programming language. For the last eight years Rust has ranked #1 in the “Most admired language” category of Stack Overflow’s annual developer survey. Perhaps no other language in the history of software programming has commanded a following so dedicated to pestering their colleagues, friends, and random passers-by to switch to it for every conceivable use case.

At the next session of the Interoperability Special Interest Group, Grey will discuss the relevance of Rust to software system integration in particular. The challenge of tying together complex software systems carries significant liabilities. Failures to connect systems together correctly or to scale well can lead to cascading failures in your operations. The Rust language and its surrounding open source ecosystem offer some unique advantages when it comes to both software correctness and scaling.

This will not be a session that teaches how to program in Rust. The focus will be to provide attendees with enough conceptual information to consider whether Rust is a good candidate for their business needs, with an emphasis on software system integration use cases. We will conclude with an open Q&A, so feel free to bring along any burning questions or concerns you might have.

3 posts - 2 participants

Read full topic

by grey on November 29, 2023 08:26 AM

November 28, 2023
We need participants for a Survey on Field-based Testing of ROS applications!

Have you ever done any kind of test in the field or used field data on ROS applications? How about runtime verification? Do you have an idea of how techniques for testing robots in the field might be improved? We want to hear from you!

We are a group of researchers from Chalmers | University of Gothenburg (Sweden), Gran Sasso Science Institute (Italy), University of Brasília (Brazil), and Ruhr University Bochum (Germany), studying runtime verification and field testing of ROS-based applications. We synthesized 20 guidelines that should help developers and quality assurance (QA) teams to gather confidence in ROS systems. Now, we aim to get first-hand insights and opinions from experts to greatly help the robotics software engineering community.

We invite you to participate in a 15-30min online survey. Participating will allow you to reflect on your own practices, learn about others’ practices, describe challenges, and suggest improvements to the robotics software engineering research community.

We split the survey into two parts, developers and quality assurance (QA) teams, to give you more flexibility in answering. Please consider answering both. Survey:

Thanks!
(Shout-out to @Katherine_Scott who avidly helped to refine the survey with us!)

2 posts - 2 participants

Read full topic

by rdcal on November 28, 2023 09:35 AM

Space ROS Community Meeting January 18th 🚀

Hi ROS Community!

First, in case you missed it, the Space ROS team of volunteers have released the first ever distribution of Space ROS. Thanks @mkhansen, @ivanperez, @bkempa, and @ezrabrooks for this work.

Second: I’m pleased to announce PickNik will be hosting the next Space ROS community video call meeting on 2024-01-18T16:00:00Z UTC

We have a lot of great speakers from the space industry updating us on past and upcoming work to put ROS 2 on future space flight missions, with the following agenda:

  • What’s in the first release of Space ROS?
    • Brian Kempa, Intelligent Robotics Group, NASA Ames Research Center
  • Space ROS Example Demo - Curiosity Rover & Nav2
    • Matt Hansen, Space ROS and ROS 2 contributor
  • Space ROS Example Demo - CanadaArm
    • Ezra Brooks, PickNik Robotics
  • Space ROS Example Demo - Monitoring ROS
    • Ivan Perez, KBR @ NASA Ames Research Center
  • ROS in Space this year: Hybrid Trust Architecture
    • Brian Kempa, Intelligent Robotics Group, NASA Ames Research Center
  • Surface Robotics and iMetro Facilities at JSC
    • Evan Laske, NASA Johnson Space Center
  • Motiv Space Systems using ROS 2 for Space Arms
    • Eddie Tunstel, Motiv Space Systems

The video conferencing details are below.

Space ROS Community Meeting
Thursday, January 18th at 8am PST / 11am EST / 5pm CET
Google Meet joining info
Video call link: https://meet.google.com/xoz-ycjz-dva
Or dial: ‪(US) +1 567-855-1075‬ PIN: ‪697 459 256‬#
More phone numbers: https://tel.meet/xoz-ycjz-dva?pin=5290218848843

1 post - 1 participant

Read full topic

by davetcoleman on November 28, 2023 04:58 AM

November 27, 2023
Isaac ROS Nov update, 2.1 release w/ Nova Orin kit

We have released Isaac ROS 2.1 with updates and bug fixes.

The Isaac ROS update for ROS 2 Humble is available at github.com/NVIDIA-ISAAC-ROS, including packages for AI perception, image & LIDAR processing, navigation and adds:

  • Pre-built Debian packages for Isaac ROS on x86 and Jetson platforms
  • Live sensor benchmarking mode in ROS 2 Benchmark
  • Nova Orin to integrate the sensing and compute from Nova Carter AMR reference into your own robot
  • Bug fixes and performance improvements

nova_orin_2d-line_sm

(Nova Orin kit with sensors and compute for AMR development)

Isaac ROS 2.1 is available now at github.com/NVIDIA-ISAAC-ROS and is part of our commitment to provide features and hardware acceleration for commercial deployment, development and research for autonomous robots.

Clone the repositories you need into your ROS workspace to build from source with colcon alongside your other ROS2 packages, use pre-built Debian packages, or leverage the pre-built Isaac ROS Dev container. Please note that this release has been tested on the NVIDIA Jetson AGX Orin & Xavier with JetPack 5.1.2.

The next major update will be in March 2024 for NVIDIA’s AI Developer Conference GTC.

1 post - 1 participant

Read full topic

by ggrigor on November 27, 2023 05:53 PM

Iron stickers from Spring are YUGE

Hey all,

I just received three stickers in the mail which I ordered from the official Spring store front. They are much bigger than anticipated and quite pixelated. They measure about 13.7cm from bottom to top and the Spring UI says the size is “custom”. Which makes me think someone might have punched in a “5”, thinking it would be cm, when really it was inches. I think Spring have different facilities depending on shipping address; I ordered to France in case it matters.

I think since I never posted, discourse doesn’t let me attach any photos, but suffice it to say that at that size they’re way too big for a laptop. :see_no_evil:

I just wanted to check if anyone else had this issue. I’ll survive this drama, but might be worth it for whoever manages the store front to double check. :slight_smile:

4 posts - 3 participants

Read full topic

by mmcm on November 27, 2023 05:39 PM

November 24, 2023
Kangaroo robot free-walking thanks to the latest developments in software and hardware

Kangaroo is a bipedal research platform for exploring advanced control methods in legged locomotion, and in recent months the team at PAL Robotics has demonstrated the robot free-walking! The prototype platform, first created in 2021 continues to evolve thanks to the dedication of the Legged Robotics team. Read on to find out more about the

The post Kangaroo robot free-walking thanks to the latest developments in software and hardware appeared first on PAL Robotics Blog.

by PAL Robotics on November 24, 2023 12:56 PM

November 21, 2023
ROS 2 networking communications in microseconds with hardware acceleration

Dear roboticists,

I’m proud to share that our group at Acceleration Robotics has disclosed our latest FPGA designs which allow bringing ROS 2 message-passing infrastructure completely into hardware. To enhance composability and cover various use cases, we’ve split the complete networking stack in three IP cores: ROBOTCORE ROS 2, RTPS and UDP/IP. Altogether, they allow to exchange small ROS 2 messages in less than 2.5 us (one-way), accelerating networking by more than 62x on average when compared to traditional software implementations on CPUs[1].

When considering the worst case scenario (maximum latency) for small ROS 2 messages, ROBOTCORE ROS 2 remains isochronous reporting a consistent round-trip latency below 5 us. Opposed to this, software implementations on modern CPUs take on average 339 us for the same, but can reach latencies of up to 22.7 ms (22700 us) or more, which means ROBOTCORE ROS 2 is Thousands-Fold (4540x) faster in these worst case scenarios.

Block diagrams of each one of these designs are short descriptions are available below for those interested:

ROBOTCORE UDP/IP ROBOTCORE RTPS ROBOTCORE ROS 2
Accelerated UDP/IP networking stack. UDP/IP on FPGA. Accelerated DDS network communications. DDS-RTPS on FPGA Accelerated ROS 2 network communications. ROS 2 on FPGA

Addressing a major bottlenecks in ROS robotic communications

ROBOTCORE® ROS 2 and friends are the result of the last 5 years working towards faster and more efficient hardware for robots surrounding ROS 2 technologies. This started back in 2018, when we released a series of papers[2][3][4][5] that investigated robot networking and unveiled that modern CPU-based networking solutions, even when optimized, could not cope with many of the real-time needs of modern distributed robotic systems in industry powered by ROS. The disclosures above deliver absolute determinism and isochronous capabilities via hardware. Compared to software-based solutions, it ensures that the communication latency is lower, consuming less energy and that latency remains always the same, regardless of the load of the system. Crucial for real-time robotic systems and solving major bottlenecks in robotic communications today.

To be presented at ROSCon India 2023

We’re excited to disclose this now and present it publicly at the upcoming ROSCon India which our group is organizing and already has 750 confirmed attendees, including the sponsorship of Qualcomm, Analog Devices and NVIDIA among others. Stay tuned for more information on this regard.

For the ROS community, we’re currently considering to hold another Hardware Acceleration Working Group (HAWG) meeting soon to discuss these results and also the upcoming release of RobotPerf which will include new categories and interesting observations.

For more, including power-efficiency or how this minimizes the ROS 2 overhead over DDS (something many DDS vendors are currently criticizing about ROS 2) check the official page of ROBOTCORE ROS 2 and the official announcement.


  1. This considers the ROS 2 layers, the communication middleware implementation (DDS) and the networking stack, most often the Linux Networking Stack (LNS). ↩︎

  2. Gutiérrez, C. S. V., Juan, L. U. S., Ugarte, I. Z., & Vilches, V. M. (2018). Real-time Linux communications: an evaluation of the Linux communication stack for real-time robotic applications. arXiv preprint arXiv:1808.10821. ↩︎

  3. Gutiérrez, C. S. V., Juan, L. U. S., Ugarte, I. Z., & Vilches, V. M. (2018). Towards a distributed and real-time framework for robots: Evaluation of ROS 2.0 communications for real-time robotic applications. arXiv preprint arXiv:1809.02595. ↩︎

  4. Gutiérrez, C. S. V., Juan, L. U. S., Ugarte, I. Z., & Vilches, V. M. (2018). Time-sensitive networking for robotics. arXiv preprint arXiv:1804.07643. ↩︎

  5. Gutiérrez, C. S. V., Juan, L. U. S., Ugarte, I. Z., Goenaga, I. M., Kirschgens, L. A., & Vilches, V. M. (2018). Time synchronization in modular collaborative robots. arXiv preprint arXiv:1809.07295. ↩︎

3 posts - 2 participants

Read full topic

by vmayoral on November 21, 2023 03:45 PM

November 20, 2023
ROS 2 TSC Meeting Minutes 2023-11-16

ROS 2 TSC Meeting Minutes 2023-11-16

ROS 2 TSC Contribution Report 2023-11-16.pdf (111.8 KB)

1 post - 1 participant

Read full topic

by Katherine_Scott on November 20, 2023 11:28 PM

Upcoming API break in urdfdom

Hi all,

Please bear with me on a long post about urdfdom.

For those who don’t know, GitHub - ros/urdfdom: URDF parser houses the source code that both ROS 1 and ROS 2 use to parse and interact with URDF files.

Since 2012, the code there has had a dependency on TinyXML (the original version). Further, that dependency is exposed via the public API, in the form of a few functions that either consume or produce a TinyXML object.

Unfortunately, TinyXML itself has been deprecated for a long time. So we want to move urdfdom exclusively to TinyXML2, but we have been concerned that doing that would break current users of the urdfdom API.

One thing we could do here would be to have a transition period where we introduced TinyXML2 APIs alongside the existing TinyXML ones. I suggested this earlier this year, and SMillerDev took up the challenge. Unfortunately, the resulting PR is large and we would have to maintain a lot more code.

Instead, we recently took a look at the uses of urdfdom across all packages in Rolling, and we found that there are zero callers of the affected APIs there. That doesn’t mean there are zero callers in the world; we can’t see things that aren’t released publicly. However, the fact that there are no callers in Rolling gives us confidence that there are few callers of these APIs in the world.

Therefore, we are very seriously considering closing the PR adding in TinyXML2 APIs and merging this PR that replaces TinyXML with TinyXML2. That would break the API, but it would be much simpler going forward and we don’t expect too much fallout from it.

This post acts as both a notice that we are going to do this, and as a question: do you depend on the TinyXML APIs from urdfdom? If you do, please respond and let us know how you are using them. If we don’t hear back from users that these APIs are important to them, then we will likely break the API and bump the major number of the urdfdom library.

Please also respond if you have any other questions or concerns about this change. Thank you.

5 posts - 3 participants

Read full topic

by clalancette on November 20, 2023 06:51 PM

Important Announcement, Patch Release 3 and New Packages for Iron Irwini 2023-11-20

We’re happy to announce a new Iron release :iron: :irwini: :tada:

The latest sync brings 11 new packages and 118 updates to ROS 2 Iron Irwini. This sync was tagged as iron/2023-11-20 .

We’ve recently made an important update to ROS 2: loaned messages are
now disabled by default. If you don’t know what loaned messages are,
then you can skip the following paragraph. If you are using loaned messages,
continue reading.
We disabled the loaned messages by default to address safety
concerns, as there were instances of shared pointers being unsafely
reused across multiple callbacks. While this adjustment temporarily
limits loaned message capabilities in callbacks, it’s a necessary step to
ensure the reliability and safety of the system. See Disable the loaned messages inside the executor. by clalancette · Pull Request #2335 · ros2/rclcpp · GitHub for more details.
If you understand the risks of using loaned messages and want to enable them,
you can set ROS_DISABLE_LOANED_MESSAGE=0 in the environment before launching your nodes.
Rest assured, we’re exploring options to safely reintroduce this feature in the future. Your
understanding and support in this matter are greatly appreciated.

Package Updates for iron

Added Packages [11]:

Updated Packages [118]:

  • ros-iron-controller-interface: 3.20.0-1 → 3.21.0-1
  • ros-iron-controller-interface-dbgsym: 3.20.0-1 → 3.21.0-1
  • ros-iron-controller-manager: 3.20.0-1 → 3.21.0-1
  • ros-iron-controller-manager-dbgsym: 3.20.0-1 → 3.21.0-1
  • ros-iron-controller-manager-msgs: 3.20.0-1 → 3.21.0-1
  • ros-iron-controller-manager-msgs-dbgsym: 3.20.0-1 → 3.21.0-1
  • ros-iron-fastrtps-cmake-module: 3.0.1-1 → 3.0.2-1
  • ros-iron-hardware-interface: 3.20.0-1 → 3.21.0-1
  • ros-iron-hardware-interface-dbgsym: 3.20.0-1 → 3.21.0-1
  • ros-iron-joint-limits: 3.20.0-1 → 3.21.0-1
  • ros-iron-libstatistics-collector: 1.5.1-2 → 1.5.2-1
  • ros-iron-libstatistics-collector-dbgsym: 1.5.1-2 → 1.5.2-1
  • ros-iron-mcap-vendor: 0.22.4-1 → 0.22.5-1
  • ros-iron-mcap-vendor-dbgsym: 0.22.4-1 → 0.22.5-1
  • ros-iron-rcl: 6.0.3-1 → 6.0.4-1
  • ros-iron-rcl-action: 6.0.3-1 → 6.0.4-1
  • ros-iron-rcl-action-dbgsym: 6.0.3-1 → 6.0.4-1
  • ros-iron-rcl-dbgsym: 6.0.3-1 → 6.0.4-1
  • ros-iron-rcl-lifecycle: 6.0.3-1 → 6.0.4-1
  • ros-iron-rcl-lifecycle-dbgsym: 6.0.3-1 → 6.0.4-1
  • ros-iron-rcl-yaml-param-parser: 6.0.3-1 → 6.0.4-1
  • ros-iron-rcl-yaml-param-parser-dbgsym: 6.0.3-1 → 6.0.4-1
  • ros-iron-rclcpp: 21.0.3-1 → 21.0.4-1
  • ros-iron-rclcpp-action: 21.0.3-1 → 21.0.4-1
  • ros-iron-rclcpp-action-dbgsym: 21.0.3-1 → 21.0.4-1
  • ros-iron-rclcpp-components: 21.0.3-1 → 21.0.4-1
  • ros-iron-rclcpp-components-dbgsym: 21.0.3-1 → 21.0.4-1
  • ros-iron-rclcpp-dbgsym: 21.0.3-1 → 21.0.4-1
  • ros-iron-rclcpp-lifecycle: 21.0.3-1 → 21.0.4-1
  • ros-iron-rclcpp-lifecycle-dbgsym: 21.0.3-1 → 21.0.4-1
  • ros-iron-rclpy: 4.1.3-1 → 4.1.4-1
  • ros-iron-rcpputils: 2.6.1-3 → 2.6.2-1
  • ros-iron-rcpputils-dbgsym: 2.6.1-3 → 2.6.2-1
  • ros-iron-rcutils: 6.2.1-2 → 6.2.2-2
  • ros-iron-rcutils-dbgsym: 6.2.1-2 → 6.2.2-2
  • ros-iron-rmw-fastrtps-cpp: 7.1.1-2 → 7.1.2-1
  • ros-iron-rmw-fastrtps-cpp-dbgsym: 7.1.1-2 → 7.1.2-1
  • ros-iron-rmw-fastrtps-dynamic-cpp: 7.1.1-2 → 7.1.2-1
  • ros-iron-rmw-fastrtps-dynamic-cpp-dbgsym: 7.1.1-2 → 7.1.2-1
  • ros-iron-rmw-fastrtps-shared-cpp: 7.1.1-2 → 7.1.2-1
  • ros-iron-rmw-fastrtps-shared-cpp-dbgsym: 7.1.1-2 → 7.1.2-1
  • ros-iron-ros2-control: 3.20.0-1 → 3.21.0-1
  • ros-iron-ros2-control-test-assets: 3.20.0-1 → 3.21.0-1
  • ros-iron-ros2action: 0.25.3-1 → 0.25.4-1
  • ros-iron-ros2bag: 0.22.4-1 → 0.22.5-1
  • ros-iron-ros2cli: 0.25.3-1 → 0.25.4-1
  • ros-iron-ros2cli-test-interfaces: 0.25.3-1 → 0.25.4-1
  • ros-iron-ros2cli-test-interfaces-dbgsym: 0.25.3-1 → 0.25.4-1
  • ros-iron-ros2component: 0.25.3-1 → 0.25.4-1
  • ros-iron-ros2controlcli: 3.20.0-1 → 3.21.0-1
  • ros-iron-ros2doctor: 0.25.3-1 → 0.25.4-1
  • ros-iron-ros2interface: 0.25.3-1 → 0.25.4-1
  • ros-iron-ros2lifecycle: 0.25.3-1 → 0.25.4-1
  • ros-iron-ros2lifecycle-test-fixtures: 0.25.3-1 → 0.25.4-1
  • ros-iron-ros2lifecycle-test-fixtures-dbgsym: 0.25.3-1 → 0.25.4-1
  • ros-iron-ros2multicast: 0.25.3-1 → 0.25.4-1
  • ros-iron-ros2node: 0.25.3-1 → 0.25.4-1
  • ros-iron-ros2param: 0.25.3-1 → 0.25.4-1
  • ros-iron-ros2pkg: 0.25.3-1 → 0.25.4-1
  • ros-iron-ros2run: 0.25.3-1 → 0.25.4-1
  • ros-iron-ros2service: 0.25.3-1 → 0.25.4-1
  • ros-iron-ros2topic: 0.25.3-1 → 0.25.4-1
  • ros-iron-rosbag2: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-compression: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-compression-dbgsym: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-compression-zstd: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-compression-zstd-dbgsym: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-cpp: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-cpp-dbgsym: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-examples-cpp: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-examples-cpp-dbgsym: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-examples-py: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-interfaces: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-interfaces-dbgsym: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-performance-benchmarking: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-performance-benchmarking-msgs: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-py: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-storage: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-storage-dbgsym: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-storage-default-plugins: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-storage-mcap: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-storage-mcap-dbgsym: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-storage-sqlite3: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-storage-sqlite3-dbgsym: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-test-common: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-test-msgdefs: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-test-msgdefs-dbgsym: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-tests: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-transport: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosbag2-transport-dbgsym: 0.22.4-1 → 0.22.5-1
  • ros-iron-rosidl-dynamic-typesupport: 0.0.4-1 → 0.0.5-1
  • ros-iron-rosidl-dynamic-typesupport-dbgsym: 0.0.4-1 → 0.0.5-1
  • ros-iron-rosidl-typesupport-fastrtps-c: 3.0.1-1 → 3.0.2-1
  • ros-iron-rosidl-typesupport-fastrtps-c-dbgsym: 3.0.1-1 → 3.0.2-1
  • ros-iron-rosidl-typesupport-fastrtps-cpp: 3.0.1-1 → 3.0.2-1
  • ros-iron-rosidl-typesupport-fastrtps-cpp-dbgsym: 3.0.1-1 → 3.0.2-1
  • ros-iron-rqt-controller-manager: 3.20.0-1 → 3.21.0-1
  • ros-iron-rqt-reconfigure: 1.3.3-2 → 1.3.4-1
  • ros-iron-rviz-assimp-vendor: 12.4.4-1 → 12.4.5-1
  • ros-iron-rviz-common: 12.4.4-1 → 12.4.5-1
  • ros-iron-rviz-common-dbgsym: 12.4.4-1 → 12.4.5-1
  • ros-iron-rviz-default-plugins: 12.4.4-1 → 12.4.5-1
  • ros-iron-rviz-default-plugins-dbgsym: 12.4.4-1 → 12.4.5-1
  • ros-iron-rviz-ogre-vendor: 12.4.4-1 → 12.4.5-1
  • ros-iron-rviz-ogre-vendor-dbgsym: 12.4.4-1 → 12.4.5-1
  • ros-iron-rviz-rendering: 12.4.4-1 → 12.4.5-1
  • ros-iron-rviz-rendering-dbgsym: 12.4.4-1 → 12.4.5-1
  • ros-iron-rviz-rendering-tests: 12.4.4-1 → 12.4.5-1
  • ros-iron-rviz-visual-testing-framework: 12.4.4-1 → 12.4.5-1
  • ros-iron-rviz2: 12.4.4-1 → 12.4.5-1
  • ros-iron-rviz2-dbgsym: 12.4.4-1 → 12.4.5-1
  • ros-iron-shared-queues-vendor: 0.22.4-1 → 0.22.5-1
  • ros-iron-sqlite3-vendor: 0.22.4-1 → 0.22.5-1
  • ros-iron-transmission-interface: 3.20.0-1 → 3.21.0-1
  • ros-iron-transmission-interface-dbgsym: 3.20.0-1 → 3.21.0-1
  • ros-iron-twist-mux: 4.2.0-1 → 4.3.0-1
  • ros-iron-twist-mux-dbgsym: 4.2.0-1 → 4.3.0-1
  • ros-iron-zstd-vendor: 0.22.4-1 → 0.22.5-1

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:

Note: The list of contributors is incomplete as there may be an issue with the tool used to generate this report.

  • Alejandro Hernandez Cordero
  • Audrow Nash
  • Bence Magyar
  • Bernd Pfrommer
  • Brandon Ong
  • Dharini Dutia
  • Fictionlab
  • Foxglove
  • Geoffrey Biggs
  • Ivan Paunovic
  • Michael Orlov
  • ROS Tooling Working Group
  • Shane Loretz
  • geoff

1 post - 1 participant

Read full topic

by Yadunund on November 20, 2023 04:37 PM

Again... Snapshot repo GPG key expired

Since yesterday, there is a problem running Melodic Industrial CI:

$ sudo apt-get update -qq
  W: GPG error: http://snapshots.ros.org/melodic/final/ubuntu bionic InRelease: The following signatures were invalid: EXPKEYSIG AD19BAB3CBF125EA ROS Snapshot builder <rosbuild@ros.org>
  E: The repository 'http://snapshots.ros.org/melodic/final/ubuntu bionic InRelease' is not signed.

I know Melodic is EOL, but still, it should be usable from the snapshot repo, shouldn’t it?

There is already another report on RSE, but I think this is a better place to discuss such problem.

13 posts - 11 participants

Read full topic

by peci1 on November 20, 2023 09:21 AM

November 18, 2023
Simple_launch approaching event handling

Hi,

A few posts on discourse and stackexchange have already highlighted the difficulty of writing Python launch files for ROS 2.

In particular, the syntax may be a bit verbose and the arguments somehow hard to handle as they are not raw Python types.

The simple_launch package wraps the standard launch syntax inside a much lighter approach. In particular, groups (by namespace or conditions) are defined through the with Python syntax and thus the indentation clearly expresses the current level of namespace or condition.

The current release allows easy handling of:

  • namespaces
  • conditions
  • finding a file inside a package (thanks os.walk)
  • container and composable nodes
  • spawning a robot_state_publisher from a xacro file with arguments, even if all of those come from launch arguments
  • uploading models to Gazebo
  • bridging topics with Gazebo (ros_gz_bridge wrapper)
  • setting use_sim_time for all nodes in the launch file
  • using the OpaqueFunction idiom (my favorite) without seeing perform or context everywhere, in case you really need raw Python types

The package is available through apt and the next release will be focusing on event-based groups. This is already available in the repository but edge cases appear when combining events and namespaces.
The next release will make it clear what the chosen approach is.

The goal is not to be able to re-do everything in a simpler way, but to be able to do very easily what people do very often. Feel free to comment, issue or pull request.
Next releases will also be focusing on documentation and type hints that are still a bit lacking due to numerous combinations of Substitutions and raw Python types.

7 posts - 5 participants

Read full topic

by OlivierKermorgant on November 18, 2023 08:27 PM

November 17, 2023
ROS News for the Week of November 12th, 2023

ROS News for the Week of November 12th, 2023

What's New and Upcoming in Open Source Robotics at ROSCon '23

Check out this fantastic PX4 and ROSCon recap video from our friends at PX4



Our next Gazebo Community Meeting will include a report from the IIT Madras Aritra maritime robotics team.



Check out this new ROS Noetic package that implements a Segment Anything Model as a ROS Service.



All good things must come to an end. Audrow has stepped down from Sense, Think, Act.



Our friends at Tangram have a new Kickstarter campaign for their HiFi Depth Sensor. From what we’re told the sensor has fantastic accuracy and resolution, auto-calibrates, and supports ROS 2 out of the box.


Events

News

ROS

6 posts - 3 participants

Read full topic

by Katherine_Scott on November 17, 2023 09:50 PM

November 16, 2023
ROS Deployment Meeting (#1?)

Hi,

for those who are interested in how to manage and deploy the ROS application?, let’s have a follow-up meeting as we promised at ROSCon 2023 BoF :smile:

revised from Automatic Deployment of ROS2 Based System to remote devices: Dual Copy or Containers?, besides we had 44 people registered to BoF: Deployment of ROS 2 to remote devices at ROSCon 2023.

with that, i think there are many interests about how to deploy and manage robot application. Please feel free to join the meeting :coffee:

Date / Place

2023-12-04T17:00:00Z UTC

Agenda

Really appreciate @ciandonovan , he is willing to share the experience and take the effort for ROS community. :clap: :clap: :clap:

How to join?

Reference

thanks,

24 posts - 12 participants

Read full topic

by tomoyafujita on November 16, 2023 07:18 PM

New Packages for Noetic 2023-11-15

We’re happy to announce 5 new packages and 51 updates are now available in ROS Noetic. This sync was tagged as noetic/2023-11-15.

Thank you to every maintainer and contributor who made these updates available!

Package Updates for ROS Noetic

Added Packages [5]:

  • ros-noetic-clearpath-onav-api-examples: 0.0.3-1
  • ros-noetic-clearpath-onav-api-examples-lib: 0.0.3-1
  • ros-noetic-clearpath-onav-examples: 0.0.3-1
  • ros-noetic-pr2eus-moveit: 0.3.15-3
  • ros-noetic-sick-scan-xd: 3.0.3-1

Updated Packages [51]:

Removed Packages [0]:

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:

  • Bence Magyar
  • Chris Iverach-Brereton
  • Fictionlab
  • Isaac I. Y. Saito
  • Jason Higgins
  • John Hurliman
  • Jose Mastrangelo
  • Jose-Luis Blanco-Claraco
  • José Mastrangelo
  • Kei Okada
  • Martin Pecka
  • Michael Ferguson
  • Roni Kreinin
  • Southwest Research Institute
  • YoheiKakiuchi
  • rostest

1 post - 1 participant

Read full topic

by sloretz on November 16, 2023 12:47 AM

November 15, 2023
Proposal for ROS 2 Production Working Group

In the October 2023 Technical Steering Committee meeting, representatives from iRobot presented on the topic of “Scaling ROS 2 for Production”, where issues regarding the current state of ROS 2 in how it manages developer cost, product quality, stability, and performance were addressed, and new ideas were proposed. The general consensus from the meeting feedback was that a working group could be formed to dedicate planning and resources towards implementing solutions to this agenda. Thus, here is the proposal:

Context: ROS 2 is a great software framework that enables efficient research, quick prototyping, and access to a community of open-source robotics projects. However, the challenge remains for issues concerning scaling ROS 2 usage for a production robot. In a production-oriented environment, quality control is a necessary requirement, therefore, any regression in the build, or stability of code on the robot, or in its performance can have major consequences. In addition, if an underlying change in the ROS 2 code significantly affects the overall build time or developer cost for integrating into robotics products, then it may impact a developer or company’s bottom line. These are concerns that make ROS 2 limited and difficult to incorporate in larger-scale production use cases.

Mission Statement: Affirm ROS 2’s commitment as an infrastructure for scalable deployment and production of robotics products by prioritizing and coordinating efforts to address concerns of Developer Cost, Stability, Quality Control, and Performance.

Key Topics to Cover:
• ROS 2 Build Farm & Statistics
• CICD & Testing Coverage
• Release schedule requirements
• Performance Evaluation & Regressions
• RMW Relationship
• Architecture Improvements
• Documentation

Goals
• Early-detection / resolution of regressions in build time, performance, and stability
• Support for physical testing as part of CI before release
• Improved capacity for developer tuning / configuration
• Stricter requirements for RMW tier support to address testing and stability
• Accessible documentation for advanced or optimized production use cases

Group expectations:
• Bi-weekly or monthly meetings to discuss solutions to address above agenda
• Define tasks and github issues related to implementing solutions
• Recruit and assign owners and resources for completing tasks
• Align agenda and task(s) timeline with ROS 2 release schedule

Call for Participation:
If you are interested in updates or participating in working group meetings, please fill out the following google form survey:

If you have any feedback on the content or direction of this proposed working group, please feel free to write a comment on this post or in the above survey. We will send a follow-up notification to organize the first meeting launch date and time.

4 posts - 2 participants

Read full topic

by bpwilcox on November 15, 2023 06:05 PM

November 14, 2023
Audrow Nash to step down from hosting the Sense, Think, Act podcast

Hi Everyone,

We have some bittersweet news. @audrow is moving on to the next phase of his podcasting career and will be stepping down as the host of the OSRF’s Sense, Think, Act podcast. Under Audrow’s masterful leadership and hosting, Sense, Think, Act has become one of the premier places to hear interviews with leaders in the world of robotics.

The OSRF is sincerely grateful to Audrow for giving Sense, Think, Act a powerful start through his hard work and dedication to interviewing a stellar range of individuals in the wide field of robotics, including Dave Coleman, Ryan Garipy, Steve Macenski, Brett Aldrich, Melonee Wise, and Matt Robinson. Topics discussed have included robot navigation, robot ethics, STEM education, manufacturing, scanning warehouse inventory, and so much more. Audrow’s interviews have been informative and thought-provoking, and he has helped to make the field of robotics more accessible to a broader audience.

Audrow’s new podcast, The Audrow Nash Podcast, is available here, and here, and we encourage you all to check it out and subscribe! It’s sure to be a fantastic and educational show, and we wish him all the best in his future endeavors. If you want to stay up to date on Audrow’s latest works you can follow him on Twitter, and LinkedIn.

Please stay tuned for exciting new content to come from Sense, Think, Act! In the meantime, existing episodes will remain available. If you haven’t listened to them yet, we encourage you to do so! We believe they’re very educational and inspirational to all in the robotics community.

5 posts - 5 participants

Read full topic

by Katherine_Scott on November 14, 2023 05:26 PM

ROS 2 Router for Remote Robotics and Topic Filtering

Hi everyone!

We’re introducing the new husarnet/ros2router Docker image, which allows you to easily bridge ROS 2 nodes running across different robots, servers, or laptops in various networks. It features built-in topic filtering, enabling you to decide in real-time which ROS 2 interface should be exposed to remote hosts.

There’s no need to change your DDS settings. Simply run our Docker image alongside your existing ROS 2 application, regardless of whether it’s running on a host or inside Docker containers.

Our Docker image is based on the newest release of eProsima DDSRouter and it automatically integrates with the Husarnet VPN client via its HTTP API.

For more details and tutorial on how to integrate husarnet/ros2router with your robots, computers, or multi-tenant cloud applications, check out the article: ROS 2 Router for Remote Robotics and Topic Filtering | Husarnet

ros2router-77f0346677b50e3540cf36a10a011d4e

1 post - 1 participant

Read full topic

by Nina on November 14, 2023 02:44 PM

November 10, 2023
ROS News for the Week of November 6th, 2023

ROS News for November 5th, 2023


ROSCon 2023 Videos and Slides Now Available! Our friends at PX4 have their event recaps up as well. Meanwhile, Odense Denmark is already planning ROSCon 2024.



We’ve got a ROS Meetup Singapore at the end of the month. This event will focus on robot dev ops!

output
The Conference on Robot Learning was this week. The gif above is taken from HomeRobot: Open Vocabulary Mobile Manipulation which uses a HelloRobot Stretch to basic tasks around the house. I’ve included some of the open access papers I came across this week below.


image
Cruise is not having a good week. Last week it was made public that Cruise vehicles needed human assistance every five miles. Early this week it was published that Cruise knew their cars had problems detecting children while driving autonomously. Now Cruise and GM are recalling all their autonomous vehicles and laying off staff.


Events

News

Papers (Mainly CoRL, but also others)

ROS


Got a minute? Why not help out some other robot developers?

5 posts - 3 participants

Read full topic

by Katherine_Scott on November 10, 2023 09:25 PM

November 09, 2023
⚜️ ROSCon 2023 Videos and Slides Now Available!

ROSCon 2023 Videos and Slides Now Available

Hi Everyone,

I am happy to announce that the videos and slides from ROSCon 2023 are now available online. You can find everything on the ROSCon website and in the OSRF Vimeo Showcase of the event. We’ve also created a short link for the videos that should make the videos easier to share: bit.ly/ROSCon23Vids. To aid discoverability on ROS Discourse I’ve pasted links to all of the talks at the bottom of the post that you can also use.

Along with the videos and slides we’ve put together a quick wrap up post on openrobotics.org. If you want to see some of our professional photos from the event please take a look.

If you missed ROSCon this year and would like a chance to meet up with your colleagues we still have ROSCon Germany next week and ROSCon India coming up in about a month. As for ROSCon 2024, Odense, Denmark is already getting ready for our visit next year.

Finally, I want to thank everyone who made ROSCon 2023 possible! We couldn’t put together such a fantastic event without the help of our speakers, sponsors, volunteers, reviewers, and workshop organizers. You all deserve a round of applause. :clap: :clap:

ROSCon 2023 Talks

13 posts - 6 participants

Read full topic

by Katherine_Scott on November 09, 2023 05:38 PM

November 08, 2023
CoppeliaSim V4.6 Released: enhanced Python integration

Robotics simulator: enhanced Python integration in CoppeliaSim

I’m happy to share the latest update of CoppeliaSim: version 4.6 is out, with enhanced Python integration:

  • Effortless connection to CoppeliaSim from any Python script
  • Access to all of CoppeliaSim’s objects and API
  • CoppeliaSim library incorporation into a Python script
  • Efficiently scheduling, initiation, and execution of multiple embedded Python scripts

For more information, please visit https://www.coppeliarobotics.com

CoppeliaSim Edu is free to download and works out-of-the-box, no registration required

Cheers,
Marc

1 post - 1 participant

Read full topic

by Marc on November 08, 2023 06:28 PM


Powered by the awesome: Planet