Planet ROS

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

Planet ROS - http://planet.ros.org[WWW] http://planet.ros.org

ROS Discourse General: Robotics Christmas Videos 2024

Hi! I noticed that no thread was started yet to share robotic christmas videos of 2024!

IEEE have started their latest video list already here:

For anyone who is winding down already for the holidays, please share any you have encountered so far :christmas_tree:

Happy holidays everyone!

5 posts - 4 participants

Read full topic

[WWW] https://discourse.ros.org/t/robotics-christmas-videos-2024/41261

ROS Discourse General: What is in scope for an Enhancement Proposal?

The OSRA’s Technical Committee on Enhancement Proposal Processes has been working over the past few months to produce a replacement for the current ROS Enhancement Proposal (REP) process, which is now severely out of date and doesn’t work with our current tools (we don’t, for example, have the mailing list it requires anymore). The TC has been looking at what no longer works with the current REP process, as well as what many other organisations with similar processes do.

As part of this work, the TC has run into that most difficult of questions: what is in scope? In other words, when do you need to send in an Enhancement Proposal and follow the prescribed process to get it approved/accepted, and when can you just go ahead and submit a PR?

So far we’ve come up with some obvious ones that we think might be in scope, like making significant changes to an external API. However this is something of a braintstorming exercise, and the more brains doing some storming, the better.

So, now that most of us are moving into a week or two of not-working-that-much, I’d like to hear your thoughts. For what should you need to follow a REP-like process? What should never be in scope? What is in the grey zone and would need discussion on a case-by-case basis?

2 posts - 2 participants

Read full topic

[WWW] https://discourse.ros.org/t/what-is-in-scope-for-an-enhancement-proposal/41254

ROS Discourse General: OSRA TGC meeting minutes for November, 2024

The meeting minutes for the regular meeting of the Technical Governance Committee held on the 21st of November, 2024, were approved in the December meeting and are now available in the official minutes repository. You can find the complete minutes here.

The TGC received the monthly project and technical committee updates, including the success of in-person PMC meetings at ROSCon, the news that Open-RMF has switched to using Zenoh, and the Infrastructure team working to move to Ubuntu 24.04.

Of particular note in this meeting, the TC on Enhancement Proposal Processes has started dealing with the thorny question of “what is in scope for an Enhacement Proposal?”

In a follow-up to an item from the October meeting, the OSRF Board of Directors decided to reject the proposal to move the Nexus project under the Open-RMF PMC for the time being. This decision was made because the Board wants the Open-RMF project to concentrate on making its existing feature set robust before expanding the scope of the project.

The next TGC meeting will take place in January, 2025. The minutes of the December meeting should be approved in that meeting and posted publicly shortly thereafter.

1 post - 1 participant

Read full topic

[WWW] https://discourse.ros.org/t/osra-tgc-meeting-minutes-for-november-2024/41252

ROS Discourse General: OSRA activity recap for 2024

As 2024 draws to a close, we’re happy to say that the OSRA has had a successful first eight months of operation. Although we still have much to do with spinning up all the different bits of the OSRA, in the past eight months we have set up the Technical Governance Committee (TGC) and four Project Management Committees (PMCs) for ROS, Gazebo, Open-RMF and Infrastructure. The TGC has set up one Special Interest Group (SIG) and two Technical Committees (TCs), one of which (on the use of generative AI tools) has already completed its work.

The TGC has discussed several technical matters of relevance to the projects that were brought up by the TGC members. Some of these have been resolved, and some are on-going. The TGC is looking forward to an even more productive 2025 with several important matters to discuss, not the least of which is to begin applying OSRA membership dues to project requests.

The PMCs are starting to grow, too. Both the ROS and the Gazebo PMCs are beginning to mentor new Committers and PMC Members from the community.

For more details, pelase see the attached PDF.

OSRA Activity Recap - March 2024 Launch To-Date.pdf (106.9 KB)

1 post - 1 participant

Read full topic

[WWW] https://discourse.ros.org/t/osra-activity-recap-for-2024/41251

NooTriX: ROS2 with Python and YAML: A Step-by-Step Guide from Creating a Workspace to Running Multiple Nodes

If you’re diving into the world of robotics with ROS2 (Robot Operating System 2), setting up a solid foundation is crucial. A well-organized workspace and properly structured nodes are the backbone of any successful ROS project. Whether you’re a beginner or a seasoned developer, this guide will walk you through creating and managing a ROS2 […]

The post ROS2 with Python and YAML: A Step-by-Step Guide from Creating a Workspace to Running Multiple Nodes appeared first on nootrix.

[WWW] https://nootrix.com/tutorials/ros2-with-python-and-yaml-a-step-by-step-guide-from-creating-a-workspace-to-running-multiple-nodes/

ROS Discourse General: Random appreciation thread

It’s the Winter Solstice in the northern hemisphere today, which means our daylight is scarce and precious and should be cherished. In that spirit of recognition and appreciation, I just wanted to share some people and things I am grateful for.

  • I am grateful for mathematics and the teachers and students I have learned with over the years. Linear Algebra! It’s cool enough on its own with eigenvalues and null spaces, but think of all the kinematics and feedback control it helps us with. I forget which class it was, but I’ll never forget how my mind was blown while following a Taylor series analysis on the chalkboard involving sines, cosines, exponentials and complex numbers that ended with (spoiler alert) e ^ (i pi) = -1. A pair of irrational numbers is related to an imaginary number? What a world!
  • I’m grateful for the open source robotics community for building tools and relationships and sharing with each other. I’m especially grateful for the colleagues I have worked with and built tools and relationships with at Open Robotics and Intrinsic and in the wider community. I’m grateful to the people who serve in leadership roles in our community, such as package maintainers, ROS Bosses, PMC project leads, Geoff and Vanessa at OSRF, the OSRF board, and many others!
  • I’m grateful to command-line interfaces and tools, grep, sed/awk, the pipe |, redirecting to /dev/null, wc. Also there is something powerful that I am afraid of and whenever I tap into its power I wonder if it will ultimately be a mistake, but I am also grateful for regular expressions.

Primarily I’m grateful for the people. Thank you for being you, and enjoy the daylight today!

3 posts - 3 participants

Read full topic

[WWW] https://discourse.ros.org/t/random-appreciation-thread/41232

ROS Discourse General: `testjob_coordinator`: a parallel integration test runner PoC

Most ROS 2 testing pipelines run all integration tests sequentially, as running in parallel is not that well supported yet. While one can set a number of workers, in practice the usefulness of that is limited as the feasible number of parallel tests greatly depends on the host (resulting in host-specific configurations) and that this number must always be based on the most resource-demanding tests, resulting in under utilization of the host resources (and thus still far from optimal test suite run durations). Also, test contamination is barely addressed, for example using separate domain ids for each test is often not the default and as far as I’m aware, no CPU isolation is done resulting in parallel tests competing for resources which increases test flakiness.

With this in mind, I developed testjob_coordinator - a proof-of-concept package that aims to address the above to easily run launch_testing-based integration tests in parallel.

In short:

  • Register tests using the testjob_coordinator_add_launch_test CMake macro.
  • If desired: specify timeout, number of CPU cores, RAM and exclusive resources - testjob_coordinator will respect these when running the tests.
  • Run the tests with ros2 run testjob_coordinator run_tests. testjob_coordinator sorts the tests to minimize overall test duration, and while running maximizes host machine resource usage while strictly enforcing each test’s limits. Also, each parallel test automatically receives a yet unused domain id through the domain coordinator.
  • Test output is available as xunit files, just like as if they were run with colcon test.

Code here, including example tests: GitHub - abaeyens/testjob_coordinator: A ROS 2 package for a PoC parallel test runner

For now the aim is to see whether this approach makes sense, before putting in further development effort (such as integration with colcon) and doing a proper system design. So please don’t already expect clean code and a polished interface.

Does this fit in your workflow? What do you like / don’t like? Which features would you like to see in such a tool? Looking forward to your feedback.

(To the moderators: If this doesn’t belong in the ‘General’ category, please move this.)

1 post - 1 participant

Read full topic

[WWW] https://discourse.ros.org/t/testjob-coordinator-a-parallel-integration-test-runner-poc/41230

ROS Discourse General: Localization-only mode in ROS 2 API of mola_lidar_odometry

Update to the former post: Tons of new features have been added to mola + mola_lidar_odometry in the latest releases:

  • Correct handling of ROS 2 namespaces.
  • Support for NDT-3D maps
  • ROS 2 services to start/stop mapping, load/save maps, etc.

Resources:

MOLA-LO: Mapping, then localize - Step-by-step tutorial

Feedback, issues, or PRs are all greatly appreciated! :slight_smile:

PS: Not all these features are available in the current binaries from apt… you might need to build from sources or wait for the next release cycle.

1 post - 1 participant

Read full topic

[WWW] https://discourse.ros.org/t/localization-only-mode-in-ros-2-api-of-mola-lidar-odometry/41225

ROS Discourse General: ROS News for the Week of December 15th, 2024

ROS News for the Week of December 15th, 2024


xmas
It is that time of year! Time for robot holiday videos! IEEE Spectrum has a full run down. I particularly like the Clearpath Robotics’ video that features multiple TB4 lites acting as elves. :elf:


image

New tutorial alert. We just released an official tutorial for the ament lint CLI utilities. If you are not using these tools to clean up your code, you should be!


soar_ros_icon_slogan_default
SOAR is the OG of classic AI! This week we learned about a new package to
connect SOAR and ROS 2.


opposite_view_loop_closure (1)

This week a team at MIT released ROMAN an open-set object mapping / global localization package along with a ROS 2 wrapper.


teaser (2)

Everyone is talking about it! This week a team of 18 universities plus NVIDIA released Genesis, a generative world for general-purpose robotics & embodied AI learning. The early demos look impressive. You can learn more at the project page.

Events

News

ROS

Got a Minute? :mantelpiece_clock: :gift:

It is the holidays and everyone has some extra free time. Why not give the gift of open source and review a pull request or fix an issue in ROS 2?

1 post - 1 participant

Read full topic

[WWW] https://discourse.ros.org/t/ros-news-for-the-week-of-december-15th-2024/41220

ROS Discourse General: New packages for Humble Hawksbill 2024-12-20

Package Updates for Humble

Added Packages [30]:

  • ros-humble-eiquadprog: 1.2.9-2
  • ros-humble-eiquadprog-dbgsym: 1.2.9-2
  • ros-humble-etsi-its-mapem-ts-coding: 3.0.0-1
  • ros-humble-etsi-its-mapem-ts-coding-dbgsym: 3.0.0-1
  • ros-humble-etsi-its-mapem-ts-conversion: 3.0.0-1
  • ros-humble-etsi-its-mapem-ts-msgs: 3.0.0-1
  • ros-humble-etsi-its-mapem-ts-msgs-dbgsym: 3.0.0-1
  • ros-humble-etsi-its-spatem-ts-coding: 3.0.0-1
  • ros-humble-etsi-its-spatem-ts-coding-dbgsym: 3.0.0-1
  • ros-humble-etsi-its-spatem-ts-conversion: 3.0.0-1
  • ros-humble-etsi-its-spatem-ts-msgs: 3.0.0-1
  • ros-humble-etsi-its-spatem-ts-msgs-dbgsym: 3.0.0-1
  • ros-humble-proto2ros: 1.0.0-3
  • ros-humble-proto2ros-dbgsym: 1.0.0-3
  • ros-humble-tuw-geo-msgs: 0.2.3-1
  • ros-humble-tuw-geo-msgs-dbgsym: 0.2.3-1
  • ros-humble-tuw-graph-msgs: 0.2.3-1
  • ros-humble-tuw-graph-msgs-dbgsym: 0.2.3-1
  • ros-humble-tuw-object-map-msgs: 0.2.3-1
  • ros-humble-tuw-object-map-msgs-dbgsym: 0.2.3-1
  • ros-humble-tuw-std-msgs: 0.2.4-1
  • ros-humble-tuw-std-msgs-dbgsym: 0.2.4-1
  • ros-humble-ur-simulation-gz: 0.1.0-1
  • ros-humble-yasmin: 3.0.3-1
  • ros-humble-yasmin-demos: 3.0.3-1
  • ros-humble-yasmin-demos-dbgsym: 3.0.3-1
  • ros-humble-yasmin-msgs: 3.0.3-1
  • ros-humble-yasmin-msgs-dbgsym: 3.0.3-1
  • ros-humble-yasmin-ros: 3.0.3-1
  • ros-humble-yasmin-viewer: 3.0.3-1

Updated Packages [330]:

  • ros-humble-ackermann-steering-controller: 2.38.0-1 → 2.39.0-1
  • ros-humble-ackermann-steering-controller-dbgsym: 2.38.0-1 → 2.39.0-1
  • ros-humble-admittance-controller: 2.38.0-1 → 2.39.0-1
  • ros-humble-admittance-controller-dbgsym: 2.38.0-1 → 2.39.0-1
  • ros-humble-autoware-common-msgs: 1.2.0-1 → 1.3.0-1
  • ros-humble-autoware-common-msgs-dbgsym: 1.2.0-1 → 1.3.0-1
  • ros-humble-autoware-control-msgs: 1.2.0-1 → 1.3.0-1
  • ros-humble-autoware-control-msgs-dbgsym: 1.2.0-1 → 1.3.0-1
  • ros-humble-autoware-localization-msgs: 1.2.0-1 → 1.3.0-1
  • ros-humble-autoware-localization-msgs-dbgsym: 1.2.0-1 → 1.3.0-1
  • ros-humble-autoware-map-msgs: 1.2.0-1 → 1.3.0-1
  • ros-humble-autoware-map-msgs-dbgsym: 1.2.0-1 → 1.3.0-1
  • ros-humble-autoware-perception-msgs: 1.2.0-1 → 1.3.0-1
  • ros-humble-autoware-perception-msgs-dbgsym: 1.2.0-1 → 1.3.0-1
  • ros-humble-autoware-planning-msgs: 1.2.0-1 → 1.3.0-1
  • ros-humble-autoware-planning-msgs-dbgsym: 1.2.0-1 → 1.3.0-1
  • ros-humble-autoware-sensing-msgs: 1.2.0-1 → 1.3.0-1
  • ros-humble-autoware-sensing-msgs-dbgsym: 1.2.0-1 → 1.3.0-1
  • ros-humble-autoware-system-msgs: 1.2.0-1 → 1.3.0-1
  • ros-humble-autoware-system-msgs-dbgsym: 1.2.0-1 → 1.3.0-1
  • ros-humble-autoware-v2x-msgs: 1.2.0-1 → 1.3.0-1
  • ros-humble-autoware-v2x-msgs-dbgsym: 1.2.0-1 → 1.3.0-1
  • ros-humble-autoware-vehicle-msgs: 1.2.0-1 → 1.3.0-1
  • ros-humble-autoware-vehicle-msgs-dbgsym: 1.2.0-1 → 1.3.0-1
  • ros-humble-bicycle-steering-controller: 2.38.0-1 → 2.39.0-1
  • ros-humble-bicycle-steering-controller-dbgsym: 2.38.0-1 → 2.39.0-1
  • ros-humble-camera-aravis2: 1.0.0-1 → 1.1.0-1
  • ros-humble-camera-aravis2-dbgsym: 1.0.0-1 → 1.1.0-1
  • ros-humble-camera-aravis2-msgs: 1.0.0-1 → 1.1.0-1
  • ros-humble-camera-aravis2-msgs-dbgsym: 1.0.0-1 → 1.1.0-1
  • ros-humble-camera-ros: 0.2.0-1 → 0.2.1-1
  • ros-humble-camera-ros-dbgsym: 0.2.0-1 → 0.2.1-1
  • ros-humble-clearpath-ros2-socketcan-interface: 1.0.0-1 → 1.0.1-2
  • ros-humble-clearpath-ros2-socketcan-interface-dbgsym: 1.0.0-1 → 1.0.1-2
  • ros-humble-control-toolbox: 3.3.0-1 → 3.4.0-1
  • ros-humble-control-toolbox-dbgsym: 3.3.0-1 → 3.4.0-1
  • ros-humble-controller-interface: 2.44.0-1 → 2.46.0-1
  • ros-humble-controller-interface-dbgsym: 2.44.0-1 → 2.46.0-1
  • ros-humble-controller-manager: 2.44.0-1 → 2.46.0-1
  • ros-humble-controller-manager-dbgsym: 2.44.0-1 → 2.46.0-1
  • ros-humble-controller-manager-msgs: 2.44.0-1 → 2.46.0-1
  • ros-humble-controller-manager-msgs-dbgsym: 2.44.0-1 → 2.46.0-1
  • ros-humble-dataspeed-can: 2.0.4-1 → 2.0.5-1
  • ros-humble-dataspeed-can-msg-filters: 2.0.4-1 → 2.0.5-1
  • ros-humble-dataspeed-can-msgs: 2.0.4-1 → 2.0.5-1
  • ros-humble-dataspeed-can-msgs-dbgsym: 2.0.4-1 → 2.0.5-1
  • ros-humble-dataspeed-can-tools: 2.0.4-1 → 2.0.5-1
  • ros-humble-dataspeed-can-tools-dbgsym: 2.0.4-1 → 2.0.5-1
  • ros-humble-dataspeed-can-usb: 2.0.4-1 → 2.0.5-1
  • ros-humble-dataspeed-can-usb-dbgsym: 2.0.4-1 → 2.0.5-1
  • ros-humble-diff-drive-controller: 2.38.0-1 → 2.39.0-1
  • ros-humble-diff-drive-controller-dbgsym: 2.38.0-1 → 2.39.0-1
  • ros-humble-effort-controllers: 2.38.0-1 → 2.39.0-1
  • ros-humble-effort-controllers-dbgsym: 2.38.0-1 → 2.39.0-1
  • ros-humble-etsi-its-cam-coding: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-cam-coding-dbgsym: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-cam-conversion: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-cam-msgs: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-cam-msgs-dbgsym: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-cam-ts-coding: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-cam-ts-coding-dbgsym: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-cam-ts-conversion: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-cam-ts-msgs: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-cam-ts-msgs-dbgsym: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-coding: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-conversion: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-conversion-dbgsym: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-cpm-ts-coding: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-cpm-ts-coding-dbgsym: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-cpm-ts-conversion: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-cpm-ts-msgs: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-cpm-ts-msgs-dbgsym: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-denm-coding: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-denm-coding-dbgsym: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-denm-conversion: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-denm-msgs: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-denm-msgs-dbgsym: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-messages: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-msgs: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-msgs-utils: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-primitives-conversion: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-rviz-plugins: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-rviz-plugins-dbgsym: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-vam-ts-coding: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-vam-ts-coding-dbgsym: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-vam-ts-conversion: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-vam-ts-msgs: 2.4.0-1 → 3.0.0-1
  • ros-humble-etsi-its-vam-ts-msgs-dbgsym: 2.4.0-1 → 3.0.0-1
  • ros-humble-force-torque-sensor-broadcaster: 2.38.0-1 → 2.39.0-1
  • ros-humble-force-torque-sensor-broadcaster-dbgsym: 2.38.0-1 → 2.39.0-1
  • ros-humble-forward-command-controller: 2.38.0-1 → 2.39.0-1
  • ros-humble-forward-command-controller-dbgsym: 2.38.0-1 → 2.39.0-1
  • ros-humble-foxglove-bridge: 0.8.1-1 → 0.8.2-1
  • ros-humble-foxglove-bridge-dbgsym: 0.8.1-1 → 0.8.2-1
  • ros-humble-franka-description: 0.2.0-1 → 0.4.0-3
  • ros-humble-game-controller-spl: 2.1.0-1 → 2.2.0-2
  • ros-humble-game-controller-spl-interfaces: 2.1.0-1 → 2.2.0-2
  • ros-humble-game-controller-spl-interfaces-dbgsym: 2.1.0-1 → 2.2.0-2
  • ros-humble-gc-spl: 2.1.0-1 → 2.2.0-2
  • ros-humble-gc-spl-2022: 2.1.0-1 → 2.2.0-2
  • ros-humble-gc-spl-interfaces: 2.1.0-1 → 2.2.0-2
  • ros-humble-gc-spl-interfaces-dbgsym: 2.1.0-1 → 2.2.0-2
  • ros-humble-geometric-shapes: 2.1.3-2 → 2.3.1-1
  • ros-humble-geometric-shapes-dbgsym: 2.1.3-2 → 2.3.1-1
  • ros-humble-gripper-controllers: 2.38.0-1 → 2.39.0-1
  • ros-humble-gripper-controllers-dbgsym: 2.38.0-1 → 2.39.0-1
  • ros-humble-hardware-interface: 2.44.0-1 → 2.46.0-1
  • ros-humble-hardware-interface-dbgsym: 2.44.0-1 → 2.46.0-1
  • ros-humble-hardware-interface-testing: 2.44.0-1 → 2.46.0-1
  • ros-humble-hardware-interface-testing-dbgsym: 2.44.0-1 → 2.46.0-1
  • ros-humble-imu-sensor-broadcaster: 2.38.0-1 → 2.39.0-1
  • ros-humble-imu-sensor-broadcaster-dbgsym: 2.38.0-1 → 2.39.0-1
  • ros-humble-joint-limits: 2.44.0-1 → 2.46.0-1
  • ros-humble-joint-limits-dbgsym: 2.44.0-1 → 2.46.0-1
  • ros-humble-joint-state-broadcaster: 2.38.0-1 → 2.39.0-1
  • ros-humble-joint-state-broadcaster-dbgsym: 2.38.0-1 → 2.39.0-1
  • ros-humble-joint-trajectory-controller: 2.38.0-1 → 2.39.0-1
  • ros-humble-joint-trajectory-controller-dbgsym: 2.38.0-1 → 2.39.0-1
  • ros-humble-kitti-metrics-eval: 1.2.1-1 → 1.3.0-1
  • ros-humble-kitti-metrics-eval-dbgsym: 1.2.1-1 → 1.3.0-1
  • ros-humble-mapviz: 2.4.3-1 → 2.4.4-1
  • ros-humble-mapviz-dbgsym: 2.4.3-1 → 2.4.4-1
  • ros-humble-mapviz-interfaces: 2.4.3-1 → 2.4.4-1
  • ros-humble-mapviz-interfaces-dbgsym: 2.4.3-1 → 2.4.4-1
  • ros-humble-mapviz-plugins: 2.4.3-1 → 2.4.4-1
  • ros-humble-mapviz-plugins-dbgsym: 2.4.3-1 → 2.4.4-1
  • ros-humble-marker-msgs: 0.0.8-3 → 0.0.8-1
  • ros-humble-marker-msgs-dbgsym: 0.0.8-3 → 0.0.8-1
  • ros-humble-mola: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-bridge-ros2: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-bridge-ros2-dbgsym: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-demos: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-imu-preintegration: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-imu-preintegration-dbgsym: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-input-euroc-dataset: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-input-euroc-dataset-dbgsym: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-input-kitti-dataset: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-input-kitti-dataset-dbgsym: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-input-kitti360-dataset: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-input-kitti360-dataset-dbgsym: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-input-mulran-dataset: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-input-mulran-dataset-dbgsym: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-input-paris-luco-dataset: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-input-paris-luco-dataset-dbgsym: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-input-rawlog: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-input-rawlog-dbgsym: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-input-rosbag2: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-input-rosbag2-dbgsym: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-kernel: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-kernel-dbgsym: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-launcher: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-launcher-dbgsym: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-metric-maps: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-metric-maps-dbgsym: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-msgs: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-msgs-dbgsym: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-navstate-fg: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-navstate-fg-dbgsym: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-navstate-fuse: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-navstate-fuse-dbgsym: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-pose-list: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-pose-list-dbgsym: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-relocalization: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-relocalization-dbgsym: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-traj-tools: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-traj-tools-dbgsym: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-viz: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-viz-dbgsym: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-yaml: 1.2.1-1 → 1.3.0-1
  • ros-humble-mola-yaml-dbgsym: 1.2.1-1 → 1.3.0-1
  • ros-humble-moveit-visual-tools: 4.1.0-1 → 4.1.1-1
  • ros-humble-moveit-visual-tools-dbgsym: 4.1.0-1 → 4.1.1-1
  • ros-humble-mrpt-apps: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-apps-dbgsym: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libapps: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libapps-dbgsym: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libbase: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libbase-dbgsym: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libgui: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libgui-dbgsym: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libhwdrivers: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libhwdrivers-dbgsym: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libmaps: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libmaps-dbgsym: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libmath: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libmath-dbgsym: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libnav: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libnav-dbgsym: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libobs: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libobs-dbgsym: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libopengl: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libopengl-dbgsym: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libposes: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libposes-dbgsym: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libros-bridge: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libros-bridge-dbgsym: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libslam: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libslam-dbgsym: 2.14.5-1 → 2.14.7-1
  • ros-humble-mrpt-libtclap: 2.14.5-1 → 2.14.7-1
  • ros-humble-multires-image: 2.4.3-1 → 2.4.4-1
  • ros-humble-multires-image-dbgsym: 2.4.3-1 → 2.4.4-1
  • ros-humble-mvsim: 0.11.1-1 → 0.12.0-1
  • ros-humble-mvsim-dbgsym: 0.11.1-1 → 0.12.0-1
  • ros-humble-off-highway-can: 0.6.3-1 → 0.7.0-1
  • ros-humble-off-highway-can-dbgsym: 0.6.3-1 → 0.7.0-1
  • ros-humble-off-highway-general-purpose-radar: 0.6.3-1 → 0.7.0-1
  • ros-humble-off-highway-general-purpose-radar-dbgsym: 0.6.3-1 → 0.7.0-1
  • ros-humble-off-highway-general-purpose-radar-msgs: 0.6.3-1 → 0.7.0-1
  • ros-humble-off-highway-general-purpose-radar-msgs-dbgsym: 0.6.3-1 → 0.7.0-1
  • ros-humble-off-highway-premium-radar-sample: 0.6.3-1 → 0.7.0-1
  • ros-humble-off-highway-premium-radar-sample-dbgsym: 0.6.3-1 → 0.7.0-1
  • ros-humble-off-highway-premium-radar-sample-msgs: 0.6.3-1 → 0.7.0-1
  • ros-humble-off-highway-premium-radar-sample-msgs-dbgsym: 0.6.3-1 → 0.7.0-1
  • ros-humble-off-highway-radar: 0.6.3-1 → 0.7.0-1
  • ros-humble-off-highway-radar-dbgsym: 0.6.3-1 → 0.7.0-1
  • ros-humble-off-highway-radar-msgs: 0.6.3-1 → 0.7.0-1
  • ros-humble-off-highway-radar-msgs-dbgsym: 0.6.3-1 → 0.7.0-1
  • ros-humble-off-highway-sensor-drivers: 0.6.3-1 → 0.7.0-1
  • ros-humble-off-highway-sensor-drivers-examples: 0.6.3-1 → 0.7.0-1
  • ros-humble-off-highway-sensor-drivers-examples-dbgsym: 0.6.3-1 → 0.7.0-1
  • ros-humble-off-highway-uss: 0.6.3-1 → 0.7.0-1
  • ros-humble-off-highway-uss-dbgsym: 0.6.3-1 → 0.7.0-1
  • ros-humble-off-highway-uss-msgs: 0.6.3-1 → 0.7.0-1
  • ros-humble-off-highway-uss-msgs-dbgsym: 0.6.3-1 → 0.7.0-1
  • ros-humble-openvdb-vendor: 2.3.2-1 → 2.3.3-1
  • ros-humble-openvdb-vendor-dbgsym: 2.3.2-1 → 2.3.3-1
  • ros-humble-pal-statistics: 2.5.0-1 → 2.6.0-1
  • ros-humble-pal-statistics-dbgsym: 2.5.0-1 → 2.6.0-1
  • ros-humble-pal-statistics-msgs: 2.5.0-1 → 2.6.0-1
  • ros-humble-pal-statistics-msgs-dbgsym: 2.5.0-1 → 2.6.0-1
  • ros-humble-pick-ik: 1.1.0-1 → 1.1.1-1
  • ros-humble-pick-ik-dbgsym: 1.1.0-1 → 1.1.1-1
  • ros-humble-pid-controller: 2.38.0-1 → 2.39.0-1
  • ros-humble-pid-controller-dbgsym: 2.38.0-1 → 2.39.0-1
  • ros-humble-pinocchio: 2.6.21-1 → 3.3.0-1
  • ros-humble-pinocchio-dbgsym: 2.6.21-1 → 3.3.0-1
  • ros-humble-pose-broadcaster: 2.38.0-1 → 2.39.0-1
  • ros-humble-pose-broadcaster-dbgsym: 2.38.0-1 → 2.39.0-1
  • ros-humble-position-controllers: 2.38.0-1 → 2.39.0-1
  • ros-humble-position-controllers-dbgsym: 2.38.0-1 → 2.39.0-1
  • ros-humble-python-mrpt: 2.14.5-1 → 2.14.7-1
  • ros-humble-range-sensor-broadcaster: 2.38.0-1 → 2.39.0-1
  • ros-humble-range-sensor-broadcaster-dbgsym: 2.38.0-1 → 2.39.0-1
  • ros-humble-rcgcd-spl-14: 2.1.0-1 → 2.2.0-2
  • ros-humble-rcgcd-spl-14-conversion: 2.1.0-1 → 2.2.0-2
  • ros-humble-rcgcd-spl-14-dbgsym: 2.1.0-1 → 2.2.0-2
  • ros-humble-rcgcrd-spl-4: 2.1.0-1 → 2.2.0-2
  • ros-humble-rcgcrd-spl-4-conversion: 2.1.0-1 → 2.2.0-2
  • ros-humble-rcgcrd-spl-4-dbgsym: 2.1.0-1 → 2.2.0-2
  • ros-humble-realtime-tools: 2.8.1-1 → 2.10.0-1
  • ros-humble-realtime-tools-dbgsym: 2.8.1-1 → 2.10.0-1
  • ros-humble-robot-calibration: 0.8.2-1 → 0.8.3-1
  • ros-humble-robot-calibration-dbgsym: 0.8.2-1 → 0.8.3-1
  • ros-humble-robot-calibration-msgs: 0.8.2-1 → 0.8.3-1
  • ros-humble-robot-calibration-msgs-dbgsym: 0.8.2-1 → 0.8.3-1
  • ros-humble-ros-gz: 0.244.15-1 → 0.244.16-2
  • ros-humble-ros-gz-bridge: 0.244.15-1 → 0.244.16-2
  • ros-humble-ros-gz-bridge-dbgsym: 0.244.15-1 → 0.244.16-2
  • ros-humble-ros-gz-image: 0.244.15-1 → 0.244.16-2
  • ros-humble-ros-gz-image-dbgsym: 0.244.15-1 → 0.244.16-2
  • ros-humble-ros-gz-interfaces: 0.244.15-1 → 0.244.16-2
  • ros-humble-ros-gz-interfaces-dbgsym: 0.244.15-1 → 0.244.16-2
  • ros-humble-ros-gz-sim: 0.244.15-1 → 0.244.16-2
  • ros-humble-ros-gz-sim-dbgsym: 0.244.15-1 → 0.244.16-2
  • ros-humble-ros-gz-sim-demos: 0.244.15-1 → 0.244.16-2
  • ros-humble-ros-ign: 0.244.15-1 → 0.244.16-2
  • ros-humble-ros-ign-bridge: 0.244.15-1 → 0.244.16-2
  • ros-humble-ros-ign-bridge-dbgsym: 0.244.15-1 → 0.244.16-2
  • ros-humble-ros-ign-gazebo: 0.244.15-1 → 0.244.16-2
  • ros-humble-ros-ign-gazebo-dbgsym: 0.244.15-1 → 0.244.16-2
  • ros-humble-ros-ign-gazebo-demos: 0.244.15-1 → 0.244.16-2
  • ros-humble-ros-ign-image: 0.244.15-1 → 0.244.16-2
  • ros-humble-ros-ign-image-dbgsym: 0.244.15-1 → 0.244.16-2
  • ros-humble-ros-ign-interfaces: 0.244.15-1 → 0.244.16-2
  • ros-humble-ros-ign-interfaces-dbgsym: 0.244.15-1 → 0.244.16-2
  • ros-humble-ros2-control: 2.44.0-1 → 2.46.0-1
  • ros-humble-ros2-control-test-assets: 2.44.0-1 → 2.46.0-1
  • ros-humble-ros2-controllers: 2.38.0-1 → 2.39.0-1
  • ros-humble-ros2-controllers-test-nodes: 2.38.0-1 → 2.39.0-1
  • ros-humble-ros2controlcli: 2.44.0-1 → 2.46.0-1
  • ros-humble-rqt-controller-manager: 2.44.0-1 → 2.46.0-1
  • ros-humble-rqt-joint-trajectory-controller: 2.38.0-1 → 2.39.0-1
  • ros-humble-rtabmap: 0.21.6-1 → 0.21.9-1
  • ros-humble-rtabmap-conversions: 0.21.5-1 → 0.21.9-1
  • ros-humble-rtabmap-conversions-dbgsym: 0.21.5-1 → 0.21.9-1
  • ros-humble-rtabmap-dbgsym: 0.21.6-1 → 0.21.9-1
  • ros-humble-rtabmap-demos: 0.21.5-1 → 0.21.9-1
  • ros-humble-rtabmap-examples: 0.21.5-1 → 0.21.9-1
  • ros-humble-rtabmap-launch: 0.21.5-1 → 0.21.9-1
  • ros-humble-rtabmap-msgs: 0.21.5-1 → 0.21.9-1
  • ros-humble-rtabmap-msgs-dbgsym: 0.21.5-1 → 0.21.9-1
  • ros-humble-rtabmap-odom: 0.21.5-1 → 0.21.9-1
  • ros-humble-rtabmap-odom-dbgsym: 0.21.5-1 → 0.21.9-1
  • ros-humble-rtabmap-python: 0.21.5-1 → 0.21.9-1
  • ros-humble-rtabmap-ros: 0.21.5-1 → 0.21.9-1
  • ros-humble-rtabmap-rviz-plugins: 0.21.5-1 → 0.21.9-1
  • ros-humble-rtabmap-rviz-plugins-dbgsym: 0.21.5-1 → 0.21.9-1
  • ros-humble-rtabmap-slam: 0.21.5-1 → 0.21.9-1
  • ros-humble-rtabmap-slam-dbgsym: 0.21.5-1 → 0.21.9-1
  • ros-humble-rtabmap-sync: 0.21.5-1 → 0.21.9-1
  • ros-humble-rtabmap-sync-dbgsym: 0.21.5-1 → 0.21.9-1
  • ros-humble-rtabmap-util: 0.21.5-1 → 0.21.9-1
  • ros-humble-rtabmap-util-dbgsym: 0.21.5-1 → 0.21.9-1
  • ros-humble-rtabmap-viz: 0.21.5-1 → 0.21.9-1
  • ros-humble-rtabmap-viz-dbgsym: 0.21.5-1 → 0.21.9-1
  • ros-humble-slam-toolbox: 2.6.8-1 → 2.6.9-1
  • ros-humble-slam-toolbox-dbgsym: 2.6.8-1 → 2.6.9-1
  • ros-humble-spatio-temporal-voxel-layer: 2.3.2-1 → 2.3.3-1
  • ros-humble-spatio-temporal-voxel-layer-dbgsym: 2.3.2-1 → 2.3.3-1
  • ros-humble-steering-controllers-library: 2.38.0-1 → 2.39.0-1
  • ros-humble-steering-controllers-library-dbgsym: 2.38.0-1 → 2.39.0-1
  • ros-humble-tile-map: 2.4.3-1 → 2.4.4-1
  • ros-humble-tile-map-dbgsym: 2.4.3-1 → 2.4.4-1
  • ros-humble-transmission-interface: 2.44.0-1 → 2.46.0-1
  • ros-humble-transmission-interface-dbgsym: 2.44.0-1 → 2.46.0-1
  • ros-humble-tricycle-controller: 2.38.0-1 → 2.39.0-1
  • ros-humble-tricycle-controller-dbgsym: 2.38.0-1 → 2.39.0-1
  • ros-humble-tricycle-steering-controller: 2.38.0-1 → 2.39.0-1
  • ros-humble-tricycle-steering-controller-dbgsym: 2.38.0-1 → 2.39.0-1
  • ros-humble-tuw-geometry: 0.1.1-1 → 0.1.2-1
  • ros-humble-tuw-geometry-dbgsym: 0.1.1-1 → 0.1.2-1
  • ros-humble-ur-description: 2.1.8-2 → 2.1.9-1
  • ros-humble-ur-msgs: 2.0.1-1 → 2.1.0-1
  • ros-humble-ur-msgs-dbgsym: 2.0.1-1 → 2.1.0-1
  • ros-humble-velocity-controllers: 2.38.0-1 → 2.39.0-1
  • ros-humble-velocity-controllers-dbgsym: 2.38.0-1 → 2.39.0-1
  • ros-humble-wireless-msgs: 1.1.1-1 → 1.1.2-1
  • ros-humble-wireless-msgs-dbgsym: 1.1.1-1 → 1.1.2-1
  • ros-humble-wireless-watcher: 1.1.1-1 → 1.1.2-1
  • ros-humble-wireless-watcher-dbgsym: 1.1.1-1 → 1.1.2-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:

  • Alejandro Hernandez
  • Apex.AI, Inc.
  • Bence Magyar
  • Boston Dynamics AI Institute
  • Brandon Ong
  • Christian Rauch
  • Dave Coleman
  • Felix Exner
  • Franka Robotics GmbH
  • G.A. vd. Hoorn
  • Guilhem Saurel
  • Hans-Joachim Krauch
  • Jean-Pierre Busch
  • Jordan Palacios
  • Jose Luis Blanco-Claraco
  • Jose-Luis Blanco-Claraco
  • Justin Carpentier
  • Kevin Hallenbeck
  • Louise Poubel
  • Luis Camero
  • M. Fatih Cırıt
  • Markus Bader
  • Mathieu Labbe
  • Michael Ferguson
  • Micho Radovnikovich
  • Miguel Ángel González Santamarta
  • Raphael Hagmanns
  • Robin Petereit
  • Roni Kreinin
  • Sarah Huber
  • Southwest Research Institute
  • Steve Macenski
  • Takagi, Isamu
  • Tim Clephas
  • Tyler Weaver
  • Yutaka Kondo
  • ijnek
  • kminoda
  • miguel
  • rkreinin

1 post - 1 participant

Read full topic

[WWW] https://discourse.ros.org/t/new-packages-for-humble-hawksbill-2024-12-20/41214

ROS Discourse General: World Magnetic Model 2025 released (and WMM2020 ending very soon!)

If you’re using magnetometers and World Magnetic Model on your robots, pay attention!

The World Magnetic Model 2025 (with validity 2025-2030) has been released by NOAA a few days ago (they made it before DOGE starts biting :smiley: ).

What’s more important, WMM2020 validity ends on 31 Dec 2024. If you’re using the model and check for validity, it is time to update pretty fast! If you don’t check date validity, your model will probably still work fine, but the error would be larger and larger.

If you’re using GeographicLib, it hasn’t adopted the new model yet, but the data are already provided by a side-channel: How to apply WMM2025 model in GeographicLib? · Issue #34 · geographiclib/geographiclib · GitHub .

If you’re using magnetic_model ROS package, WMM2025 will be included in its next release.

4 posts - 2 participants

Read full topic

[WWW] https://discourse.ros.org/t/world-magnetic-model-2025-released-and-wmm2020-ending-very-soon/41211

ROS Discourse General: Time to give your magnetometers a big refresh!

Are you using magnetometers on your robot? And are you using them right? Did you know each magnetometer has a bias that needs to be removed?

I’d like to announce the release of our suite of magnetometer tools that could be helpful to lots of people who deal with outdoor navigation.

The release is for ROS Noetic currently. We’ll definitely port the stack to ROS 2 some time next year.

I’ll be happy for feedback!

magnetometer_pipeline

To calibrate your magnetometer (i.e. identify its bias), use node magnetometer_pipeline/ magnetometer_bias_observer . Just spin up the node, call service /calibrate_magnetometer and you have 30 seconds to rotate your robot about as many axes as you can. This corresponds to the 8-shape phones sometimes want you to do.

Using a magnetometer without calibration is bad, bad, bad! The outputs are usually pretty much nonsense. Do not do it.

Once the magnetometer is calibrated, bias is published on topic /imu/mag_bias. Node (and nodelet) magnetometer_pipeline/magnetometer_bias_remover can take the raw /imu/mag data and remove the bias from them, providing topic /imu/mag_unbiased.

magnetometer_compass

To convert the magnetometer measurement to a heading, use node(let) magnetometer_compass/magnetometer_compass. It eats /imu/mag_unbiased and /imu/data (with orientation) and extracts azimuth (heading).

As there are multiple possible ways to express azimuths, magnetometer_compass supports all imaginable combinations:

Azimuth reference:

  • Magnetic North (compliant with physical compasses)
  • Geographic (true) North (compliant with maps)
  • UTM North (compliant with the UTM projection - a Cartesian projection of Earth, used e.g. by robot_localization)

Azimuth orientation:

  • ENU (East-North-Up, compliant with REP-103)
  • NED (North-East-Down, compliant with physical compasses)

Units:

  • degrees (compliant with humans)
  • radians (compliant with REP-103)

Output data types:

To be able to convert between magnetic and true North, magnetic declination needs to be known. This value depends on GNSS position, so the compass node can eat NavSatFix messages which tell it where the robot is. Or, if the position is predictable/static, you can set it as a config parameter and then you don’t need to provide the NavSatFix messages. The resolution of the magnetic model is ~3500 km, so you don’t need to be very precise here.

Magnetometer measurements can be quite noisy. Therefore, magnetometer_compass contains a built-in low-pass filter with configurable strength to make the azimuth reading a bit more stable.

Once you get the magnetometer_compass running, you might want to visualize its output using magnetometer_compass/visualize_azimuth, which can eat any of the above-defined outputs.

Some magnetometer drivers (ethzasl_xsens_driver, I’m looking at you) mix up the units in the magnetometer part and report in Gauss instead of Tesla (1 T = 10000 G). Fortunately, for just identifying the azimuth, this is no problem!

compass_conversions

As can be seen above, there are quite a lot of ways to express an azimuth. compass_conversions provide a C++ library, message filter and nodelet that can convert any kind of azimuth to any other kind.

Using the message filter, it is quite simple to subscribe to any kind of azimuth representation and get the one you actually need in your code:

message_filters::Subscriber azimuthInput(...);
message_filters::Subscriber fixInput(...);
compass_conversions::CompassFilter filter(log, nullptr, azimuthInput, fixInput,
  compass_msgs::Azimuth::UNIT_RAD, compass_msgs::Azimuth::ORIENTATION_ENU,
  compass_msgs::Azimuth::REFERENCE_GEOGRAPHIC);
filter.registerCallback([](const compass_msgs::AzimuthConstPtr& msg) {
  ...  // Handle the data which come geographic-referenced, ENU oriented, in radians
});

Analogically, you can spin up compass_conversions/compass_transformer to do this conversion at the ROS API level.

magnetic_model

Converting magnetic North to true North requires knowing the magnetic declination. This is a value provided by World Magnetic Model. magnetic_model is a C++ library that provides easy usage of the model with ROS data types. In addition to what GeographicLib already provides, magnetic_model also knows the error model of the conversion, so it can also tell you the variance of the conversion.

This package comes with all available releases of WMM preinstalled, so there’s no need to get the data elsewhere. But it still supports customizing the path to the folder with models - just in case you need to use something different.

1 post - 1 participant

Read full topic

[WWW] https://discourse.ros.org/t/time-to-give-your-magnetometers-a-big-refresh/41208

ROS Discourse General: New Packages for Noetic 2024-12-19

We’re happy to announce 10 new packages and 79 updates are now available in ROS Noetic. This sync was tagged as noetic/2024-12-19.

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

Package Updates for ROS Noetic

Added Packages [10]:

Updated Packages [79]:

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:

  • Atsushi Watanabe
  • Felix Exner
  • Guilhem Saurel
  • Iori Yanokura
  • Jean-Pierre Busch
  • Jose-Luis Blanco-Claraco
  • Justin Carpentier
  • Kei Okada
  • Martin Pecka
  • Noda Shintaro
  • Ryohei Ueda
  • Shingo Kitagawa
  • Shunichi Nozawa
  • YoheiKakiuchi
  • Yuki Furuta
  • Yusuke Furuta
  • furuta
  • nozawa

1 post - 1 participant

Read full topic

[WWW] https://discourse.ros.org/t/new-packages-for-noetic-2024-12-19/41203

ROS Discourse General: How do you monitor your robot diagnostics (topic rates)?

Hi all!

What kind of tools do you use to monitor your robots in runtime? I’m especially interested in monitoring ROS 2 topic rates to confirm for example that all the sensors are publishing data correctly.

I’m looking for a solution that could do this without large overhead, and that would preferably work “from outside”, without injecting code to the subscriptions/publishers. It should publish ROS Diagnostics messages if the expected rates are below the given thresholds.

Is there a solution that can already do this? I’ve so far checked for example ROS 2 built-in Topic Statistics and ros2_tracing, but they don’t seem to fulfill these requirements.

I would be also interested in hearing how you monitor the other aspects of your robots, such as network usage, Node health, etc.

11 posts - 8 participants

Read full topic

[WWW] https://discourse.ros.org/t/how-do-you-monitor-your-robot-diagnostics-topic-rates/41191

ROS Discourse General: Next Client Library WG Meeting: Friday 20th December 2024 8AM PT

Hi,
The next meeting of the Client Library Working Group will be this Friday, 20th December 2024 at 8 AM Pacific Time.

The Client Library Working Group has also become the first official WG under the new OSRA and ROS PMC organization!

10 posts - 5 participants

Read full topic

[WWW] https://discourse.ros.org/t/next-client-library-wg-meeting-friday-20th-december-2024-8am-pt/41179

ROS Discourse General: ROS 2 Visualization Tools for Architecture

Hello everyone,

I was wondering what kind of visualizations tools do you use or are aware to see the architecture of a ROS 2 system?

For instance, if you would like to see the connections between nodes and topics (e.g., I know that rqt can show that), visualize messages flow, parameters, or even documentation.

Thank you!
Paulo

3 posts - 3 participants

Read full topic

[WWW] https://discourse.ros.org/t/ros-2-visualization-tools-for-architecture/41170

ROS Discourse General: Global Robot Density in Factories Doubled in Seven Years - What's the impact of ROS?

Has anybody read this news? What’s your opinion on the impact of ROS here?

+++

Global Robot Density in Factories Doubled in Seven Years

New World Robotics Data by International Federation of Robotics reveal

Frankfurt, Nov 20, 2024 — Robot adoption in factories around the world continues at high speed: The new global average robot density reaches a record 162 units per 10,000 employees in 2023 - more than double the number measured only seven years ago (74 units). This is according to the World Robotics 2024 report, presented by the International Federation of Robotics (IFR).

Robot density serves as a barometer to track the degree of automation adoption in the manufacturing industry around the world," says Takayuki Ito, President of the International Federation of Robotics. “This year’s runner-up is China, which ranks third worldwide behind Korea and Singapore, but right up with Germany and Japan."

Robot density by region

The European Union has a robot density of 219 units per 10,000 employees, an increase of 5.2%, with Germany, Sweden, Denmark and Slovenia in the global top ten.

North America´s robot density is 197 units per 10,000 employees – up 4,2%. The United States ranks tenth in the world among the most automated countries in the manufacturing industry.

Asia has a robot density of 182 units per 10,000 persons employed in manufacturing - an increase of 7.6%. The economies of Korea, Singapore, mainland China and Japan are among the top ten most automated countries.

Top countries

The Republic of Korea is the world´s number one adopter of industrial robots with 1,012 robots per 10,000 employees. Robot density has increased by 5% on average each year since 2018. With a world-renowned electronics industry and a strong automotive industry, the Korean economy relies on the two largest customers for industrial robots.

Singapore follows with 770 robots per 10,000 employees. Singapore is a small country with a very low number of employees in the manufacturing industry, so it can reach a high Robot density also with a relatively small operational stock.

China took third place in 2023, surpassing Germany and Japan. The country’s push to the use of automation technology results in a high robot density of 470 robots per 10,000 employees (2022: 402 units). China only entered the top 10 in 2019. It has managed to double its robot density within four years.

Germany ranks fourth with 429 robots per 10,000 employees. The robot density of Europe´s largest economy has grown by 5% CAGR since 2018.

Japan is in fifth place with 419 units. Robot density of the world´s predominant robot manufacturing country grew by 7% on average each year (2018-2023).

Robot density in the United States reached 295 units in 2023. The country ranks tenth in the world.

About Robot density

Robot density is the number of operational industrial robots relative to the number of employees. It can cover the whole manufacturing industry or just specific industrial branches. The number of employees serves as a measure of economic size, so the quotient of operational stock over employees puts the operational stock on a uniform base.

1 post - 1 participant

Read full topic

[WWW] https://discourse.ros.org/t/global-robot-density-in-factories-doubled-in-seven-years-whats-the-impact-of-ros/41123

ROS Discourse General: Is there a ROS 2 gazebo project for humanoids robots?

Dear ROS community,

I was researching if there are ROS 2 Gazebo project for humanoid robots that would facilitate in learning robot locomotion and whole-body motion planning. I am looking towards humanoids similar to Unitree’s H1/H2.

A research scientist from ETH Zurich pointed me to the Issac Gym environment that comes with the assets for H1/H2. But as far as I understand, that simulation pipeline does not use any ROS, and is meant for RL like research.

The closet project I found was Unitree’s ROS 1 project GitHub - unitreerobotics/unitree_ros but it has not been updated for the newer ROS 2 and Gazebo.

Thank you for your time.

With best,
Azmyin

4 posts - 3 participants

Read full topic

[WWW] https://discourse.ros.org/t/is-there-a-ros-2-gazebo-project-for-humanoids-robots/41094

ROS Discourse General: Opinion on companies still using ROS1

I would like to read what you think about taking a Job in companies who work extensively with ROS, but for one reason or another they are still in ROS1.
On one hand I realize that ROS is just a framework and that a lot can still be done and learned.
On the other, having worked for some years on both ROS and ROS2 I see the benefits of working with ROS2.
So I am torn and would like to hear other voices on the matter.

16 posts - 12 participants

Read full topic

[WWW] https://discourse.ros.org/t/opinion-on-companies-still-using-ros1/41079

ROS Discourse General: ROS News for the Week of December 9th, 2024

ROS News for the Week of December 9th, 2024


image

:cn: :tada: Our first ever ROSCon in China happened in Shanghai over the weekend! We want to congratulate the organizers on orchestrating such an impressive event. You can find a recap of ROSCon China here.

May 2023 - Nov 2024

ROS 2 Iron Irwini is now officially end-of-life. If you are currently using Iron please consider upgrading to Jazzy!


harp2
Check out the HARP2 robot that was posted to the ROS Discord server yesterday. The developer’s website is full of really great posts that are worth checking out, especially on the topic of microROS.


poster-thumbnail

The team behind TidyBot2 at Stanford and Princeton have open sourced the hardware for their robot. The robot supports a variety of arms and configurations allowing you to build a clone using hardware you may already have in the lab. See the docs for more details.


image

This week ROS Industrial released a comprehensive list of depth cameras for robotics applications. Even if you don’t need a new depth camera I recommend bookmarking this website for future website.


image

I want to send a big shout out @abaeyens for putting together this fantastic documentation on ROS 2 integration testing for docs.ros.org. :tada:

People often ask us how they can best contribute to the project. My recommendation is that when you run across something that feels not poorly documented take the time to summarize what you learned while figuring out how to solve the problem. That’s exactly what @abaeyens
did in this case and the results are excellent.


Events

News

ROS

Got a minute? :alarm_clock:

All we want for Christmas are pull requests to the ROS 2 docs. :gift:

1 post - 1 participant

Read full topic

[WWW] https://discourse.ros.org/t/ros-news-for-the-week-of-december-9th-2024/41073

ROS Discourse General: Call for “IFR’s Women in Robotics: 10 Women Shaping the Future of Robotics in 2025” is now open

Call for “IFR’s Women in Robotics: 10 Women Shaping the Future of Robotics in 2025” is now open

The International Federation of Robotics (IFR) is looking for outstanding women in robotics

Dec 10, 2024 — IFR would like to highlight and honor Women in Robotics - in particular women in the robotics industry - and give them more visibility. IFR will select a list of 10 women to officially award as “IFR’s Women in Robotics: 10 Women Shaping the Future of Robotics” in 2025.

IFR decided to give women in robotics more visibility and acknowledgment. This should inspire girls and young women to pursue a career in STEM subjects or robotics and will also help companies to reach gender equality and overcome shortage of staff.

IFR would like to highlight and honor Women in Robotics - in particular women in the robotics industry - and give them more visibility.
IFR will select a list of 10 women to officially award as “IFR’s Women in Robotics: 10 Women Shaping the Future of Robotics” in 2025.

IRF is in particular looking for women that have either a proven track record in robotics, stand out as industry leader or women with a proven activity in encouraging young people to go into STEM or that somehow support females in robotics.

Deadline for submission is January 31st, 2025.

How to submit a suggestion

Send an email to secretariat@ifr.org
include a short bio and a description of what makes her noteworthy or particular with respect to our described scope
add her full name, affiliation, country, contact details and a photo

Selection criteria:

  • The suggested women needs to be active in the robotics industry
  • IFR will select at least one per continent,
  • but a maximum of one woman per company,
  • consider different company sizes (large, medium, small)
  • consider different company scope (Robot supplier IR, SR, component supplier, integrator) and
  • consider different levels of hierarchy (C-level, intermediate, lower level)
  • Proven track record in robotics / stand out as industry leader
  • Proven activity in encouraging young people to go into STEM or that somehow support females in robotics

Publication of results will be on International Women’s Day - March 8th, 2025.

IFR’s 2024 Women in Robotics

Learn more on why gender balance is beneficial for economies

1 post - 1 participant

Read full topic

[WWW] https://discourse.ros.org/t/call-for-ifr-s-women-in-robotics-10-women-shaping-the-future-of-robotics-in-2025-is-now-open/41068

ROS Discourse General: REUSE compatibility vs multi-package repo

Hi. I’ve started trying to have my repos REUSE-compliant.

It seems that single-package repos can easily be turned into REUSE-compliant by adding all the SPDX comments to files, moving the top-level LICENSE file into LICENSES/BSD-3-Clause.txt and specifying <license file="LICENSES/BSD-3-Clause.txt">BSD</license> in package.xml.

However, if I want to do the same for a multi-package repo, then the LICENSES folder has to be a top-level one, i.e. at the same level as are the packages (that is a REUSE requirement). At the same time, I’d like to not have to copy all licenses to each package - as it’s best if each is stored only once. However, if I put <license file="../LICENSES/BSD-3-Clause.txt"> in package.xml, then bloom-release fails not being able to find the license file. That’s because it builds each package from the repo in a separate directory that is moved outside the repo.

I don’t see a clean solution how to satisfy both REUSE and bloom (except not adding the file= attribute, but I’d like to keep it). My current dirty workaround is to just copy the license file into the root of each subpackage. That’s not nice, but it does the job.

Does anybody know of a cleaner solution? I think it would be very nice if ROS deployment process would be compatible with REUSE.

6 posts - 3 participants

Read full topic

[WWW] https://discourse.ros.org/t/reuse-compatibility-vs-multi-package-repo/41063

ROS Discourse General: Optimizations cpp ROS2 node. colcon build

I’ve been using ROS2 for a year. Maybe previously you guys talked about this. However I’ve done experimental tests about the optimization C++ code ROS2 node and wrote a simple node.

#include "rclcpp/rclcpp.hpp"

class HelloWorldNode : public rclcpp::Node
{
public:
    HelloWorldNode() : Node("hello_world_node")
    {
        RCLCPP_INFO(this->get_logger(), "Hello, World! This is a ROS2 node.");
    }
};

int main(int argc, char **argv)
{
    rclcpp::init(argc, argv);
    rclcpp::spin(std::make_shared<HelloWorldNode>());
    rclcpp::shutdown();
    return 0;
}

Then by simply building the above code by using

colcon build

I got hello_node then explored assemble code

objdump -d <path>/hello_node > hello_node.asm

got around 5000 lines of instruction code in hello_node.asm, it seems like it didn’t do any optimization to the code. Then run the following command

colcon build --cmake-args -DCMAKE_BUILD_TYPE=Release
///alternative
colcon build --cmake-args -DCMAKE_CXX_FLAGS="-O3 -march=native"

then looked number instructions lines the number dramatically decreased from 5000 to 1700. the number of instruction lines in assemble doesn’t always mean it’s optimized yet it’s good factor.

Screenshot from 2024-12-11 16-24-11

“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”“”"
simple by adding “set(CMAKE_BUILD_TYPE Release)” to your CMakeLists.txt is enough. then you can simply use colcon build.
Optimizations flags

8 posts - 7 participants

Read full topic

[WWW] https://discourse.ros.org/t/optimizations-cpp-ros2-node-colcon-build/41048

ROS Discourse General: :checkered_flag: Gazebo Garden officially end-of-life [x-post Gazebo Sim Community]

Original Post

Dear ROS Community,

Gazebo Garden has reached end-of-life (EOL) as of November, 2024. Garden was the seventh major release of Gazebo and was supported for two years (non-LTS). It was the first release where Ignition was renamed Gazebo. It also introduced various exciting features, including custom shader plugins, Reset API, DEM support, lunar and custom surface coordinates, glTF and GLB mesh support, and an acoustic communication plugin, just to name a few. See the entire list of features on the Release Features page.

We recommend all Garden users migrate to a supported release as soon as possible, such as Harmonic (LTS) or Ionic, which are paired with ROS Jazzy and Rolling (Kilted once released) respectively. Migrating to either Harmonic or Ionic should be fairly smooth, however, be sure to check the release highlights for Harmonic and Ionic in addition to checking each Gazebo library’s migration guide.

As part of the Garden EOL, the following Gazebo libraries have also reached end-of-life. Their latest released binaries will remain available at http://packages.osrfoundation.org/, but no more fixes or releases will be made.

Library major version Final release
gz-fuel-tools8 8.2.0
gz-sim7 7.9.0
gz-gui7 7.2.2
gz-launch6 6.2.0
gz-msgs9 9.5.1
gz-physics6 6.7.0
gz-rendering7 7.5.0
gz-sensors7 7.3.1
gz-transport12 12.2.2
sdformat13 13.9.0

We sincerely thank all contributors to all libraries in Garden :pray:

What does End of Life Mean?

Users often ask us, “what does end of life mean?” To put it briefly, end of life means that the Gazebo team will no longer support that particular Gazebo release. In practical terms, this means that we will no longer be providing the following for Gazebo Garden:

  • New features or capabilities
  • Security updates
  • Bug fixes, patches or support
  • Updated binaries

It is also worth noting the things that won’t change after Gazebo Garden goes end of life:

  • Gazebo Garden binaries will not suddenly disappear
  • Users will not need to migrate immediately, but they should migrate as soon as possible

:gazebo: Gazebo Dev Team :gazebo:

1 post - 1 participant

Read full topic

[WWW] https://discourse.ros.org/t/gazebo-garden-officially-end-of-life-x-post-gazebo-sim-community/41044

ROS Discourse General: How important is ROS when searching for a job?

I have made an analysis of almost 2.000 jobs in LinkedIn and found out how relevant is ROS for getting a job as a robotics software developer. I included other interesting data about what matters for companies posting robotics jobs.

Check all that data in this video: https://youtu.be/wDeVNsD73A4?si=wcD3F1FizuJ52K3e

Podcast-video-2024-Ricardo-Tellez-the-truth-about-ROS-jobs

1 post - 1 participant

Read full topic

[WWW] https://discourse.ros.org/t/how-important-is-ros-when-searching-for-a-job/41032

Wiki: TullyFoote/TestPlanetRSS (last edited 2014-09-25 22:49:53 by TullyFoote)

Except where otherwise noted, the ROS wiki is licensed under the
Creative Commons Attribution 3.0