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.

Hope i get some feedback and I'm open to other options if you do know of any better stack for this use case :)

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?

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.

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

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’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'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)

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!

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.

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 starting a master’s in two months, working on vision-guided grasping and end-effector integration for humanoid robots. I have experience in Mechanical Design mainly .. have worked with ROS, and computer vision in college but want a better understanding of humanoids as a complete system.

My rough plan is below: start with anatomy and hardware, then arm movement and control, then some simulation. I learn best through practical examples rather than heavy maths.

Any recommendations for accessible resources, or changes you’d make to the plan? Also happy to connect with anyone interested in studying together.

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? 👀

I’ve been building a ROS 2 stack for the SO-101 arm, and it now runs on my physical arms.

What it does:

• Simulate the arm in Gazebo Harmonic, or run it headless on fake hardware
• Plan and execute motions with MoveIt 2
• Drive the real follower arm through a ros2_control hardware plugin (C++, Feetech STS3215 servos)
• Teleoperate the follower with the leader arm, all in ROS 2

How it works: you calibrate the arms once with LeRobot. The stack reads that calibration and checks it against the servos before enabling anything. After that, everything runs in ROS 2 without LeRobot.

Ubuntu 24.04 + ROS 2 Jazzy, open source (BSD-3). Feedback welcome!

https://github.com/adoodevv/so101_ros2

Researching tooling for robotics developers, would love to know your ROS stack and how long does it take to set up, which software do you use, any bottlenecks, which operating system does your ROS run on?

Hi everyone! I've been building Afferent-Omni, an industrial-grade Command & Control (C2) framework designed for real-time visuo-tactile sensing, closed-loop manipulation, and embodied AI evaluation.

🔬 Key Features:

• FastAPI Backend: 9 modular routers, 15 REST endpoints, and 50 Hz closed-loop WebSocket streaming.
• Omni-Tier Telemetry: Integrated neuromorphic reflex arc (<15 ms latency), multi-digit topology, and acoustic friction profile.
• Interactive 3D HUD: Real-time gel deformation mesh, dynamic force-vector arrows, and HSL glow spheres in Three.js.
• Sim2Real Safety Shield: Dynamic force budget calculation and zero-shot grasp planning.
• LLM Copilot & SQLite Persistence: AI assistant contextualized with live streaming telemetry.

💻 GitHub Repo:https://github.com/raulrodriguezmesia-blip/afferent-omni

🌐 Live Showcase: Includes a standalone lightweight C2 HTML dashboard for quick testing.

Feedback, stars, and contributions are very welcome! Let me know your thoughts on tactile feedback integration for robotics! 🤖✨

There are 20 physically interactive robot simulations based on real New York/New Jersey locations you can download from that HF link. Isaac Sim and MuJoCo supported. I am part of this project.

Background: NYU's AI4CE Lab, along with Cornell researchers, scanned 500+ locations in New York and New Jersey. They combined large-scale real-world capture with metric geometry and photorealism. The result provides simulation environments for robot navigation. This project is called Wanderland (CVPR 2026 Highlight - https://ai4ce.github.io/wanderland/).

So this past Tuesday, the Wanderland team suggested over a call that my independent team convert a subset of their scans into interactively and semantically rich 3D environments for simulators.

We followed up on that; creating interactive, editable, part-aware 3D digital twins/cousins where robots experience articulated mechanisms and physics down to the object level. E.g. where doors and gates can swing physically, drawers can open, free objects can be pushed or dropped, and surfaces have configurable friction.

Converting these 20 locations took us ~36 hours.

We used NYU's scans for 10 locations, but NYU's photographs for the other 10 (to showcase the range of the capability).

We've developed a grounding harness that constructs everything using the AI base model of our choice: https://github.com/RareSense/Nova3D.

So in this case, specifically we:

(i) Produced digital twins/cousins of entire environments with functional, articulated constituent parts
(ii) Delivered elaborate semantic annotation. I.e. ranging from posters on walls, light switches, door handles, down to different components of complex objects like vehicles (wheels, etc.) come with their individual semantic annotation.
(iii) PBR-grade texturization was applied to give a real-world feel.

---

Happy to collaborate with anyone (academia/corporate/startups/hobbyists), or answer questions, or generally discuss the pros/cons of what we did. And if you want to reach out to the Wanderland team - the project URL above will give you the requisite contact details.

I also specifically invite interested parties to try our interactive simulations independently. And if you do, please share the results back. Both successes and failures are super duper valuable!

I have a followed the official guide here:
https://docs.ros.org/en/lyrical/Get-Started/Installation/RHEL-Install-RPMs.html

I noticed the instructions to add the repo is:

sudo dnf install curl
export ROS_APT_SOURCE_VERSION=$(curl -s https://api.github.com/repos/ros-infrastructure/ros-apt-source/releases/latest | grep -F "tag_name" | awk -F'"' '{print $4}')
sudo dnf install "https://github.com/ros-infrastructure/ros-apt-source/releases/download/${ROS_APT_SOURCE_VERSION}/ros2-release-${ROS_APT_SOURCE_VERSION}-1.fc.noarch.rpm"

However, when I run:

sudo dnf install ros-lyrical-desktop

It says the package cannot be found. Am I doing something wrong?

I'm building batchplan-ros: send several candidate grasp poses in one request, plan to them in a batch, and keep the shortest valid path.

It speaks MoveIt's MoveGroup and GetPositionIK interfaces, runs on CPU, and has an optional MoveIt planner plugin. The browser Panda demo is three commands away:

git clone https://github.com/natsuku-lab/batchplan-ros

cd batchplan-ros

pixi run demo

Open http://localhost:8080. ROS 2 Jazzy, Linux or Apple-silicon macOS; no GPU required.

ROS entry point: https://github.com/natsuku-lab/batchplan-ros

Standalone Rust library: https://github.com/natsuku-lab/batchplan

LeRobot dataset guide: https://github.com/natsuku-lab/batchplan/blob/main/docs/training-data.md

These are entry points to the same project. It's early and uses sphere-based robot collision geometry. I'd love feedback from anyone trying it with their own robot.