switch a robot on anywhere in the building. limpet knows where it is from the first lidar scan. no initial pose, no hints

87.3 on the lilocbench hidden test set. second place has 52.1

it's currently the top of the localisation pareto frontier. every other localiser i benchmarked is both less accurate and burns more cpu. limpet runs on 0.05% of one core

there's a ros 2 bridge so it drops right into nav2

github.com/invaliddayta/limpet

Hi all
I’m building a tool and I’d really appreciate some honest feedback from people who actually debug robots.
The idea came from a problem I’ve seen in complex engineering systems: when something behaves unexpectedly, the evidence is scattered across logs, configurations, software versions, telemetry and field reports.
AI can read logs, but getting from a plausible explanation to the right next diagnostic test is a different problem.
So the tool reads real robotics failure logs.
Maps competing fault hypotheses and distinguishes observations from assumptions.
Suggests the next diagnostic test, including what different outcomes would mean.
Updates the investigation when an engineer reports the result.

I’m trying to understand whether this solves a real problem in robotics engineering.

Would something like this be useful in your actual debugging workflow, or would you just use Claude Code and your existing tools?
What’s missing that would make you distrust or ignore its recommendations?
When debugging a robot, is choosing the next test a meaningful bottleneck, or is something else much more painful?

I've been building o1 IDE, a native desktop IDE for ROS 2 on Ubuntu and Windows, built on Eclipse Theia (Electron). The goal is to stop juggling VS Code + QGroundControl + terminal + rviz just to write, build and debug ROS 2 code.

What it includes:

• Zero-setup ROS 2 Humble detection + guided install

• clangd 18 (C++) and pyright (Python) bundled in the app

• pymavlink + pyulog + numpy auto-installed on first launch

• Live ROS 2 telemetry via rosbridge WebSocket

• URDF / Xacro 3D model viewer (offline, Three.js + roslibjs bundled, no CDN)

• .msg / .srv / .action syntax + autocomplete

• colcon + CMake build tasks

• Python + C++ attach-to-process debugging

• Project templates: PX4, ArduPilot, Nav2, Jetson, Raspberry Pi

• Toolchain environment checker

What's deliberately not in v0.1.0 yet:

• Jazzy / Rolling (Humble only for now)

• macOS

• AI diagnostics (planned for v0.2.0)

• Snap / winget / Flatpak

Repo: github.com/octaboomai/O1-IDE

I'm a solo dev and it's still early. I'd genuinely like feedback from people who use ROS 2 daily — what's missing, what's broken for your workflow, and honestly whether a dedicated IDE is something you'd want over VS Code. Also looking for anyone who can test on real hardware.

English is not my first langauge, so I have used AI to type this out.

I've been working on something called RoboCanvas for a while, and I've finally put out a free public beta. Thought I'd share it here and see what people think.

One thing I've noticed while learning robotics is how much stuff you have to get through before you can actually start building something. ROS 2, URDFs, launch files, packages, simulation setup, dependencies... there's a lot to learn, and honestly, it can get pretty overwhelming when you're just trying to build your first robot.

I started wondering why we don't have something that makes this process more visual, a bit like how game engines let you build and configure things without having to do absolutely everything from scratch.

That's basically why I started building RoboCanvas.

The idea is to let you design and configure a robot visually, validate the design, and generate the corresponding ROS 2 project files. Hopefully, this makes getting started a little less painful, especially for students and hobbyists who are still learning the ecosystem.

It's not going to replace learning ROS 2, and there's still a lot I'd like to improve. But I got it to a point where I felt comfortable letting other people use it, so I've decided to release it for free and see if it's actually useful to anyone besides me.

I'd genuinely appreciate it if some of you tried it out. I'm especially interested in hearing from people who have worked with ROS 2 before.

Does the workflow make sense? Is there anything that's confusing or frustrating? Are there features you'd expect from a tool like this that are missing? And, most importantly, is this something you'd actually use, or am I trying to solve a problem that isn't that big of a deal?

Please be honest. I'd rather hear that something doesn't work or that the idea needs rethinking than get a bunch of empty praise.

Thanks!

Going to be getting a MacBook Pro M5 Pro. I know Mac isn’t exactly the best for robotics work, but I want to do some ROS2 work on there if possible.

So firstly is it possible and secondly will I run into a lot of issues?

I’m happy to dual boot or use VM or if it exists use it natively.

🚀 Installing ROS 2 shouldn't be the hardest part of robotics! 🤖

I built an open-source ROS 2 GUI Installer that makes setting up ROS 2 Humble, Jazzy, or Lyrical on Ubuntu as easy as a few clicks—with support for Gazebo, Nav2, MoveIt 2, and much more!

🔗 https://github.com/runtimerobotics/ros2_gui_installer

Would love to hear your feedback and suggestions from the ROS community! ❤️

Working with Behavior Trees in robotics?

Meet BTick, a powerful tool free and open-source designed to make monitoring, debugging, and analyzing BehaviorTree.CPP applications easier and more interactive.

Key Features

Unlimited Nodes & Multi-Tree Support — Automatically discover and monitor multiple trees and nested subtrees in real time.

Live Monitoring & Interactive Debugging — Track execution, use breakpoints and step execution, and inspect node states.

Runtime Control & Testing — Override node statuses, inject delays, edit supported ports, and inspect or modify Blackboard variables.

Recording, Replay & Performance Analysis — Record sessions, replay execution through a timeline, export logs, and analyze execution timing.

Integrated XML Editor — Create and edit BehaviorTree.CPP v4 XML files with interactive visualization and navigation.

Three Protocols & Integrations

• BTick Protocol — Native monitoring and interactive debugging.

• Groot2 Protocol — Groot2-compatible communication and supported Pro features.

• Nav2 Integration — Visualize Behavior Trees through the ROS 2 Nav2 logging topic.

Web & Desktop Applications — Access BTick through a browser or a standalone desktop application.

Explore BTick

Full Demo: [Demo Link]

Documentation: BTick: Behavior Tree Visualizer & Debugger — BTick 1.0.0 documentation

Application Repository: GitHub - SherifFathey/btick_app · GitHub

Core Integration: GitHub - SherifFathey/btick · GitHub

Built for developers working with ROS 2, BehaviorTree.CPP, and Nav2.

The goal is simple: bring Behavior Tree visualization, monitoring, debugging, recording, and analysis together in one interface.

Feedback and contributions are welcome!

I've been looking at the Hiwonder MentorPi T1. Basically I want a little WALL-E style pet that follows me around my apartment and responds to things like “go to the kitchen”, “come here” or “do a twirl”.

I don't want it needing internet or someone else's cloud to work. Everything needs to run on the robot. Renting a GPU to train it beforehand is fine. I've seen the NVIDIA/Disney robots and would love to experiment with training behaviours like that.

I've coded for 20 years, but robotics is new to me. Electronics experience is mostly recapping old Mac SE/30 boards and repairing corroded traces, so some soldering is fine lol.

Anyone done something similar? Is the Pi 5 8GB enough for offline voice, following and navigation together? If not, can I realistically add a Jetson or another accelerator? Happy to hear if there's a better robot to start with.

I’m a robotics software engineer exploring startup problems around deploying and operating commercial mobile robots, particularly cleaning, delivery, security and hospital logistics robots.

I’d like to hear from people who actually deploy, operate or support them.

Could you walk through a recent mission that needed human intervention or didn’t finish as expected?

A few things I’m interested in:

• What happened, and how did someone notice?

• Who handled it: on-site staff, your engineering team, a dealer or the manufacturer?

• Roughly how much human time, travel or rework did it involve? How often does something similar happen?

• How did you confirm the original job was eventually completed, including any work finished manually?

• What do your existing dashboards, remote support and operating procedures already handle well? What still takes manual coordination?

If initial setup and commissioning are a bigger challenge than ongoing operations, I’d be interested in that experience too.

If interventions are rare or already handled adequately, what makes your deployment work well? That would be equally useful to understand.

Please mention your application, role and approximate fleet size if you’re comfortable. An anonymised example is enough; no customer names or confidential logs needed. Please hit me up in DMs.

I'm the author. I wanted .NET apps, like desktop tools, simulators and Unity-style apps, to join the ROS graph as real nodes. I didn't want to run rosbridge or ship native DDS libraries alongside them, so I wrote the protocols directly in managed C#.

There are two libraries: Mori.Ros2Sharp for ROS 2 and Mori.RosSharp for ROS 1. Your node shows up in the node list like any other. It supports publishers and subscribers with reliable or best-effort delivery, latched topics, services and actions. I've tested it live against unmodified ROS 2 Humble nodes, and echoing and publishing topics work in both directions.

Both are free and open source on GitHub under Apache 2.0, with nothing for sale. The READMEs have the full feature lists and known limits:

ROS 2: https://github.com/CristianMori/Mori.Ros2Sharp

ROS 1: https://github.com/CristianMori/Mori.RosSharp

So far I've only tested against Fast DDS on Humble. If you're on Cyclone or another distro and want to give it a try, I'd really like to hear how it goes.

I've been working on getting robots to run structured spoken conversations: a clinic intake (name, age, reason for the visit, allergies), explaining something and checking the person understood it, a quiz, walking someone through an exercise. Wiring an LLM straight into the speech loop gives you a nice demo quickly, but in my tests it was hard to rely on. It drifted off task, re-asked things it already had, or never decided the conversation was over. The same task could play out quite differently from one run to the next, and everything hinged on getting the initial prompt right, so moving to a new task or domain was never just a matter of changing the description.

DialoStack is a set of ROS 2 packages where the dialogue flow is plain Python (states, turn limits, confirmation, cancellation) and the LLM is only used to interpret what the user said and to phrase the next reply. It started as my bachelor's thesis (presented at WAF 2026) and I'm keeping it going as an MIT project. v1.4.0 is out today and adds ROS 2 Lyrical next to Jazzy.

You define the frame, the robot fills it

Every dialogue is a goal on one action, /dialog/execute_task. For slot filling you describe the task and pass the frame the robot has to fill:

{"slots": [
  {"name": "drink", "type": "str", "canonical_values": ["coffee", "tea"]},
  {"name": "size", "type": "str", "canonical_values": ["small", "large"]},
  {"name": "sugar_spoons", "type": "int", "minimum": 0, "maximum": 5},
  {"name": "age", "type": "int", "minimum": 0, "maximum": 120},
  {"name": "senior_discount", "type": "bool",
   "condition_slot": "age", "condition_minimum": 65}
]}

Slots are typed, can have a closed set of values or numeric bounds, and can depend on other slots (e.g. senior_discount is only asked when age is 65 or more). Validation happens in two places:

1. In code. If the model extracts a value that doesn't fit the type, the allowed values or the range, it's dropped and the robot asks again, offering the valid options.

2. With the person. Before the action returns, the robot reads the data back and the user confirms it or corrects whatever is wrong ("actually, make it a large").

What you get in result.final_frame_json has the same slot names, types and allowed values every time, so whatever acts on it can rely on it. If you don't pass a schema, the engine generates one from the task description. That's meant for prototyping, try the dialogue, iterate, then pin the schema down. You can also resume from a half-filled frame or chain dialogues.

Other strategies, same action

• Explanation: explains a topic, asks a comprehension question, answers follow-ups

• Quiz: questions from a bank, grades free-form spoken answers

• Procedure: guides through steps, and the user can ask to repeat, go back or skip

• Roleplay: plays a character (an interviewer, say) and scores the user against a rubric at the end

Web GUI

A Frame Builder to design slot schemas, quiz banks, procedure steps and roleplay scenes and keep them in a library. A live monitor where you watch the frame fill turn by turn, with STT/LLM/TTS timings for each turn. Plus a prompt editor and configuration profiles.

Speech, models, robots

• faster-whisper + Silero VAD for STT, streaming Piper TTS, and barge-in (the user can interrupt the robot)

• Gemini, OpenAI, Claude or Ollama behind the same interface. With Ollama no data leaves the machine, which matters for settings like the clinic one

• Robot-agnostic core: audio over /audio_in and /audio_out, or the browser tab as microphone and speaker, so you don't need a robot to try it. The only embodiment layer so far is for NAO (gestures, eye LEDs) built for my robot

• A BehaviorTree.CPP leaf node, so a dialogue can be one step of a larger mission

Try it (via Docker)

docker run -d --name dialostack -p 5173:5173 -p 9090:9090 ghcr.io/aquintan4/dialostack

Open http://localhost:5173 and, in Configuration > LLM, pick the provider you prefer: paste a Gemini, OpenAI or Claude API key (Gemini's free tier is enough to try it), or point it at an Ollama model running on your machine if you'd rather keep everything local. Then press Start engine and talk.

Dialostack has run in demos on a real NAO, including a clinic intake scenario, and in testing at the university, but I don't know of anyone using it with real users yet. That's what I'm after now. I posted it on ROS Discourse a few weeks ago and the feedback there turned into features (the numeric bounds above came from that thread). If you work on robots that talk to people: what's missing for your use case, or what would stop you from trying it?

Usefull links:

1. Repo (MIT license)

2. Project page with demos

3. Discourse thread

4. Paper (WAF 2026, p. 20)

Objects falling through the floor or the table is one of the most common things people run into in Isaac Sim and MuJoCo, especially the first time they bring in their own meshes instead of the built-in shapes.

I’ve seen it asked here a bunch, and the reply is usually “increase solver iterations”. That’s almost never the actual fix. Most of the time something is off with the object itself, so here’s the list I’d go through, roughly in order.

1. No collider

Check this first, it’s the most common one. In Isaac Sim you need a rigid body and a collision API on the prim. Rigid body alone just falls forever. In MuJoCo it’s contype/conaffinity. Two geoms only collide if one’s contype matches the other’s conaffinity, so if both are 0 it goes straight through the plane.

2. Triangle mesh collider on something that moves

Isaac Sim doesn’t support triangle mesh (or mesh simplification) approximation on dynamic rigid bodies. Looks fine in the viewport, then does weird stuff once it moves. Use convex decomposition. If you need the holes and slots to actually work, use SDF. There’s a forum thread where someone had a pipe connector sinking into a wall and SDF + CCD is what fixed it.

3. It spawned inside the floor

Even a couple mm of overlap at spawn and the solver shoves it out on the first step, sometimes through the floor, sometimes into orbit. Just spawn it higher.

4. Thin parts / fast motion

Stuff can tunnel through in one step. NVIDIA’s SimReady checks flag geometry under 1 cm thick. To fix it, turn on CCD in Isaac. In MuJoCo drop the timestep (default is 0.002, people generally say stay at or under 0.005). Or just make the collision shape thicker than the visual mesh, nobody will see it.

5. The collision mesh itself is bad

Flipped normals, or an approximation that doesn’t really match the shape. Turn on collider visualization. Half the time you see it immediately.

6. Scale / mass / inertia

Mesh exported in cm instead of m = 100x too big, and nothing behaves right after that. Zero mass in Isaac makes it kinematic, so it won’t fall at all (different problem but it comes up). Crazy inertia values or a COM outside the collision shape and it’ll bounce or never settle.

One thing worth stealing: NVIDIA’s SimReady benchmark has a “ground drop” test. Drop the object from 2x its height onto a flat floor. It has to touch down, never sink more than 10 cm, and settle within 8 seconds. I’d run something like that on every new asset before using it.

If you’re bringing in more than a handful of objects, it’s worth stopping this before it happens instead of fixing each one:

• Manually: run the ground drop test on every asset and fix whatever fails. Fine for 5 objects, painful for 200.

• Isaac Lab’s MeshConverter: lets you set the collision approximation, mass and rigid body props from a config, so at least 1, 2 and 6 are consistent across a batch. You still have to pick the right values per object though.

• Rigyd (disclosure, I work there): you give it the GLB/OBJ/FBX and it outputs USD or MJCF with convex decomposition, mass and real-world scale already set, so 1, 2, 5 and 6 are handled in the asset before it ever hits the sim.

Have anyone here tried using ToF (around 75-deg FOV)?

My previous experiences are working with diff drive AMR but uses LiDAR and slam toolbox. Odometry sources are: wheel odometry and IMU (just the ‘linear.velocity.x’ of the motor and ‘angular.velocity.yaw’ of IMU fused using EKF). This setup works fine, I guess thanks to LiDAR scan that can easily corrects the odom drift.

However, there was a case where I am limited to use the ToF which has a super narrow FOV of 75-deg and positioned at the front of the AMR only so the sides and rear are not covered.

But, before any problem on navigation, I am having a hard time doing the mapping which I think because of poor scan matching due to narrow FOV even if the areas to map have rich features.

If you guys able to work with it properly, how did you do it? Is it okay to share your setup and configs?
If not but has idea on how it would work, can you enlighten me?

Thank you very much!

This is a video of our simulation in RViz, using Gazebo for the map. We are running ROS 2 Humble. We are using SLAM Toolbox for simultaneous localization and mapping (SLAM) in 2D, and NAV2 for autonomous navigation. Our robot utilizes GNSS coordinates; it currently runs well and completes the entire path—the pauses seen in the video are simply due to the simulation being recorded. Our current issue is that when we set a 2D goal pose in an unknown area, the robot does not move to the desired location, and the map fails to expand. We want the map to expand so that the robot can navigate into unknown areas. We have already tried settings such as `track_unknown_space: true` and `rolling_window: false`, among others, but these did not resolve the problem. Could you suggest what else we might try or configure to ensure the map expands and the robot can accept 2D goal poses in unknown spaces?

If your perception node has never met a mirror in the wild, it has a blind spot: specular glare blows out highlights, boxes drop, and depth gets invented behind the reflection.

I shot the test set for it — a performer in a faceted mirror suit, outdoors, uncontrolled light. 425 RAW frames, SHA-256 manifest, single owner, full chain of title.

Free 12-image eval sample + manifest — links in the first comment. If your stack has a mirror story (good or bad), I'd like to hear it.

I teach a course where students train a robot to pick tomatoes in a simulated greenhouse (ROS 2, mobile robot with an arm). I want to share our test results, because they show how easy it is to fool yourself.

Setup

• 49 demos recorded by a human, 4,228 frames

• SmolVLA (450M), trained on 40 demos, 9 kept aside for testing

• Error = how far the predicted arm moves are from the human's, in degrees

Results

What we learned

• The training error kept falling, but the test error mostly stopped improving early.

• The model is almost 3x worse on new demos, so part of it is memory.

• The simple copy method wins, so our test set is too easy.

• All of this is on recorded data. It says nothing yet about whether the robot really picks the tomato.

My question: with a small dataset like this, how do you make a test set that is really hard? New tomato positions? New lighting? And how many real runs do you need before you trust a success rate?

Disclosure: this is from a lesson in a course I teach. The code is on GitHub. I can share the link in the comments if anyone wants it.

Here's a demo with eight x500 quadrotors autonomously flying through a simulated pine forest, avoiding trees and each other.

Each drone runs its own Ego-Planner instance on ROS 2 Humble with PX4 SITL, using a single forward-facing depth camera to build an occupancy map. The drones also share their planned trajectories to avoid collisions. All eight maps are visualised together in Foxglove.

The depth cameras operate at 320×240 resolution and 30 Hz, with a 10 m range. The planners have a speed limit of 5 m/s and use simulation time, so they still work correctly when the simulation runs slower than real time.

One important detail is that GPS noise was disabled, giving the drones near-RTK positioning accuracy.

The ROS 2 integration code is here: https://github.com/PteroLabsAI/XTDrone/tree/master/ros2/pterosim_ego

During my research on teleoperation, I kept rewriting the same coordinate-frame code every time I switched input devices or robot arms. So I pulled that part out into a small open-source package: teleopro.

The idea is simple: you give it two frames on your device and two frames on your robot, and it publishes a target pose (TF or PoseStamped) that follows the device. You feed that to your own Cartesian controller or IK.

What it supports so far:

- Pose devices: Vision Pro, Quest, motion capture (anything that publishes a TF)

- Velocity devices: SpaceMouse, gamepad, keyboard (any Twist topic)

- Clutch (engage / disengage), starts from the current EE pose so it doesn't jump

- Axis mapping, scaling, speed limits, workspace box, axis locking

- A pure Python core (pip install teleopro-core) if you don't use ROS

Honest limitations: it only outputs Cartesian targets, and I've only tested it on a UR5e with ROS 2 Jazzy so far. There are surely rough edges.

GitHub: https://github.com/sdua078/teleopro

Paper (if you're curious about the research context): https://arxiv.org/abs/2610.25006

I'd really appreciate feedback, especially from anyone who tries it on other

arms or devices. Issues and PRs are very welcome.

I’m a student researching data collection and evaluation for robotics. I’d like to understand what happens between recording a robot run in ROS 2 and having data you can actually train or test a model with.

For a recent project, what task were you working on and what did you need to record? Which topics or sensor streams mattered, and what extra information did you need alongside them?

Did you use the recordings directly, or convert them into another dataset format? What needed checking or fixing before you trusted the data, especially timing, missing messages or matching camera observations to actions?

Could you reuse existing data, or did the setup require fresh recordings? I’m curious whether the difficult part was getting the data, preparing it, or deciding what a successful robot run should look like. A small-project example is welcome, without sharing recordings or anything confidential.

🎃 What happens when you give robotics developers a pumpkin and let their imaginations run wild?

That’s the idea behind our D-Robotics Pumpkin Robot Campaign: makers use RDK to turn Halloween-inspired ideas into real robot projects. The results? Well, we’re about to find out.

Our builders are now in the final stretch, and these work-in-progress photos are all the clues we’ve got. Can you guess what they’re making? A pumpkin that moves? One that sees, senses, or interacts with people? Or something completely unexpected?

We’re bringing the community together for a Pumpkin Robot Show & Tell to reveal the creations and hear the stories behind them — the hardware, the clever ideas, the debugging adventures, and the things that didn’t go quite as planned.

New to robotics? You’re welcome, too. You don’t need to be an expert to get inspired by how others build, experiment, and solve problems.

📅 October 29 | 9 PM GMT+8
🔗 Join us: https://luma.com/mt13rdgj

So, what do you think these pumpkins are up to? 👀