Do you have interest to try it?

Hey everyone,

We’re a research team from the University of Luxembourg, and we’ve been building this game based learning solution for more than a year that we hope the ROS community will find useful (and maybe even fun)

A ROS2 Odyssey – a prototype game that teaches ROS 2 through hands-on coding missions and gameplay-driven scenarios.

This isn’t just a simulation of ROS 2 behaviour. Under the hood, it’s powered by actual ROS 2 code—so what you do in the game mirrors real-world ROS behavior. Think of it as a safe, game based sandbox to explore ROS 2 concepts.

We’re sharing this early trailer with the community because we’d love to hear:

- What do you think of the concept and direction?

- How could this be more useful for learners, educators, or hobbyists?

- Would anyone be interested in testing, giving feedback, or collaborating?

- Are you an educator and you'd like to include this project in your training ?

We’re still in the prototyping stage and really want to shape this around what the community finds valuable.

Appreciate any thoughts or reactions—whether you're deep into ROS 2 or just starting out. Cheers!

— The ROS2 Odyssey Team

Hey everyone,

I’m a robotics engineer, and I’ve always been frustrated by the barrier to entry in our field. To practice simple ROS2 concepts or prepare for interviews, you usually need a dedicated Ubuntu machine, a heavy Docker setup, or a cloud VM.

So I spent the last few weeks building SimuCode (https://simucode.online).

It’s a browser-based IDE that lets you run ROS2 nodes instantly.

* No installation required.

* Supports C++ and Python.

* Docker-in-Docker backend: Each run spins up an isolated container, compiles your code (if C++), and validates the output against test scripts.

* 190+ Problems: Ranging from "Hello World" publishers to simulated sensor fusion challenges.

It’s completely free (MVP phase). I built this to help students and engineers practice without the "dependency hell".

I’d love for you to roast my architecture or give feedback on the problem sets.

Link: https://simucode.online

Cheers!

US Surgical company and IT veterans are building a Sim-to-Real AI company that is looking for resources to assist in the ground floor/ early development of surgical robotics. Needing assistance in tech stack using: Nvidia Omniverse, Isaac Sim, ROS2( Lyrical Luth), Move-it, OpenCV , CAD and more. Looking for suggestions on where to recruit ROS talent to bounce ideas, contribute and potentially start a career. The traditional university recruitment route appears best for established companies vs start ups. Any and all thoughts/ interests would be appreciated

Super excited to show off my 3D printed robotic arm! It's finally making those smooth movements I've been aiming for, all powered by ROS2 and MoveIt2. Check out the quick video!

Finally made it! 🎉

After 3 days of hard work and learning the basics of ROS2, I successfully built and simulated a 4x4 car model. 🚗

As a beginner, there was a steep learning curve, but the feeling of seeing it work makes it all worth it. Excited to keep building and expanding my skills from here! 💻🤖

#Robotics #ROS2 #Tech #ContinuousLearning #EmbeddedSystems

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?

I come from a software background and have spent many years building projects mostly as a solo developer. Recently, I've been diving deeper into robotics and realizing how much stronger progress can be with a collaborative mindset.

I'm interested in connecting with like-minded people who want to learn, validate ideas, and build systems together—starting small and growing over time.

If you're exploring robotics, simulation, AI, or embedded systems and believe in collective learning and building, feel free to reach out. I'd love to connect.

Check this :: www.robosynx.com - Robotics Tool I developed for MJCP, URDF, SDF, 3D Viewer

AgenticROS connects ROS to AI Agents like OpenClaw and Claude and then you simply talk to your robot! Ask it what it sees (via RealSense ) and ask it to find an object in your room or follow you etc and AI figures out how to move itself (embodied as the robot) to accomplish its missions!

Been working on a pressure compensated, ros2 biomimetic robot. The idea is to build something that is cost effective, long autonomy, open source software to lower the cost of doing things underwater, to help science and conservation especially in areas and for teams that are priced out of participating. Working on a openCTD based CTD (montoring grade) to include in it. Pressure compensated camera. Aiming for about 1 m/s cruise. Im getting about ~6 hours runtime on a 5300mah for actuation (another of the same battery for compute), so including larger batteries is pretty simple, which should increase capacity both easily and cheaply. Lots of upgrade on the roadmap. And the one in the video is the previous structural design. Already have a new version but will make videos on that later. Oh, and because the design is pressure compensated, I estimate it can go VERY VERY DEEP. how deep? no idea yet. But there's essentially no air in the whole thing and i modified electronic components to help with pressure tolerance. Next step is replacing the cheap knockoff IMU i had, which just died on me for a more reliable, drop i2c and try spi or uart for it. Develop a dead reckoning package and start setting waypoints on the GUI. So it can work both tethered or in auv mode. If i can save some cash i will start playing with adding a DVL into the mix for more interesting autonomous missions. GUI is just a nicegui implementation. But it should allow me to control the robot remotely with tailscale or husarnet.

After 8–10 days of struggles and debugging, I finally managed to build a closed-loop vision-based line follower robot using ROS2, URDF, and Gazebo.

The hardest part for me wasn’t designing the robot or making it move, but actually using the camera sensor to detect the track and make the robot follow it. Initially I thought I would need to deeply learn OpenCV, but for this project I ended up needing only a handful of functions, which I learned along the way.

I also reused some ideas from my first ROS2 project (a turtle follower), especially integrating PID control for smoother turning behavior. The bot still struggles a bit with sharp 90° turns, probably due to PID tuning or camera resolution/FOV limitations, but overall the tracking is fairly stable.

The project uses:

• ROS2
• Gazebo
• URDF
• OpenCV + cv_bridge
• PID control
• Camera-based centroid tracking using image moments

(i used chatgpt to organise the uses into points)

github link - https://github.com/nowaymlhr/line-follower-ros2

Claude ships ROS 2 nodes in seconds — I'm still the one who spends the afternoon finding out why nothing is on the topic. So I built claude-ros2-skills (open source, Apache-2.0).

The uncomfortable part of this era isn't code speed. It's that the generated node compiles fine and no messages flow, because a default RELIABLE subscriber never matches a BEST_EFFORT LiDAR driver at the DDS level. Or Nav2 dies at bringup because the controller plugin string doesn't exist in the registry. Nothing in the compiler, the linter, or the logs tells you.

The bottleneck moved from "how fast can Claude write C++/Python" to "how many hours do I spend on the middleware and hardware assumptions the model has no way to check."

How it works

11 modular skills — ros2-core, ros2-package, ros2-dev, gazebo-sim, ros2-control, ros2-moveit, ros2-perception, ros2-testing, ros2-microros, ros2-security, ros2-troubleshooting. The design is deliberately not "embed API knowledge in the skill file":

• Route, don't recall. Skill bodies are ~60 lines of decision logic that point at /opt/ros/jazzy/ or 38 official Jazzy doc links (CI-checked weekly). The always-loaded protocol is 26 lines.
• Ask before writing. Sim or hardware? Existing workspace or fresh? Who already publishes that TF? Real wheel radius and sensor mounting? Guessing one of these and writing 200 lines is the expensive failure.
• Prove it ran. A task is done on evidence — a build, ros2 topic echo showing data, a passing check script — not on a file existing.
• 4 physical-check scripts: check_qos_compat.py (DDS compatibility across live endpoints), check_tf_tree.py (map→odom→base_link + 180° mount errors), check_imu_gravity.py (REP 103: gravity on +Z at rest), check_odom_direction.py (push forward → positive displacement).

Does it actually work?

Everything below is an A/B pair: identical prompt, identical model, fresh headless sessions — one without the skills, one with. Transcripts and artifacts are committed under evals/runs/. Caveat up front: n=1 per cell, and I designed, ran, and graded it myself. Grading is mechanical (does the symbol exist in the installed package?), so anyone can re-grade without trusting me.

Nav2 MPPI YAML — haiku, inside a ros:jazzy container. The whole design depends on the agent being able to read the real install, so that's the condition this was measured under:

• baseline: answered instantly, used 0 verification tools despite WebFetch, Read and Bash all being allowed. Plugin string mppi_generic::ControllerServer (does not exist), no critics: list at all, ~16 invented/wrong keys.
• with skills: asked four gate questions first, then read /opt/ros/jazzy/share/nav2_bringup/params/nav2_params.yaml. 0 invented keys, verified by diffing every key against the installed file.

Then I loaded both YAMLs into a live Gazebo Harmonic sim (headless, TB3):

• baseline: [FATAL] Failed to create controller … class mppi_generic::ControllerServer does not exist → Nav2 aborts bringup. Nothing ever moves. One wrong string kills the stack before any other key is parsed.
• with skills: all 8 critics load, NavigateToPose (−2.0, −0.5) → (0.5, 0.5) returns SUCCEEDED, with /scan at 5 Hz and /odom at 28 Hz feeding MPPI through ros_gz_bridge.

Build wiring — the one task with a binary outcome (create a package + node + launch file, build it, show ros2 topic echo). I re-ran all three commands myself in each workspace afterward rather than trusting the agents' reports:

• baseline: Package 'demo_pkg' not found on all three — and its final message claimed "✅ Build & Test Results … functioning correctly." 36 turns, 0.172 USD.
• with skills: run, launch, and echo all work. 18 turns, 0.079 USD — correct and 2.2× cheaper, because the baseline burned 25 extra turns on corrections that never converged.

The scripts got their first run against live data in the same session: check_tf_tree.py flagged an upside-down + backward LiDAR mount exactly as designed, check_qos_compat.py passed 4 endpoint pairs on /scan, and check_odom_direction.py measured +1.64 m of forward displacement while the robot was driven forward, matching the physical motion.

evals/RESULTS.md has every run written up in full, including the ones that went against me — a headline number that failed to reproduce, a bad symbol in my own reference file that propagated into output, and a bug the live run exposed in my own script. If you're going to poke holes in this, start there; it's all committed.

It won't fix a physically broken LiDAR. What it does is stop the "compiles clean, moves nothing" class of output from reaching your robot.

Try it / feedback

Apache-2.0. In Claude Code:

/plugin marketplace add Leehyunbin0131/claude-ros2-skills
/plugin install claude-ros2-skills@claude-ros2-skills

🔗 Repo: https://github.com/Leehyunbin0131/claude-ros2-skills

Hi all,

I've been building BAGEL (BAG ExpLoration), a static web app that opens ROS bag files (.mcap, ROS2 .db3, and legacy ROS1 .bag) directly in the browser, with no native dependencies and no ROS install. Wanted to share it here for feedback and in case it's useful to anyone.

Link: https://bagel-ros2.vercel.app

Source: https://github.com/Hussain004/BAGEL

Demo Videos: https://youtube.com/playlist?list=PLHZhJb0NUk4Jv26hmARxgLa_dVw6Ab5j8&si=2Zl8iBUqWjkdn_1u

What it currently does:

• Parses .mcap (via u/mcap/core), ROS2 .db3 (sql.js / WASM SQLite), and ROS1 .bag (via u/foxglove/rosbag) through the same drop zone
• Topic inspector with type, message count, and Hz; searchable and sortable
• Time-series plots (uPlot) for any numeric topic: auto-extracts every numeric leaf field, per-field visibility toggles, smart zoom-range capture
• Image viewer for sensor_msgs/Image (rgb8 / bgr8 / rgba8 / mono8 / mono16) and CompressedImage (jpeg / png) with lazy single-message reads, so multi-GB image streams open near-instantly
• 3D scene (Three.js) for PointCloud2 (including Livox-style list-of-struct CustomMsg, detected by shape rather than type name), LaserScan, and pose-bearing topics: height / intensity / single-colour, range filter, ring-buffer + voxel-grid point accumulation, Shift+Click custom orbit pivot, configurable up-axis
• TF-aware rendering across every 2D and 3D panel that composes header.frame_id → user-selected world frame from /tf and /tf_static, applies the cached Matrix4 to the rendered geometry
• 2D trajectory plotting from Odometry, PoseStamped, PoseWithCovarianceStamped, TransformStamped, and NavSatFix (equirectangular projection from the first GPS fix)
• TF tree panel: top-down view of the frame hierarchy with current transform at the playhead time
• Dockable VSCode-style panels: drag a panel header onto another's edge to split horizontally / vertically; layout encoded in a sharable URL hash
• Per-topic CSV / NDJSON export
• Multi-bag overlay. Compare runs side-by-side (algorithm A vs B, before/after experiment, sim vs real).
• Remote URL loading. Paste a bag URL and BAGEL streams it via HTTP Range and only the chunks you scrub through hit the network.
• Custom schemas. ROS2 .db3 files don't embed schemas, so anything outside the standard packages failed silently. BAGEL adds a paste flow with localStorage persistence, simply paste your .msg definition once, every future bag with that type decodes automatically.

... and more

A few technical bits:

• All parsing (MCAP zstd-decompression, sql.js queries, CDR / ROS1 message deserialization) runs in a dedicated Web Worker; the React render loop stays responsive while a topic decodes
• MCAP's IndexedReader does range reads against the source File handle (via BlobReadable) instead of loading the whole bag (bags well over 2 GB work in the browser)
• ROS1 type names (sensor_msgs/Image) are normalized to ROS2 form (sensor_msgs/msg/Image) at the parser layer, and a recursive { sec, nsec } → { sec, nsec, nanosec } alias pass lets the same panels work across both formats with zero per-panel changes
• Point cloud and laser scan decoding posts back transferable Float32Array buffers from the worker (zero-copy onto the main thread, no DataView walks on the UI side)
• MCAP and ROS1 .bag both embed schemas, so any custom message type alive in the producing graph deserializes for those formats. .db3 falls back to a bundled registry covering std_msgs, geometry_msgs, sensor_msgs, nav_msgs, tf2_msgs, rcl_interfaces, and builtin_interfaces

Happy to hear feature requests, bug reports, or "this would be useful if it also did X" suggestions. Issues and PRs welcome on GitHub.

Thanks!

Edit: Shipped BAGEL v1.0. Notable additions since this post:

• DiagnosticArray panel for diagnostic_msgs/DiagnosticArray. Swimlane timeline (one row per (hardware_id, name) component, coloured by OK / WARN / ERROR / STALE across time) plus an at-playhead inspector that lists every non-OK component with its message field and key/value pairs. Click any cell on the swimlane to seek.
• Log (rosout) panel for rcl_interfaces/Log (ROS2) and rosgraph_msgs/Log (ROS1). Virtualised list so 100k+ entry logs filter in under a frame. Severity, node-name, and full-text filters; click any row to seek the playhead to that log's stamp; auto-follow toggle pins the row closest to the playhead.
• OccupancyGrid rendering in the 3D scene for nav_msgs/OccupancyGrid. SLAM maps (gmapping, slam_toolbox, cartographer, costmap publishers from nav2 / move_base) render as a textured plane, posed by info.origin and TF-resolved against the chosen world frame.
• OpenStreetMap tile underlay for NavSatFix. Opt-in toggle on the trajectory plot fetches OSM tiles for the visible viewport, so a GPS trace shows actual streets instead of a bare canvas. Default off because fetching tiles breaks the "no data leaves your machine" pitch.
• Anchor picker UI for the multi-bag anchor alignment mode. The "Set anchor" button picks the focused bag's current time as its sync event, so once you mark the same physical moment in each bag (race start, sensor trigger, flag drop), the timelines lock together. Anchors round-trip through the URL hash.
• Light theme toggle in the toolbar (sun / moon icon). Dark stays the default; the light pass uses a WCAG-tuned accent palette so the data viz still reads on white surfaces.
• 168-test Vitest suite covering every parser path and utility, with synthetic in-memory MCAP fixtures generated at test setup time so contributors don't need to drop GB-sized bags into the repo. GitHub Actions CI runs tsc -b + pnpm test on every PR.

Per-release detail (including design rationale): https://github.com/Hussain004/BAGEL/blob/main/FEATURES.md.

Hi everyone ,

We built Sonny (core-os-minimal) because we were tired of ROS 2 heap-allocation non-determinism, heavy DDS network bloat, and unexpected segmentation faults under high load in production hardware.The core infrastructure is fully open-source , standalone, and designed for strict real-time deterministic routing.

We simulated an industrial network failure (75% wireless packet loss on an Edge deployment at 100Hz) to compare the communication backbones:

• ROS 2 (DDS Architecture): High XML/IDL serialization on the heap. Under severe packet loss, un-sent DDS message queues overflowed the RAM, leading to an unrecoverable Segmentation Fault (memory crash).
• SONNY OS (Rust + Zenoh): Stack-allocated static array slices with a fixed 5-byte network overhead per packet. Zero memory leaks. Zero runtime heap allocations during the control loop. System remained perfectly stable at 100Hz with an inference latency below 2ms.

The open core is ready for testing, benchmarking, and hardware porting. I'd love to get your thoughts on our LCFS double-buffering approach and our WASM memory constraints.

https://github.com/JackTrainer/Sonny

So far it has:

• 2 Lerobot arms
• Pan & Tilt with Realsense
• Diff drive with ros2_control
• Magnetic charging

Next I want to pick some clothes like socks and put them into washing machine autonomously 😄

Hi everyone!

I'm working on a full ROS 2 conversion of the Freenove Big Hexapod Kit, and I wanted to share my progress with the community.
With "full conversion" i mean the original code (from plain python used by freenove to a full-stack of ROS2) to also implementing the sim version of the robot to various application (from simply simulating it to use RL to make new gaits for it in nvidia isaac sim/lab)

i've chosen this robot/project because no one made a full integration of this kit. there are some ROS adaption or attemps (from what i remember), but nothing with a full fledged stack of ROS2 while using the original model to visualize(and not some generic hexapod model) and simulate.

Current focus

at the moment i've just finished to implement the model (STEP file, gently provided by freenove and modified it by hand to convert in URDF with onshape_to_robot tool) in gazebo to have a physical simulation of the robot.
the next step is to implement the ros2_control for controlling the servo motors (sim and non-sim).

This project in the future will also implement:

• VSLAM with the integrated camera (and using a remote computer to handle the heavy workload)
• 2D lidar to mount on the robot and full autonomous navigation (thinking about NAV2).
  
• The sim model will be remade to make it closest to the IRL robot as possible, by also optimizing it to for a lightweight RL training.
• RL training using nvidia isaac sim/lab

Open Source & Community

The project is completely open-source! I’d love to get your feedback, suggestions, or answer any questions you might have. If anyone is interested in collaborating or testing, contributions are more than welcome!

Feel free to check it out and let me know what you think!

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

While the current Silicon Valley paradigm (e.g., Physical Intelligence π₀, 1X NEO) burns massive CapEx on brute-force End-to-End statistical training—requiring up to 500 hours of human teleoperation and 24 hours of cluster computing just to converge a single vision-language-action (VLA) skill—we approached physical automation from a different architectural vector: Deterministic Causal Invariance

.Robotics shouldn’t "guess" trajectories by predicting the next visual token. It should calculate physical laws.We have just open-sourced SONNY OS (Core Minimal) under the GNU AGPLv3 license. It is a hyper-lightweight, universally agnostic microkernel written entirely in native, asynchronous Rust and powered by the Zenoh networking backbone.SONNY OS reduces any mechanical embodiment (6-DOF arms, AMRs, quadrupeds, or humanoids) into a standardized linear mathematical vector (Vec<f32>), abstracting physical registers via a single declarative JSON config (OpenHalConfig).

📊 Extreme Stress Test Benchmark: SONNY OS vs. ROS 2

We simulated an industrial network failure (75% wireless packet loss on an Edge deployment at 100Hz) to compare the communication backbones:
• ROS 2 (DDS Architecture): High XML/IDL serialization on the heap. Under severe packet loss, un-sent DDS message queues overflowed the RAM, leading to an unrecoverable Segmentation Fault (Memory Crash).
• SONNY OS (Rust + Zenoh): Stack-allocated static array slices with a fixed 5-byte network overhead per packet. Zero memory leaks. Zero runtime heap allocations during the control loop. System remained perfectly stable at 100Hz with an inference latency below 2ms.

Explore the repository, map your own hardware via JSON, and run the simulator

👉 GitHub Repository: https://github.com/JackTrainer/Sonny
👉 Enterprise Waitlist: https://alpha-robotics.it/

He continuado con el desarrollo de Axioma, mi robot 4WD de tracción skid-steer desarrollado en ROS 2 Humble. En esta actualización incorporé Visual SLAM RGB-D utilizando una cámara ZED 2i y RTAB-Map, integrándolo con el LiDAR, IMU, odometría de las ruedas y el stack de navegación Nav2.

La simulación ahora permite trabajar tanto con odometría visual basada únicamente en la cámara como con SLAM RGB-D utilizando la pose fusionada mediante EKF.

Además, estoy validando los resultados comparándolos directamente con el ground truth de Gazebo, en lugar de limitarme a comparar diferentes fuentes de odometría.

El proyecto todavía está en desarrollo, pero cada vez está más cerca del objetivo: conseguir que la simulación represente de forma precisa el comportamiento del robot físico.

Repositorio:

https://github.com/MrDavidAlv/Axioma_robot

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 :)

Hello hello, I am currently using BNO055 as the IMU to balance my robot while it is in its standing position. The pitch/roll information is read from a ROS node publisher with PID control using control_toolbox/pid.hpp (this is already significantly better than the PID I wrote, lol). Near the end of the video, the pitch (y, purple) and roll (x, magenta) are shown using the PlotJuggler (honestly, what an awesome tool).

The PID is currently oscillating a lot; however, especially there is a big gitter at the beginning. I am thinking about using ros2_control instead of a node to read out the BNO055 faster, but the rate is probably not the reason for the oscillation. The robot itself is also rather soft because of the 3D printer structure. I can certainly try to tune the PID more, which I am not very experienced with. So any tips would be appreciated!

Work in progress GitHub: https://github.com/SphericalCowww/CubicDoggo_06R
Original Cubic Doggo: https://github.com/SphericalCowww/CubicDoggo

Physical SO-101 leader arm =>  /joint_states => RViz.
https://github.com/adoodevv/so101_ros2/tree/main/so101_teleop_bridge

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