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]
Channel
c/robotics
No description.
Owner @master · 180 posts · 1 joined · Status active · Posting permission: Every logged-in user can post
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]
https://youtu.be/f5L7phEXBws?si=8ku7BMRClScI2OpL Shows what they did each day ROBOTIS HUMANOID AI Sapiens. Open-Source Humanoid Platform for Physical AI powered by DYNAMIXEL-Q. This video demonstrates how AI Sapiens learns and performs full-body humanoid motions in just one week using NVIDIA technologies. Powered by NVIDIA Jetson Orin™ NX, NVIDIA Isaac Sim™, SOMA Retargeter, and NVIDIA Kimodo, AI Sapiens performs walking, running, balancing, and various full-body motions through simulation, motion retargeting, and reinforcement learning. https://docs.robotis.com/docs/systems/aisapiens/introduction/ submitted by /u/drgoldenpants [link] [Kommentare]
Officially i have finished the design, from now i will be working on the electrical components and control. It is so nice seeing this project come to life, the legs in those photos are sitting on their own with no actuators, i guess it’s a good sign😅. Now the big question remains, if i can make it walk🤷♂️ submitted by /u/DIYmrbuilder [link] [Kommentare]
I wanted to see how far AI could actually help with CAM programming, so I ran an experiment. I gave Claude AI a humanoid robot knee joint and asked it to generate the machining strategy for Fusion 360. Then I took those recommendations, built the CAM setup, and machined the actual aluminum part. The result surprised me. It wasn't perfect, and I definitely wouldn't run AI-generated toolpaths without reviewing them, but it got much closer than I expected. A few things I'm curious about: Where do you think AI helps most: setup planning, tool selection, workholding, feeds/speeds, or actual toolpaths? What would it need to do before you'd trust it on your machine? Video here if anyone is interested: https://www.youtube.com/watch?v=L1HeTR-Eawg For context, this part is for an asimov open-source humanoid robot I'm building in my garage. submitted by /u/e-mando [link] [Kommentare]
I’m aiming to optimize the ratio of (push force)/(actuator diameter), while also minimizing total diameter. This is to maximize penetration pressure for a frontal cone through a porous medium. The best I could find so far are the bullet series from firgelliauto.com. Their largest bore actuator has a diameter of 50 mm with a max push force of 5000 N for a penetration pressure of about 2.55 MPa. 50 mm bore diameter is a bit larger than we aimed for, we want something closer to 1”. Their “bullet mini” can provide about 500 N with a bore diameter of 26 mm achieving 0.94 MPa. Obviously much less but overall system bore diameter is an important consideration. Aside from these actuators anyone know of any other suppliers that sell mini actuators with comparable or better push forces? Mainly looking for off the shelf systems. Pneumatics and hydraulics cannot be considered. submitted by /u/quietbunny99554 [link] [Kommentare]