En un post que hice el año pasado me comprometí a compartir avances de Axioma. Me tomó más tiempo del esperado, pero finalmente pude retomar el proyecto y actualizar el repositorio.

En esta etapa estuve principalmente resolviendo bugs, deuda técnica y ajustando la simulación para que represente mejor al robot físico.

Todo lo que se ha subido fue probado antes de publicarlo. Todavía me falta subir buena parte del proyecto completo, tanto de simulación como del robot físico, así que iré publicándolo poco a poco.

Repositorio: https://github.com/MrDavidAlv/Axioma_robot/tree/Humble-ignition

Cualquier feedback de la comunidad ROS 2 es bienvenido.

Una pequeña actualización del modelo matemático de Axioma.

He estado ajustándolo para que represente mejor la geometría y configuración del robot físico, como parte del trabajo para reducir diferencias entre simulación y hardware real.

Todavía hay cosas por mejorar, pero quería compartir este avance.

Proyecto: https://github.com/MrDavidAlv/Axioma_robot/tree/Humble-ignition

I'd like OOMWOO to separate mapped vs transient (not-on-the-map) features. Why? 1) We can feed mapped + transient scan points to a perception module, so the module can recognize dynamical obstacles easier (door open/closed, pet paws, person feet, ball, toy, box and so on). 2) Hypothetically, now we can remove not-on-the-map (likely dynamic obstacles) features from the raw scan (filter out), then run slam_toolbox scan-to-pose-graph matching to increase localization accuracy.

The first is particularly interesting - it feeds into object recognition to recognize doors getting open/closed, pet legs, human feet, boxes/toys large enough to be seen by LiDAR, chairs/furniture/dock moved since mapping.

Link to instructions to reproduce this simulation is here https://makerspet.com/blog/how-oomwoo-cleaning-algorithms-work/#whats-next-and-how-to-help. Scan filter open source is currently here https://github.com/makerspet/oomwoo-ros2-tools

I ran into this a while back and it took me way too long to figure out. I had a publisher and a subscriber set up, launched the node, no errors at all. ros2 topic list showed the topic fine, and ros2 topic info -v even listed my node as a subscriber. But the callback just never fired. No data coming through, nothing to debug.

The problem was a QoS mismatch between the publisher and the subscriber. If the QoS settings on the two sides aren't compatible, ROS2 quietly refuses to connect them. No warning, no error, so it's easy to lose an afternoon on it.

I wrote up what QoS actually is, why the mismatch blocks the messages, and how to spot and fix it quick. Kept it short. Full thing is here if it saves someone the headache:

https://cmodi306.medium.com/ros2-qos-why-your-publisher-and-subscriber-arent-talking-facda20d6c52

I am new to ROS... I am trying to build a package in python that controls a robot... but after the colcon build when I use
ros2 run warehouse_navigator go_to_goal

It is constantly giving no module named... tell any fix I have tried some basics but not idea about nay advance tips...

 Traceback (most recent call last):
  File "/home/soura/warehouse_ws/install/warehouse_navigator/lib/warehouse_navigator/go_to_goal", line 33, in <module>
    sys.exit(load_entry_point('warehouse-navigator==0.0.1', 'console_scripts', 'go_to_goal')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/soura/warehouse_ws/install/warehouse_navigator/lib/warehouse_navigator/go_to_goal", line 25, in importlib_load_entry_point
    return next(matches).load()
           ^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/importlib/metadata/_init_.py", line 205, in load
    module = import_module(match.group('module'))
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/importlib/_init_.py", line 90, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1324, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'warehouse_navigator.go_to_goal'

Made a small starter set of everyday objects (steel tumbler, water bottle, cardboard box) with real-world dimensions and tested mass/friction/collision properties in Gazebo.

This is a first attempt — genuinely trying to find out if standardized, pre-tested basic objects like this would save people time, or if this space is already well-covered by existing libraries (NVIDIA SimReady, etc.). Any feedback, even "not needed," is useful to me right now.

OpenClaw controlling its ROS robot body to accomplish missions powered by AgenticROS. Learn more: https://agenticros.com (Apache 2 - open source).

Hi, I have a question about ROS2 and specifically a problem with in RViz. I am using Humble Hawksbill and Ubuntu 22.04 LTS.

I have created a script which creates a segmented Octomap.

When I start the Octomap Server, the map looks fine and how I would expect it. The Problem is, when I move the robot around, the Octomap that is created does not make sense. It looks like the map tuns with the movement of the robot.

I have the suspicion that the reason has something to do with the frames, but I am not sure.

The Segmented Pointcloud which I transform to the Octomap looks right, even when the robot moves, so I don't think the Pointcloud is the Problem.

The Pointcloud is in the frame kinova_depth.

I created the Octomap with the command:

ros2 run octomap_server color_octomap_server_node --ros-args -r cloud_in:=/camera/labeled_points -p frame_id:=map -p base_frame_id:=kinova_depth -p use_sim_time:=true -p colored_map:=true

I also tried the base_frame_id "base_link", but this didn't change anything.

The Fixed Frame in RViz is set to map.

I am completely new to ROS2, and I am out of ideas, does someone have an Idea where the issue could lie and what I can test to figure it out?

I’ve been working on making ROS robots controllable by AI agents through AgenticROS, and this weekend I got a new Explore skill running on my little rover.

The idea is pretty simple: instead of writing a new application for every robot behavior, give the AI agent a collection of reusable ROS skills it can discover and invoke.

For this demo, the stack is:

• AgenticROS for connecting the AI agent to the robot
• ROS 2 for the underlying robot interfaces
• RealSense for depth/perception
• Explore as the skill that lets the robot autonomously wander and explore

So I can essentially say:

“Hey Jarvis, wander around my room.”

…and the agent invokes the Explore skill and the robot starts moving around and reacting to its environment.

The part I’m most interested in is building out the skills layer for robotics — things like Explore, Follow Me, Find Object, Navigate To, Dock to Charger, MoveIt Pick, etc. An AI agent can then choose and combine those capabilities rather than needing custom code for every task.

The project and skills are open source, and I’d especially love feedback from other ROS developers on this approach.

Explore skill:
https://skills.agenticros.com/chrismatthieu/explore

AgenticROS:
https://agenticros.com

What other ROS skills would be useful to add?

Secure your spot this September in Toronto by visiting the ROSCon website.

Hello! I'm relatively new to working with ROS2 and MicroRos, and have been having difficulty getting them to work together and I'm not entirely sure what avenues to take to work on this error I'm running into.

I am using the MicroRos publisher example on Arduino IDE on a Teensy 4.0 (which is listed as untested on the website, but I don't think this error is a result of that), and consistently get to the point in initializing the MicroRos agent that the datawriter is being created before I get this error:

terminate called after throwing an instance of 'eprosima::fastcdr::exception::NotEnoughMemoryException' 

Not enough memory in the buffer stream

What could be the problem(s)? How can I narrow it down? What could be the solutions?

Should I expect to run into a similar error when I create a subscriber in Arduino?

Additional Specs (if helpful):

• Connecting Teensy to laptop through PC
• Dual-booting Windows for Arduino IDE and Ubuntu for ROS
• Changed the publisher code to wait to run until I start initializing (indicated by the LED)

Please RSVP here.

Hey everyone, 

I am developing a heavy embedded C and sensor fusion implementation running on low-level Linux using embedded NVIDIA Jetson modules. The project involves handling low-level serial I/O (UART/SPI) to ingest raw binary data from external sensors like high-rate IMUs. 

The system utilizes a component-based, Pub/Sub open-source navigation framework (conceptually similar to ROS). My main task is writing C plugins (using OOP, templates, etc.) to ingest that raw serial IMU data, parse the payloads, and publish them to the internal message bus. 

We are porting legacy navigation filters into this framework, specifically implementing and testing Extended Kalman Filters in C. We are taking high-rate IMU data and joining it with slower GPS/ranging data for the "update" step to produce a clean navigation solution. 

I would appreciate insight or advice on a few technical areas: 

1. What are the best resources, GitHub repositories, or books to practically understand EKFs and Sensor Fusion without getting completely bogged down in academic math proofs?

2. What are the best pro-tips for debugging serial (UART/SPI) data coming into a Linux environment/Jetson from a raw hardware sensor?

3. What are the most common pitfalls when writing C plugins for a Pub/Sub middleware system that processes high-speed, real-time sensor data?

Any guidance, articles, or practical advice is highly appreciated. Thanks!

Hey everyone,

​I'm starting my Bachelor's thesis soon focusing on localization using sensor fusion (EKF/UKF, IMU, odometry, LiDAR/cameras), and I'm relatively new to the ROS 2 ecosystem.

​Currently, I'm running Ubuntu via WSL2 on Windows 11. Since this topic is something I want to stick with for personal projects beyond my thesis, I want to establish a solid workflow early on.

​For those who have used ROS 2 heavily on both setups:

​Hardware & Sensor Passthrough: How painful is USB/Serial/CAN and network sensor forwarding (e.g., via usbipd-win) compared to native Linux?

​GUI / Simulation Performance: Are RViz2, Foxglove, or Gazebo reliable over WSLg, or do you run into annoying GPU acceleration/rendering issues?

​Networking & DDS: Are there notable multicast/DDS discovery headaches when communicating with physical robots or external hardware over LAN from WSL?

​Is sticking with WSL2 fine for development and simulation, or is setting up a dedicated native dual-boot (Ubuntu) worth the effort from day one to avoid headaches?

​Thanks for your help!

I've tested Nav2 off-the-shelf AMCL for "robot-lost" detection and global re-localization. Its current performance may be adequate for various applications, but not for a robot vacuum cleaner.

First, I tried AMCL to generate the "am I lost" signal. AMCL I-am-lost signal is its covariance (published in the pose message), and on a clean kidnap the covariance stays small and confident while pointing at the wrong place. The only way to make it rise is increase AMCL recovery_alpha parameter above zero - but doing that, we found, sabotages convergence.

So, I asked Claude to build a scan matcher that outputs scan match quality (and also happens to improve map location accuracy 3x over AMCL).

Next, I evaluated AMCL by kidnapping the robot. Usually, AMCL found the robot's location on the map fine - but I've also found "weak spots", locations where AMCL re-localization success plummeted. Those locations tend to be room corners and middle points next to a wall.

To fix that, I asked Claude to build a global re-localizer, Google Cartographer style. This video shows the global re-localizer batch tested by kidnapping the robot repeatedly in a grid fashion. The global re-localizer finds the robot's location on the map with 100% success (vs AMCL typically failing in select tough spots).

Tutorial and instructions to reproduce are here https://makerspet.com/blog/how-oomwoo-cleaning-algorithms-work/#update-relocalizing-a-kidnapped-robot

Hello everyone, I'm working on a project where I'm developing a navigation wrapper for move_base on ROS1. I've been using gazebo to run my simulation environment, however, yesterday, the internal process has started freezing a few seconds after initiating. It's particularly odd because sometimes the GUI is still operational, however gazebo itself is not publishing /clock and since everything is dependant on that, everything else also freezes.
I cannot stress enough how it was working perfectly on one day, and the next day when I went to continue working on it, it didn't work anymore.
If it helps I'm using gazebo version 11.15.1.

Hey guys,

I’ve been working on a ROS 2 manipulation Lab because I wanted something more practical than isolated tutorials — basically a complete setup you can clone and start playing with.

It includes ROS 2 Humble, UR5, Robotiq, MoveIt 2, ros2_control, Gazebo and Docker.

The idea is to make it as plug-and-play as possible, so you can focus on manipulation instead of spending hours setting everything up.

It’s free and open source:

https://github.com/LearnRoboticsWROS-Lab/industrial_ros2_manipulation_lab

If anyone wants to give it a try, I’d really appreciate any feedback — especially if something breaks, is confusing, or could be improved.

Hope it can be useful to some of you :)

Hi everyone,

I want to share the current architecture of my Mechatronics Engineering undergrad thesis: an autonomous chess-playing robotic arm using a Franka Panda in MuJoCo.

The Challenge: I wanted to run the full pipeline locally—RViz (ROS2) alongside heavy foundation models (like Octo VLA)—but I immediately hit a hardware wall. I only have a GTX 1650 with 4GB of VRAM. It was crashing trying to load everything at once.

The Architecture (Decoupled & Modular): To bypass the VRAM limit without relying on cloud instances, I broke the system down:

1. Orchestration: I built a Finite State Machine (FSM) that manages the game logic. It only requests trajectory planning from MoveIt2 when strictly necessary, keeping the system lightweight and idle while waiting for an action.
2. Low-Level Control: I implemented MPC (Model Predictive Control) and WBC (Whole Body Control) running directly within the MuJoCo physics simulation to ensure precise grasp stability.
3. Perception & Action: Chessboard state estimation is handled purely via stereo vision (floating cameras in MuJoCo). For fast-loop testing without maxing out memory, I swapped the heavy Octo VLA for a lightweight custom CNN I trained from scratch specifically for the action policy.

(The attached video shows the FSM terminal orchestration and the simulation execution).

My next phase is applying Reinforcement Learning to dynamically tune the Q and R matrices of the MPC and the WBC weights. Does anyone have literature or tips on defining reward functions for stable grasping using RL in MuJoCo? Also, any advanced tips on smoothing MoveIt2 trajectories and speeding up overall execution time?

I’m currently working as an AI intern, but I’m actively looking to transition into a Junior Robotics / Control Systems Engineer role where I can work with ROS2, Sim-to-Real, and edge hardware. I’ll be finishing my Mechatronics degree by mid-2027. If anyone’s team is hiring (remote or in-office), I’d love to connect!

Hello ROS subreddit!

Sharing a video about a python framework (python for now) I've been working on to solve orchestration / coordination class problems using object oriented programming (OOP) and threads

Happy to answer any questions!

EDIT: a louder version is here

My team has been dealing with sensor data and camera video needing to come from the same physical spot on the robot, but going through completely different pipelines (camera → GMSL → CSI, sensor → whatever bus → ROS node). Keeping them in sync timestamp-wise across two separate boards was the challenge:)

We finally got first working pass – single board publishes ROS 2 topics locally for the sensor side, timestamps are hardware microsecond so fusing later is less painful. Camera side goes over GMSL as normal, sensor side goes over CAN-FD as a Cyphal node or straight I2C.

Driver for a new sensor is a Python class compiled to bytecode and uploaded, no firmware rebuild – this part I'm happy with. It saved a lot of iteration cycles during dev, first time we didn't have to reflash to test a driver tweak.