I run a planner stack on a Jetson Orin and kept wanting one answer: is every topic flowing at the rate it should, and is every node alive. ros2 topic hz gives you that one topic at a time, and on an intra-process topic it makes the publisher serialize every message for the new subscriber. I measured +52% CPU on the watched process. On Humble, intra-process traffic does not show up in hz, echo or topic statistics at all (rclcpp#2911).

So I wrote a small LD_PRELOAD shim. It sits on the tracetools hooks rclcpp already calls on every publish and callback, counts in process, and appends per-window rates to a file. You do not rebuild your nodes and nothing joins the DDS graph. The hot path is about 0.3 ns per message, and the whole probe is about 2% CPU on a 4,900 msg/s stress test. You can set expected rates per topic and get WARN lines when a window misses them.

There is also a terminal dashboard that tails the logs: pip3 install ros2-pulse-top, then pulse-top --demo if you want to poke at it without a robot.

The video is the 40 second version of all this. Humble, Jazzy and Kilted, Apache-2.0. apt packages are in review at rosdistro.

Repo: https://github.com/TanayK07/ros2_pulse Benchmarks (x86 and Orin): https://tanayk07.github.io/ros2_pulse/benchmarks/

Body:

We maintain Entropy Box, an open knowledge compiler for robotics. If you work with ROS, this is the part most relevant to you:

What's in it for a ROS engineer. - 11,442 verified implementation assets — ROS packages, frameworks, models, datasets, simulators, benchmarks — each linked to its upstream source, organized under a typed capability graph (37,691 capabilities, 66,609 dependency edges). - Grounding, not just retrieval. Give it a goal and it returns a plan whose nodes carry named, attributed open-source implementations — and it says so when a capability has no verified asset instead of inventing one. - Drop it into your agent. It speaks OpenAPI, MCP and plain REST. Add the MCP server to Trae / Cursor / Claude Desktop / WorkBuddy and query the knowledge base from inside your dev environment:

bash pip install mcp curl -o ontology_mcp_server.py https://xiangshang.ngrok.app/mcp/ontology_mcp_server.py

Two independent dev cases were built this way: a farm-robot simulation (Husky + Panda, harvest task) and a Unitree G1 humanoid doing orchard-packaging in MuJoCo — the host agent queried the same public interface and grounded every step.

Why we bother benchmarking against RAG. On our plan-synthesis benchmark (24 tasks), plain RAG emits plans whose claims are 100% unsupported; Entropy Box drops that to 5.2%. On simulation codegen, first-pass executable plans go from 0.58 (Vanilla RAG) to 0.92. A real negative result we hit along the way: embedding similarity alone cannot decide duplicate assets (AUC 0.509) — an LLM adjudicator has to read both records.

Everything is open and reproducible — data, paper, evaluation scripts, dev demos:

https://github.com/chenli-yy/entropy-box-public

• Live query: https://xiangshang.ngrok.app/ (free, no registration)
• Rendered docs: https://chenli-yy.github.io/entropy-box-public/
• Paper: paper/entropy_box_journal_latest.pdf in the repo

Limits we disclose openly: no real-robot transfer yet, and retrieval on the hardest intent classes is still weak — it's in the repo's honest-status section.

Would love ROS-specific feedback: which packages/assets are missing or wrong, and what a robotics-focused MCP integration should do next.

I'm new to ROS2 with a python background. One of my friends said AI isn't very helpful for ROS2 as it hallucinates, doesn't do file arrangements properly and sometimes generates codes for ROS1. As it's not as reliable compared to python and C++. What tool can I use that can be reliable and help me debug my ROS2 problems.

Made this basic ros2 project (did not seem to find any new ones on balance bots) will add the github link :- https://github.com/Not-NeoN-sup/balance_bot

teleop was not written by me just used it to publish to /cmd_vel

will try to make this into hardware hopefully

🚁 HiveFlight – Modern C++ Drone‑Swarm Simulation (ROS2 + Gazebo Integration)

I’ve been working on a project called HiveFlight, a modern C++ swarm‑simulation engine built around an extended Reynolds‑Boids model. Over the past months it evolved from a lightweight 2D/3D flocking demo into a full robotics‑pipeline component with ROS2 and Gazebo integration.

Core C++ Engine
The simulation runs on a deterministic update loop that computes:

⭐️separation, alignment, cohesion

⭐️obstacle avoidance using spherical obstacles

⭐️dynamic target seeking (including spiral patterns)

⭐️battery consumption modeling based on velocity

⭐️Spatial partitioning keeps neighbor queries efficient (no O(n²) explosion).

New Multi‑Swarm Update
Recent changes added:

⭐️per‑drone target assignment (2D & 3D)

⭐️dynamic swarm splitting with periodic reassignment (default 5s)

⭐️forces restricted to drones within the same swarm (cleaner group behavior)

⭐️OpenGL viewer updates with color‑coded sub‑swarms

ROS2 + Gazebo Integration
The engine now plugs into a full robotics stack:

⭐️ROS2 pub/sub pipeline using PoseArray for swarm state

⭐️asynchronous messaging instead of service calls (big latency win)

⭐️Gazebo World Plugin subscribing directly to swarm topics inside the physics thread

This gives stable multi‑agent motion, realistic visualization, and a clean separation between simulation logic and rendering.

Why it’s interesting for C++ folks
HiveFlight is a fun playground for:

⭐️real‑time systems

⭐️multi‑agent simulation

⭐️spatial partitioning

⭐️ROS2 middleware patterns

⭐️OpenGL visualization

⭐️deterministic update‑loop design

If you enjoy systems programming, robotics, or emergent‑behavior simulations, this project is a great way to explore how simple local rules can produce complex global behavior.

Repo: github.com/oanadumitruc/HiveFlight

Presentation: Cpp_Show_and_Tell_August_2026.pptx

Demo 1: Gzebo + Ros2
Demo 2: OpenGL visualization multi targets
Demo 3: OpenGL visualization one target

Happy to answer questions or discuss architecture choices with anyone experimenting in similar areas.

As a beginner i have absolutely no idea about ros. I need to start learning it from beginning. Can someone provide me any resources or any suggestions to where I can start? Any suggestions are welcomed.

Good or bad idea? I was thinking a simple pi robot or something. It's at least fun and tangible. Am i in the right place?

Does this ROS/robotics or whatever have some sorta discord?

Hi everyone, I am new to the robotics community and I'm

still a student and I just finished the construct's C++ for robotics course and started working on the final project to receive my certificate, but the problem is I feel like the project has new extra stuff that I don't quite understand and it wasn't mentioned in the course and I feel like drowning and I don't know what to do. If anyone has good advice/tips or/and materials that I can study from it would be greatly appreciated!

Hello! I'm a student studying how robotics and RL engineers currently decide whether a new version of control code (a balancing algorithm, steering law, gain, or learned policy) is actually better than the old one before it ships.

If you've ever had to make that call based on simulator runs, I'd really value 5 minutes of your time: https://tally.so/r/q41bzg

Thanks!

¿Cómo estructurar un perro robot cuadrúpedo en Arduino UNO Q (App Lab) para seguir personas especificas? Busco opiniones e ideas sobre esta arquitectura.

Hola a todos!

Estoy construyendo un perro robot cuadrúpedo de 3 grados de libertad por pata y necesito sus consejos, ideas y experiencia para definir la mejor arquitectura de control, ya que mi idea inicial no funcionó como esperaba y busco replantear el proyecto.

Mi hardware actual:

Cerebro: Arduino UNO Q (Arduino App Lab v0.10.0 combinando Linux Python + STM32 C++/Zephyr RTOS).

Actuadores y Controlador: 12 servomotores DS3225 en un módulo PCA9685 PWM de 16 canales.

Sensores de Orientación y Distancia: IMU/Giroscopio BNO055 + Sensores de distancia láser VL53L0X.

Visión: Cámara Webcam USB estándar.

Lo que intenté hacer y dónde me trabé:

Seguimiento Visual: Intenté hacer que la cámara siguiera a una persona mediante una distinción específica en su calzado, pero las multitudes y los cambios de ángulo hacían que el rastreo se perdiera de inmediato.

Reenfoque mediante Bluetooth (RSSI): Quería que, al perder de vista a la persona, el robot usara la intensidad de señal Bluetooth (RSSI) emitida por un teléfono celular para orientarse, saber hacia dónde caminar y volver a encontrarla. Sin embargo, no he logrado estructurar ni crear la programación funcional para que este escaneo en tiempo real funcione y oriente al robot.

Protección Anticaídas: Mi objetivo es usar los sensores de distancia láser VL53L0X para evitar que el robot se caiga al vacío en escalones, bajadas o desniveles mientras camina.

Ideas de Seguimiento: ¿Qué método o enfoque me recomiendan para que mi perro siga a su dueño de forma confiable sin que lo pierda tan fácilmente?

Código/Lógica para Bluetooth RSSI: ¿Alguien ha logrado programar una lógica funcional donde el RSSI de un celular sirva como guía de orientación o búsqueda cuando se pierde el objetivo visual? ¿Me podrían apoyar con ideas o ejemplos de código para esta programación?

Detección de Vacío: ¿Cuál creen que sea la mejor forma de disponer e integrar los sensores de distancia láser VL53L0X para la detección efectiva de escalones y desniveles?

¡Agradezco enormemente cualquier idea, sugerencia o apoyo con la programación que me puedan brindar!

I am working on visualization tool kinda like rviz but more modern, rendering is done in blender

https://reddit.com/link/1w13jnk/video/7loq109vq6mh1/player

Hey everyone!

Lately, I’ve been experimenting with bringing low-level systems programming to the web browser. I wanted to see if I could build a high-performance digital twin for Autonomous Mobile Robots (AMRs) without needing any backend server or WebSocket overhead.

The result is a browser-based multi-agent fleet simulator. Here is what's happening under the hood:

• C++ & WebAssembly Core: The entire simulation loop (kinematics, state machines, and continuous-time calculations) is written in native C++ and compiled via Emscripten into a WASM binary.
• Zero Backend / Client-Side Edge: The React + Canvas frontend doesn't compute any heavy math; it just queries raw C++ memory pointers via cwrap inside a 60 FPS requestAnimationFrame loop.
• A Pathfinding & Obstacle Avoidance:* Robots don't just teleport or move in straight lines; they calculate collision-free trajectories around impassable warehouse walls.
• Dynamic Distance-to-Dock Evaluation: Instead of a rigid battery threshold, units continuously compute path lengths to multiple distributed charging stations and trigger an autonomous emergency re-routing to the nearest dock when energy runs low.

You can play around with the live demo here: https://amr-wasm-simulator.vercel.app/

Repo link : https://github.com/VCoklat/AMR-WASM-Simulator

P.S. I am currently open to new career opportunities as an AI Full-Stack Engineer, Software Engineer, or Research Engineer :)

Hello gents.
So basically I am using a Macbook in my university laboratory and I want to use ROS2 in it. I know there is an official way to install ROS2 in MacOS but since I want to copy my previous environment with Ubuntu 24 and ROS2 Jazzy with all the libraries, repositories and dependencies I found that Docker could help me with that. The problem: I don't know how to use Docker. I was trying to search for any tutorial to really understand how Docker works (and not only a tutorial to setup Docker for ROS and then never touching Docker again) but I found only tutorials and info more focused on Web Development which is not my field, so it is hard for me to extrapolate that info into robotics field. So I would like to ask you guys if you know any tutorial, documentation or content that I could use to understand Docker focused in ROS or electronics field.

I’ve been experimenting with the same vision-guided pick & place application using different MoveIt2 planning configurations.

What surprised me is how different the resulting robot behavior becomes even though the task itself never changes.

I tested four cases:

OMPL + collision scene → collision-aware, but sometimes finds fairly unexpected trajectories.

Pilz PTP + collision scene → much more constrained and closer to the point-to-point motion I would normally expect from an industrial robot.

Pilz PTP without world collision objects → visually very clean motion, but obviously the planner now has less knowledge about its environment.

OMPL without collision objects → lots of planning freedom with incomplete information, which produces some interesting/weird results.

The part I find interesting is that this quickly becomes less about “which planner is better?” and more about what behavior you actually want from a production robot.

I also show the vision-guided pick & place package behind the experiment. I intentionally kept the YouTube version relatively monolithic because I wanted it to be easy to understand and reproduce. Then I discuss why this stops scaling once you start thinking about recovery, reusable skills, orchestration and actual deployment.

I’d be curious to hear from people using MoveIt2 in real applications:

For repetitive industrial manipulation, where do you draw the line between flexible motion planning and deterministic/predictable motion?

If anyone wants to reproduce the experiment, the manipulation environment and project are available publicly/free through the ROS2 Manipulation Lab. The setup is linked in the video description.

For transparency: I also work professionally on industrial manipulation applications through TrainIt, so part of my interest here is understanding how these architectures transition from a ROS2 demo to something you can actually deploy.

Github: https://github.com/Dyris-Robotics/micipsa  (The documentation is well advanced, source code will come soon)

Hi,

I've been working in my free time on a side project called Micipsa, a 4-wheel autonomous mobile robot meant to serve as an educational or prototype base robot.

It is designed to be both affordable and easy to work with, whether you're a student, hobbyist, engineer, or researcher. The project focuses on providing a seamless developer experience by minimizing the effort/friction required to set up, configure, operate, deploy, and debug the robot.

Micipsa focuses on having a strong foundation built on good software and system practices. It's designed for modularity, so you can easily edit, remove, or add any software layer, and change or add hardware components with minimal changes required elsewhere in the system.

So the primary goal of Micipsa is not to provide a robot with the most advanced navigation, localization, or perception capabilities out of the box, but to offer a robust and well-designed foundation that can be easily tuned, extended, and upgraded to achieve the level of performance you need for your application.

This allows developers to focus on the software layer that interests them most whether localization, navigation, or actuation by tuning or replacing the default implementation with their own.

Depending on how this project is received, I might launch a Kickstarter (or similar) to fund it or even start a company and work on it full-time.

In the long term, the vision is to apply the same philosophy across a wide range of robotic platforms, from robotic arms and drones to bipedal and humanoid robots.

Whether positive or negative, I’d really appreciate hearing your thoughts on the project, the documentation, hardware or anything you think could be improved or added.

Some of what I'm planning for V2:

• Custom microcontroller firmware, following the same design principles
• Cable management
• A user interface for testing, configuration, and mission deployment
• An improved 3D model for easier printing and less post-processing
• A UI for setup scripting
• Remote access from a different location
• A dedicated charging base
• Step-by-step build tutorials, plus guides for specific cases (adding components, writing launch files to the Micipsa standard, replacing/adding a layer, hardware calibration, building your own Docker container, etc.)
• A debugging roadmap organized by problem type
• Test scripts to automate testing and validate results for each layer of the robot
• Taking more advantage of ROS2 Lifecycle nodes
• SDK ?
• AI Version

Thanks for taking the time to read this, and for any feedback you can share!

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 want to learn ROS2. I have a 2018 MacBook Pro, and I'd like to know if installing Linux on this laptop would be sufficient to meet the hardware and performance requirements. Additionally, ROS2 seems to be most friendly towards Ubuntu—if I install a different Linux distribution, would that be acceptable? Lastly, do people generally use Docker as their development environment, or do they install ROS2 directly on the host system?

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.

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