@Simon

try it right now without installing anything. the fiftyone app is running in a hugging face space for the first time (its a bit hacky atm, but working on polishing it up) space: https://huggingface.co/spaces/harpreetsahota/fiftyone-app full walkthrough: https://voxel51.com/blog/view-mcap-files-fiftyone submitted by /u/datascienceharp [link] [Kommentare]

Hey everyone, We've been building Miu — an embodied AI agent on a Yahboom Raspbot-style platform (Raspberry Pi, mecanum wheels, RPLidar C1, PTZ camera, ultrasonic bumpers). After a lot of wiring and debugging, V2 is working enough that he can autonomously drive around inside a room without us manually joysticking every move. What's working: • LiDAR-based room scanning + obstacle avoidance • Holonomic mecanum control (strafe, not just diff-drive spin-in-place) • Ultrasonic as a "digital bumper" for stuff LiDAR misses (cables, furniture edges) • Live 3D viewer (Rerun) so we can actually see what the robot thinks • Backend orchestration: LLM plans missions, a separate executor drives the motors Nav2 / ROS 2 helped a lot as a reference stack and for A/B testing navigation — though our production path on the Pi is leaner (FastAPI + custom holonomic controller). Nav2 taught us the patterns; shipping meant ripping out a lot of complexity. What almost killed the project (real talk): Too many cooks on cmd_vel — vision pipeline, proximity reflex, room scan thread, teleop, and agent tools all wanted to move the robot at once. Classic race conditions. LiDAR serial lock — Nav2 container + our own LiDAR reader + live viewer polling the same serial port = chaos. Had to enforce one LiDAR reader and stop competing services. Control-loop bug — we were doing LiDAR HTTP calls inside the 10 Hz drive loop. Robot spun in circles after ~2 ticks. Decoupled sensor thread (LidarScanBuffer) from control thread — fixed immediately. Observability nightmare — logs split across Pi journal, movement_log, PM2 JSON (multi-GB…), Discord, activity stream. Couldn't answer "why did it turn left?" until we built a unified observability endpoint. Battery — still an issue. Continuous LiDAR + movement + inference drains faster than we'd like. Low-battery caps on movement duration for now. V2 architecture (what we changed): • One motion supervisor — single authority on motors • Mission FSM — vacuum / explore / find_person / teleop, one active job at a time • Planner vs executor split — the LLM picks what to do; it doesn't fire raw motor pulses every turn Next steps: • IMU + wheel odometry fusion (EKF) → AMCL for proper pose • Persistent room memory (episodes, obstacle map, cascade/EOD summaries) • Click-to-nav in the live viewer • Battery / power management tuning Happy to answer questions about the stack, Nav2 vs custom control, or mecanum on a Pi. Still very much work in progress — would love tips from anyone who's shipped a home robot without it becoming a full-time ROS babysitting job. Stack (rough): Pi 4/5 · Yahboom chassis · RPLidar C1 · FastAPI on Pi · Mac mini backend (Postgres, agent loop) · ROS2 Nav2 (research/A-B) · Python holonomic controller · Rerun for viz submitted by /u/Spinning-Complex [link] [Kommentare]

Dr. Ayanna Howard, dean of The Ohio State University College of Engineering, former NASA roboticist and founder of Zyrobotics, explains why both universities and startups are necessary to advance robotics. Universities support foundational research that may not produce a commercial return for many years. Startups take that research and try to connect it to an immediate market need, moving quickly and changing direction when the technology or business model does not work. Howard also discusses the difficulty of building startups within universities because academic incentives are centered on research, publications and grants rather than developing products for customers. She sees the strongest model as faculty providing technical guidance while students lead the work of turning research into a viable company. Full convo: https://www.youtube.com/watch?v=lis9e9L4ScU submitted by /u/Responsible-Grass452 [link] [Kommentare]

I posted about an earlier version of this project here a few years ago. I always wanted to continue it, but life happened: house, kids, work, and suddenly project time disappeared. The old version worked, but it was five-year-old code, so I did what most people think about doing when they look at old code - I started from scratch. The project is called Vanchor. It is a different kind of robot than what is usually posted here, but still a robot :) Vanchor is an open-source GPS anchor/autopilot system for smaller boats using cheap electric trolling motors. The target is small fishing boats, kayaks, and other small boats with trolling motors (focused on bow mounted currently). The idea is to turn a cheap trolling motor into a simple autonomous boat-control system. Main functions: Hold position, similar to spot-lock Hold heading Follow waypoints Follow a shoreline Follow a depth contour Move between fishing spots Work around an island or structure Drift or orbit around an area Follow APB data from a plotter Test behaviour in simulation before using real hardware It is not meant to replace OpenCPN, chartplotters, or proper marine navigation. It is more focused than that: small-boat control for fishing and DIY automation. The new version has among a lot other features: Python-based controller Local web UI for phone/tablet use Simulator based on Fossen’s 3-DOF marine craft model GPS/IMU hardware support Driver system for custom hardware Location and heading from phone sensors through the PWA app, where supported Depth contours Catch logging GPX waypoint import Several fishing-focused control modes Early PCB designs Early 3D-printable servo/control models One thing I wanted to fix from the old version was the wiring. The boat setup quickly turned into a crow’s nest of wires, and debugging loose connections in a boat is not fun. Especially when you just want to catch some perch. So this version also has early PCB designs for a cleaner setup, plus 3D-printable servo/control models. The simulator is one of the more useful parts right now. It makes it possible to test control behaviour without having the boat, water, GPS, IMU, and motor driver available at the same time. The project is still early, but it is now at the point where outside feedback would be useful. Any feedback is appreciated. Especially feedback on the PCB. It looks fine when I inspect it, but it has been years since I designed my own, much simpler, PCB. And yes, even the 3D models and PCB designs were created with Fable. Without it, I would never have found the time to pull this together. So far, I am quite impressed by it. https://preview.redd.it/5u1eld6qlwbh1.png?width=3708&format=png&auto=webp&s=daa0ec1e2f3685177b538af5c972931e268b6c0a Repos: Main project: https://github.com/AlexAsplund/vanchor PCB designs: https://github.com/AlexAsplund/vanchor-pcb CAD models: https://github.com/AlexAsplund/vanchor-cad submitted by /u/aasplunds [link] [Kommentare]

The clip shows a dual-arm rig autonomously arranging flowers into a glass vase at 1x speed, fully autonomous, with three simultaneous camera angles in the corners so the full workspace is visible. Robbyant has released LingBot-VLA 2.0, a VLA model trained on roughly 60,000 hours split as 50,000 hours of real-robot data across 20 embodiments plus 10,000 hours of egocentric human video. The action space covers whole-body control to include head, waist, mobile base, and dexterous hands up to Unitree G1 and Fourier GR-2. On the authors' own GM-100 eval, where pi-0.5 and GR00T figures are also self-reported, Agilex Cobot Magic reaches 34.4% success and Galaxea R1 Pro 15.6%, with several tasks at 0%. The paper notes the model often makes partial progress then fumbles final precise placement or release, and OOD performance degrades sharply. Relative joint actions increased average success from 33.7% to 55.0% in ablations. submitted by /u/Feeling_Till_7418 [link] [Kommentare]

Tried creating same pick and place simulation with a few different models. The recurring pain point was resolving XML issues after the initial generation. Gave Drift a try for the same task. I spent more time iterating on the scene itself instead of chasing configuration errors. If anyone is looking for the exact prompt I used: Create a MuJoCo scene using a Franka Panda arm, place it on a table and a cube in front of it with a target pad. submitted by /u/AxBodiSpray [link] [Kommentare]

Researchers created a breakthrough technology that allows robots to feel and recreate touch just like humans. Using muscle-like air chambers, machines can now instantly mimic sensations ranging from soft tissues to rock-hard surfaces with 89% accuracy, revolutionizing robotic surgery and teleoperation. Credits: https://www.nature.com/articles/s44182-026-00102-2 submitted by /u/Similar_Suit_3709 [link] [Kommentare]

I do not exactly have a photo as of now, and I was still kind of anxious to post this but I had built this CLI tool that creates a ROS workspace but only with a single .toml file(yes like Pixi, y'all need to stop ffs!) which contains ur entire launch pipelines, nodes, setup etc to essentially eliminate the need of Cmakelists, launch.py, etc. and a hot reloader to eliminate colcon build etc., reach build if you wanna build it into a ros2 package, reach doctor and trace for diagnostics, debugging, etc. I finally tested it today to see if it can even move my OpenArm robot properly or not and it did. For a minute or two I felt really happy that it's finally working but yeh now I'm moving forward to cross compilation management and reducing the setup overhead for the robots. Here's the link incase anyone wants to check it out: https://github.com/ascii-robotics/ros-config-reduction P.S: built it in rust submitted by /u/Aromatic-Dig9997 [link] [Kommentare]

So basically I'm using: Feetech SCS-15 Serial Servo motors Feetech FE-URT-2 USB to TTL Controller Voltage Regulator Module (5V output) Raspberry Pi 3.7v 18650 Batteries to control the servo motors in the daisy chain ish way. For some reason I need to power servos using batteries individually, and I am not sure how I could do the wirings. Like, are they even different from one another and which way is the most adequate? In my poor understandings the ground seems all connected regardless of which way of these 3. submitted by /u/Dangerous_Break5656 [link] [Kommentare]