c/robotics

Hello Everyone, I am preparing my manuscript for upcoming ICRA'27. But They have page limit of 8 pages, including references. As well, They don't accept any supplementary documents. So my question is how can I show more experiments and ablation studies? Because 8 page is not sufficient. Any tips? Much appreciated!! submitted by /u/selim_sarowar [link] [Kommentare]

Took apart an industrial QDD actuator today and found the internals interesting. It's a different feeling when you can actually look at how they are integrated. submitted by /u/Cubemars [link] [Kommentare]

Since I'm absolute unsure of about the hardware, I'm having second thoughts on the below: Motors - BetaFPV 0802SE Brushless Motors 4pc - 19500KV DSC: FLYWOO GOKU F405 HD 1-2S 12A AIO ELRS (ICM42688) ESP32 ESP32-S3 Development Board AYWHP ESP32 S3 ESP32-S3-DevKitC Module with WROOM-1-N16R8 Low Power MCU with Dual-Mode Wi-Fi and Bluetooth Type-C Connector Compatible with Arduino BETAFPV BT2.0 Battery Charger and Voltage Tester V2 BetaFPV BT2.0 550mAh 1S 40C HV LiPo Battery High Voltage Rechargeable Batteries With BT - 2.0 Connector For FPV Racing Drones Tiny Whoops and Micro Quadcopters Pack of 4 submitted by /u/Needlesssalt [link] [Kommentare]

This article looks at some of the common sensor integration challenges in motion control, including signal compatibility, communication protocols, environmental noise, and the growing demand for smarter feedback systems. As robots, AMRs, machine vision systems, and motion control platforms get more advanced, the challenge is not just adding more sensors. It is making sure the data is usable, synchronized, reliable, and actually helps the system make better decisions. As submitted by /u/Responsible-Grass452 [link] [Kommentare]

Hey everyone, I've been talking to a lot of robot engineers and kept hearing the same frustrations: - Debugging ROS2 errors takes hours - Setting up proper logging is painful - Writing boilerplate nodes wastes expert time So I built **Mechis** — a free AI co-pilot specifically for robot engineers. **What it does:** - 🐛 **Debug** — paste your error or stack trace, get the exact fix - 📋 **Logging** — describe your robot setup, get a complete ROS2 logging config - ⚙️ **Code Gen** — describe what you want in plain English, get clean ROS2 Python code **Try it free here:*\* mechis-neon.vercel.app No signup needed. Just open and use. --- **I'd genuinely love your feedback:** Did it actually help or was the answer generic? What's missing that you wish it had? What's the #1 ROS2 problem you face daily that a tool like this should solve? Would you pay for this? submitted by /u/According_Koala4857 [link] [Kommentare]

Hi all, just wanted to share a small project I built over a few robotics series. This one builds on top of the mycobot 280pi that I won from a competition, thought it was a fun project to learn with MoveIt2. The raspi itself ran extremely slow, so I had to find an alternative to control from another PC to run the MoveIt and Computer Vision applications via TCP. Feel free to check it out. submitted by /u/OkThought8642 [link] [Kommentare]

Spent the last few weeks on a benchmark/harness that tries to answer one question honestly: did a robot arm actually do the demonstrated task, or did the success metric just get fooled? The setup: compile a human demo into an object-centric graph (what changed in the world: relations, contacts, event order), run a solver, then independently extract a graph from the rollout only and check if they match. The whole point is a hard information boundary so the "answer key" can never leak into the side that grades the rollout. A no-op baseline fails with named failure classes; a dumb scripted arm passes. That contrast is the thing I care about. Most manipulation success metrics are hand-coded predicates written by the same person training the policy. The policy author controls both the behavior and the definition of "success." That's a conflict of interest we'd never accept in ML benchmarking, yet it's standard in manipulation eval. But I keep going back and forth on whether this matters, and I'd like other people's read: The case that it's real: VLA/foundation-model training is starved for reliable dense reward at scale. Human raters don't scale, brittle predicates lie. An automatic, embodiment-agnostic grader that can say "this rollout reproduced the demonstrated transformation, here's why it failed" seems like an obviously-missing piece of the training loop. The case that it's a non-problem: maybe everyone's already fine with task-specific success checks because in practice you only care about the tasks you're shipping, and a general verifier is solving for a generality nobody needs. And the representation that makes verification tractable (discrete relational state — INSIDE/TOUCHING/event-order) is also what caps it: it handles pick/place/insert/open-drawer but has no obvious purchase on force-profile or deformable tasks, which is exactly where the frontier is. There's also the uncomfortable bit: the hard 80% is perception (video → graph under occlusion and contact noise), and that's where the leakage discipline gets harder, not easier, because your extractor is now a learned, error-prone thing. Two questions I don't have a settled answer on: Is reward/eval honesty a first-order bottleneck for the current generation of manipulation learning, or second-order polish? Is object-centric relational state a dead representation for where manipulation is actually going, or a reasonable floor you build up from? submitted by /u/Alexpplay [link] [Kommentare]

Driver rewrite was expected part. What got us was everything downstream that was quietly depending on old sensor and nobody documented it. New sensor's X-axis points a different way, your TF was written around the old one, and now everything's subtly rotated but nothing throws an error. Rate doubles and you're retuning Kalman gains you thought were settled. And then power rail - a different draw, nothing to debug on software side, just had to find it by elimination. Every single one of these was invisible until we actually swapped sensor. Sensor swap is probably most honest test of whether architecture is actually modular or just looks modular in README, and I'm not sure if our codebase was just particularly messy or this is how it always goes. submitted by /u/NickShipsRobots [link] [Kommentare]

This was my first time using ESP32, I used S3 Supermini because of its compact size which I needed to make this small pocket sized/keychain robot. ​ I am calling it MiniSoul, as it is smaller version of a robot that I am working on called SoulBot. ​ At its core it uses a behaviour engine I built which dictates it's behaviour based on the past interaction which affects different personality factors like Fear, Joy, Curiosity,Desire,Sadness and Anger. ​ The interaction is using touch plate on the top by measuring capacitance and it differentiates between tap, aggression and caress based on small kNN model. ​ I am also using seperate RTC module to give clock functionality like alarm/reminder and also the EEPROM on the RTC module is used to store personality states, storing personality on external EEPROM means it survives OTA firmware updates, not just power cycles. Also this would not damage the storage after multiple write cycles like it would to the flash memory. ​ For touch classification I have used KNN model also on device data collection for touch tuning as every casing varies slightly. ​ The whole MiniSoul OS is built on top of micropython which also allows OTA updates. ​ submitted by /u/SobyDamn [link] [Kommentare]

From Litian Liang on 𝕏 (thread with multiple videos): https://x.com/litian_liang/status/2066541466286215570 This work is done in Inclusion AI lab at Ant Group, advised by James (Jingxi) Xu and Professor Mark Cutkosky from Stanford BDML lab. Website: https://ume-exo.github.io Paper: https://arxiv.org/abs/2606.14218 submitted by /u/Nunki08 [link] [Kommentare]

Hey r/robotics, A while back I posted asking for name suggestions for my new mobile robot platform. Last time around, you guys gave me Arctos for the 6-DOF arm. This time, the top upvoted comment was Cary McCarface. So, officially, the robot is designated Arctos CMC. The "CMC" stands exactly for what you think it does. I finally finished the full build and just put together a quick video showing it driving around and doing its thing. Despite the ridiculous name, a lot of engineering went into making this thing work on a budget. If anyone wants to build one of these themselves, I’ve made the CAD files available. I’m also working on putting together a hardware kit that will be coming soon, but until that's ready, the full Bill of Materials (BOM) is available so you can source the parts yourself. submitted by /u/ganacbicnio [link] [Kommentare]

Hi reddit, I've built an accessibility app that helps people with mobility issues play video games hand-free and now we're developing a human-robot interaction for robotic systems. This HRI can help teleoperation of robots by providing a more precise and faster input method by using person's head movements to guide mechanical actuators, robotic arms etc. in combination with regular controllers. We are looking for a use-case provider with the profile of industrial company or infrastructure owner providing the industrial testbed, defining the use case for inspection and maintenance. And would like to join us in the JARVIS open call 2: external pilots stream. Any advice on finding someone for such a project is also VERY APPRECIATED. We are new to robotics industry and would love to make it happen as this HRI can also help a lot of people with mobility issues to control things in their day to day lives, like wheelchair robot arms or assistive robots. If you know anyone we could reach out to, please don't hesitate to DM me or comment. Thanks! submitted by /u/SensePilot [link] [Kommentare]

Payload 5kg, reach 704mm 6-axis industrial robot industrial arc welding, high-speed industrial assembly robots, pick and place etc. submitted by /u/Iris-lee88 [link] [Kommentare]