c/robotics

I have some 35-48v 500w bldc motors (e-skateboard motors) that I want to use for my robotics projects. They are much higher power than the small gimbal motors I typically use with Simple FOC drivers, so I'm wondering what's the typical setup for these high power motors. Power supply: better to use a big lipo battery or a wall power supply? From what I've seen, batteries can provide more current but are kind of dangerous? Controller: I want to use an FOC drive to precisely control position. the motor has an encoder built-in. I was looking into the ST G431 driver, but I'm not sure if it can handle so much power. I'm quite new in BLDC control and high power electronics, any advice or info would be really helpful! submitted by /u/the_relentless_epee [link] [Kommentare]

Has anyone encountered the Stretch robot from Boston Dynamics in any warehouses? If so - how smoothly does it actually run in terms of package handling and errors? I’ve seen plenty of demos online, yet all the boxes are presented in a way that just isn’t realistic? (They’re perfectly stacked and flat) Just curious as I’ve been looking for an answer but nothing online. Is the technology as reliable as they’re stating? submitted by /u/roboticist-666 [link] [Kommentare]

Follow-up to my v2 trajectory post. The RViz trajectory had visible zig-zag jitter even when the robot was stationary. Before deciding what filter to apply, I wanted to actually measure the noise and understand what's driving it. The problem The v2 system uses a physically fixed AprilTag (tag1) as a world frame anchor. The Pi detects it each frame, inverts the camera→tag transform to get world→camera, and publishes that as a TF. The zig-zags in the trajectory come from frame-to-frame instability in that pose estimate. The root cause is AprilTag PnP pose ambiguity — the solver has two valid geometric solutions for a planar tag and flips between them. The flip shows up as a large swing on one axis, typically ±15cm, even with the camera stationary. On top of that, small angular errors get amplified into position noise through the matrix inversion: at ~74cm tag distance, a 5° rotation error becomes ~6.5cm of position noise in world frame. The question I wanted to answer before touching the filter: how much does tag size actually move the needle? Method Added a single_tag_world_mode flag to config so ManualTracker can run with just the world anchor tag in frame — no chase target needed. Camera held stationary, pointed directly at the tag, for ~2–3 minutes per condition. Raw camera-frame poses recorded automatically to JSON. Four conditions: 5cm and 20cm printed tags, each with room lights on and off. All four plots below share identical axis scales so the distributions are directly comparable. Results Condition σ X σ Y σ Z (depth) 5cm — lights off 3.4 cm 0.5 cm 4.5 cm 5cm — lights on 5.1 cm 1.7 cm 3.7 cm 20cm — lights on 2.7 cm 0.4 cm 1.4 cm 20cm — lights off 2.1 cm 1.0 cm 1.7 cm (Images: 5cm lights off → 5cm lights on → 20cm lights on → 20cm lights off) What the plots show Tag size dominates. Going from 5cm to 20cm cuts depth noise by roughly 3x. The distributions tighten and become more unimodal — the PnP flip signature (broad or bimodal histogram on X and Z) is clearly visible in the 5cm sessions and largely absent in the 20cm sessions. Lighting is secondary. For the 5cm tag, lights-on is actually worse on X (σ 5.1 vs 3.4cm), likely because uncontrolled ambient light causes glare that degrades corner localization on a small tag. For the 20cm tag the lighting effect is small enough that it's not the thing to optimize. Best condition across all three axes simultaneously: 20cm + lights on (σX=2.7cm, σY=0.4cm, σZ=1.4cm). What's next This experiment was groundwork, not a fix. The noise is reduced but still present — 2cm+ std dev on X and Z with a stationary camera is not acceptable for a usable world frame. The next step is a filter, but the right choice (EWMA, velocity gate, Kalman, or some combination) depends on understanding the noise characteristics, which is what this data was for. Still deciding. Open to suggestions from anyone who's dealt with PnP jitter on planar markers before. References Post history v2 trajectory post v1 tag chaser PiCar-X introduction Hardware / code PiCar-X on Amazon Git repo submitted by /u/okineedaplan [link] [Kommentare]

not sure if this is the right flair 😕 I had put this post up on r/gradadmissions but i feel like I'd get a better demographic that knows the field better here submitted by /u/Proud_Imagination_94 [link] [Kommentare]

I'm reading the papers of Cosmos3 and Dreamzero and they looks very promising (compared to memoryless VLAs). And I am wondering where the filed will evolve. Based on your practical experience with new models, what's your bet between VLAs, WM, Jepa-style, WAM, RL approaches, and all of that? I worked so far with VLAs (eg pi05), and I don't have any experience in using the nvidia stack so far, of and other world action models. I am thinking if I should invest time in changing the base policy, and I'd appreciate some feedback form who has tested them (ie: the open source/weights model available, and capable of inference without one thousand gb of vram) On my side I'm a fan of model working planning latent space; video action models (which have more temporal coherence wrt vla), but I also feel that semantic power of a VLM should be present aswell. Ps: suggested survey reading in this topic: "World Model for Robot Learning: A Comprehensive Survey" Happy to discuss with you submitted by /u/Amazing-Coat5160 [link] [Kommentare]

Hey i was working on a 6dof robot arm and completely new to this And just found out about inverse kinematics I'm having trouble trying to find the right material to learn it where can I find good material submitted by /u/OkCash6221 [link] [Kommentare]

I recently visited a robotics space that’s focused specifically on humanoid robots. Not industrial arms, warehouse AGVs, or general automation, but bipedal / human-form platforms. It’s part of an incubator-style setup for early-stage teams working in this niche. What surprised me most wasn’t actually the full robots. The complete humanoid demos were interesting, of course, but the component side stood out more: actuators, dexterous hands, sensing systems, and all the less visible hardware that makes these machines possible. It made me think that the real progress may be happening below the “cool demo video” layer. Another thing I noticed was the visitor mix. Over just a couple of weeks, there seemed to be people coming through from different parts of the world: corporate visitors, researchers, MBA / exec ed groups, and others trying to understand where the field really is. The common question seemed to be: are humanoids actually close to being useful in real-world environments, or is this still mostly future-facing R&D? The incubator model itself also felt notable. Instead of every startup trying to build everything alone, the space seems designed to put founders, suppliers, researchers, and component companies near each other. That kind of clustering has worked in other deep-tech sectors, so I’m curious whether humanoids need the same thing to move faster. A few questions I’m still thinking about: Are humanoid robots finally approaching real product-market fit, or are we still in the “ten years away” phase? Which use cases are most likely to come first: logistics, manufacturing, elder care, inspection, retail, or something else? Is the recent momentum mostly driven by hype and funding, or are there specific technical bottlenecks that have genuinely improved? Are components like actuators and robotic hands the real near-term market before full humanoids become practical? I’m interested in how people here read the current moment. For those working in robotics, automation, or related hardware: does this feel meaningfully different from previous humanoid waves? submitted by /u/Great_Arachnid5776 [link] [Kommentare]

I've been considering a long-term quadruped project and have been poking around the builds that are out there. There's a ton of cool stuff, but so far I haven't seen anything open-source seems to match the dynamic motion capabilities of the mini-cheetah. "Dynamic motion capabilities" is pretty hard to pin down without benchmarks, but subjectively I mean the speed, rough-terrain capabilities, and performance jumping/falling. (Even more subjectively I mean the backflip). Given the seven year gap that really surprised me. My question for the community is two-fold: Is there an open-source quadruped build that does match the mini-cheetah that I just missed? If not, why? submitted by /u/lellasone [link] [Kommentare]

Weekend project, one weekend in — lots still half-built: a 6-DoF SO-101 arm (Feetech STS3215 / LeRobot) with a wrist camera, driven by an agent that plans camera moves, films them, and stitches the edit. Sharing v1 — rough, but the loop works. The demo is a side-by-side: left is an external phone shot (manual), right is the arm's own wrist camera. The choreography — wake → framed "hero" pose → dolly/roll/tilt beats → rest — runs through a safety layer (soft joint limits + velocity cap + stop sentinel). A few things I hit that others might find useful: 🔧 Dead elbow servo, diagnosed by feel. Stiff to backdrive, idle temp 53°C vs ~38°C on the others = shorted/lossy winding. Swapped it, re-set the ID, recalibrated the joint. 📐 The jerky motion wasn't the servo or the mount. Braced the table and it still jerked — turns out it's STS3215 gear backlash (~0.87° measured by others) plus low-speed stick-slip. Confirmed stick-slip is speed-dependent: ~51 backward micro-ticks at 12°/s vs ~0 at 50°/s. ✅ The fix: dropped P_Coefficient 32 → 16 (LeRobot's own recommended value). Slow-speed judder went from ~43 stutter events/sweep to ~0 in a controlled A/B. Plus: keep recorded moves single-direction and faster. 🎯 No IK yet, so "orbits" drift. Leaned on framing-safe moves — roll about the optical axis, dolly, tilt — to keep the subject centered. The goal is reusability: clone the repo, build/attach the SO-101, and you can direct Claude to film your own demos. Still manual for now (external camera + initial framing/hero pose). Next up: better camera, longer scripts, closed-loop framing. As always, it's all open source — control lib, safety layer, calibration, and the motion/stitch scripts. I will organise it better once the project is complete 👉 https://github.com/kamalkantsingh10/dummie Happy to go deeper on the motion-streaming / backlash tuning if useful. submitted by /u/KamalSingh10 [link] [Kommentare]

Would a ASL-ML from BO3 work in real life as a Autonomous Quadruped Robot. I kinda think it could only problem would be power/batteries. If it would work what could it be used for? I mainly think security, patrolling important assets etc. submitted by /u/LowAcanthocephala528 [link] [Kommentare]

Would a ASL-ML from BO3 work in real life as a Autonomous Quadruped Robot. I kinda think it could only problem would be power/batteries. If it would work what could it be used for? I mainly think security, patrolling important assets etc. submitted by /u/LowAcanthocephala528 [link] [Kommentare]

This draw io diagram summarizes the perception pipeline I'm building for robotic object localization: - Capture real RGB-D data with an eye-in-hand camera setup. - Bootstrap a small labeled dataset - Fine-tune a YOLO-Seg model - Generate assisted labels for additional real captures - Compose synthetic RGB-D views using masks, depth, camera intrinsics and in-painted backgrounds. - Retrain the segmentation model with the expanded dataset - Input 2D masks, classes and confidences into 3D using depth and camera intrinsics - Extract 3D object localization outputs usable for robotic tasks -- Feedback is welcome! submitted by /u/nettrotten [link] [Kommentare]