While experimenting with GRPO training, I kept running this shit that when reward increases, it becomes difficult to tell whether the policy is genuinely improving or simply exploiting the reward function. So I built a small library called rewardspy that wraps an existing reward function and continuously monitors indicators that often precede reward hacking. It currently tracks things like rolling reward statistics, reward variance collapse, reward component imbalance, response length drift, reward slope changes, GRPO group collapse, anol. This is my first major RL project so I would absolutely love some technical advice Check it out here: https://github.com/AvAdiii/rewardspy submitted by /u/BaniyanChor [link] [Kommentare]
I have to use a Unitree Go1 with a jetson AGX orin strapped to it for a university project. It's so hard to iterate because as soon as I get close to making progress, I have to power the whole thing off and replace the battery. Now I know you should run heavy processing offline and communicate with the robot over a network, but what I am doing is basically ROS2 troubleshooting for which I need the setup exactly as it will be during deployment. Exactly how is this "robotics revolution" powered by vision-language-action models supposed to work, when the most popular quadruped cannot even power a jetson for more than 15 minutes standing still??? I always thought VLA was an impractical idea, but now I am even less convinced. submitted by /u/EchoImpressive6063 [link] [Kommentare]
I released MetriPlane v0.2.0 and am preparing a SoftwareX research-software paper while finishing my MSc thesis. 3-minute demo: https://www.youtube.com/watch?v=7U5nbBbGGbw Repo: https://github.com/Miko997/metriplane Zenodo DOI: https://doi.org/10.5281/zenodo.20736619 MetriPlane is an observe-only physical-observability tool for bounded workcells. The v0.2.0 demo shows a replayed missing-tool event becoming: - physical event log - Cell Truth Report - evidence bundle - local bundle verification - generated regression test The goal is not robot control or safety certification. The goal is replayable evidence: what physically happened, what proves it, and whether the incident can become a repeatable software check. I am looking for technical feedback from robotics, simulation, manufacturing, digital-twin, and research-software people. Public reproduction issue: https://github.com/Miko997/metriplane/issues/6 I am especially interested in: Does the camera-free reproduction path work on other machines? Is the evidence-bundle / regression-test loop useful? Are the limitations clear enough? What should be validated next? Scope: - observe-only - planar/tagged assets - no robot or machine control - no safety certification - no marker-free tracking claim - no production deployment claim Useful feedback format: OS: Python version: doctor: pass/fail deterministic replay: pass/fail Atlas run: pass/fail bundle verify: pass/fail generated regression test: pass/fail Technical relevance: 2–5 sentences Main limitation: 1–2 sentences Critical feedback is preferred. submitted by /u/No-Editor-8797 [link] [Kommentare]
Disclosure: I work with a commercial robotics data collection team. This is not a sales post. I've been comparing different human-demonstration formats for robot manipulation, and I'm curious which configuration researchers find most useful for initial testing. The main options seem to be: • Egocentric video only • Egocentric + two wrist cameras • Task and step labels • Country and collection metadata Egocentric-only data is easier to scale, but hands often block the object. Wrist views improve grasp visibility, although synchronization and motion blur create extra problems. We're considering releasing a small free public evaluation sample from the US, UK and Australia. It would require no signup, email or contact details. Which format would be most useful for testing an existing manipulation or imitation-learning pipeline? Also, what minimum information should be included: camera calibration, FPS, task labels, timestamps, licensing documentation or failure examples? I can share the public sample in a follow-up only if the moderators confirm that it is appropriate. submitted by /u/WideAmbition1964 [link] [Kommentare]
Hi all, I have trained a convolutional autoencoder on a set of medical images. Further classified latent feature maps using random forest to find the top scoring feature map. Now my goal is to understand which input image is captured in top scoring latent feature map. Any suggestions? I have tried encoding one image at a time while other images were muted. I then checked spearman between top scoring feature map with the original top scoring feature map. While I see some expected results, I still have some false positives. I have also tried decoding only top scoring latent feature map by setting others feature maps to 0. But I believe, the decoder entanglement is giving me many false positive results. submitted by /u/xxpostyyxx [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]
From Brett Adcock on 𝕏: https://x.com/adcock_brett/status/2066181478904705357 submitted by /u/Nunki08 [link] [Kommentare]
I want to make a post asking for help. I want to buy a 3D printer to start printing some components and figures that I might be able to sell in the future. I mainly want to print robotic parts such as housings, arms, or support pieces that I could use for robotic kits. I want to know which is the best 3D printer to start with without breaking the bank. My budget is around 350–400€. I have some good experience using the Elegoo Neptune 3 Pro and the Raise3D Pro2 Plus, which I often use to make parts and components for my projects at school. I want to get something similar to the Elegoo. I was considering these 3 options: • Bambu Lab A2L • Elegoo Neptune 4 Plus • Elegoo Centauri Carbon I want something that isn’t too big but not too small either. I also talked to some teachers, and they told me to take into consideration that at some point I may need to repair or replace some parts of the printer, which could cost more or less depending on the model. So I want to keep that in mind too. If anyone can help me, please submitted by /u/Mf_KingIsHere [link] [Kommentare]
v1 post here if you want the background. Where v2 is now The big addition in v2 is a world-frame coordinate system and live trajectory visualization in RViz2. The robot now runs two AprilTags simultaneously: tag0 is the chase target, tag1 is physically fixed to the wall and acts as the world anchor. A ROS2 node on Ubuntu (tf_bridge) connects to the Pi over WebSocket, ingests raw camera-frame poses, and computes a floor-anchored world frame on first tag1 detection. World origin is the floor point directly below the camera. From there it publishes /trajectory/car and /trajectory/tag0 as LINE_STRIP markers to RViz2, and writes per-cycle PLY point clouds for inspection in MeshLab. The URDF visualization is also live — a picar_description ROS2 package provides a tracking URDF anchored to the camera TF frame, so the robot mesh follows its world-frame position in RViz2 in real time. Manual Track mode lets me drive with WASD while tag detection and TF publishing run in the background, which is what the video shows. What the video shows Split view: dashboard on the right, RViz2 on the left. I'm driving forward with keyboard controls. You can see the trajectory building in RViz2 as the robot moves — and you can also clearly see the problem: the path is a zig-zag even when the motion is roughly straight. That's not wheel slip or steering noise. That's measurement noise from the AprilTag pose solver, visualized honestly. The jitter problem The zig-zags are real and understood. Root cause is AprilTag PnP pose ambiguity — the solver has two valid solutions for a planar tag and flips between them frame to frame. One axis swings ±15cm per frame while the robot is stationary. On top of that, a small angular error in the tag1 pose gets amplified into position noise in world frame: at ~74cm tag distance, a 5° rotation error becomes ~6.5cm of position error. Every raw frame goes straight to TF with no filtering, so one bad frame is a spike on the trajectory. What's next Two things need fixing before the trajectory is useful: Fix the world frame geometry. The current floor-anchoring logic and world frame initialization are approximate. Tag1 needs to be treated more carefully — its pose relative to the world origin needs to be stable across the session, not just initialized once and held. Add a noise filter. An EWMA filter with a velocity gate in _process_frame would reject the frame-to-frame pose flips without introducing lag on real motion. This was prototyped and tested during the v2 session but pulled out to keep the debrief clean — it's the next thing going in. Once those two are solid the trajectory should be smooth enough to actually reason about where the robot has been. Stack: Raspberry Pi 4B · PiCar-X v2.0 · Picamera2 · pupil-apriltags · FastAPI · ROS2 Humble · Python 3.13 References Post history v1 tag chaser PiCar-X introduction Hardware / code PiCar-X on Amazon Git repo submitted by /u/okineedaplan [link] [Kommentare]
We recently presented a paper at ACM CAIS 2026 on safety evaluation for tool-using LLM agents. The core issue is that task completion alone can be misleading: an agent may complete a task while violating a safety or policy constraint. We separate outcomes into safe success, unsafe success, and failure, and study how verification changes this tradeoff. We evaluate this using τ-bench / Tau-bench tool-use scenarios and propose a two-tier verification architecture: deterministic policy/tool checks first, followed by an LLM-based verifier for more contextual safety cases. The main finding is that verification can reduce unsafe success, but it can also reduce task completion as the task horizon increases. This creates what we call the Verifier Tax: a horizon-dependent safety–success tradeoff in tool-using agents. Paper: https://dl.acm.org/doi/full/10.1145/3786335.3813160 Curious how others think agent evaluations should report unsafe success. Should unsafe completion be counted as success, failure, or a separate category? submitted by /u/AccomplishedLeg1508 [link] [Kommentare]
This video demonstrates the general concept that makes a differential wrist joint work. Both motors working together achieve two degrees of freedom. submitted by /u/Icy_Hat_7473 [link] [Kommentare]