c/robotics

Fruit harvesting remains one of the most challenging robotics applications. Detecting ripe fruit is becoming easier with modern vision models, but reliable picking in unstructured environments is still difficult. Do you think the biggest challenge today is: • Vision? • Motion planning? • End-effector design? • Cost? Curious to hear different opinions. submitted by /u/ROS_RobotAlisa [link] [Kommentare]

Inventory robots are moving beyond isolated pilots and becoming part of larger systems that combine computer vision, electronic shelf labels, AI, cleaning robots, and real-time analytics. Tesco, Kroger, Harmons, BJ’s, Stop & Shop, Wakefern, Schnucks, and others are using autonomous shelf-scanning systems to track out-of-stocks, misplaced products, pricing errors, promotional compliance, and shelf conditions. Harmons says autonomous shelf scanning reduced out-of-stock conditions by more than 50% and pricing errors by 75%. submitted by /u/Responsible-Grass452 [link] [Kommentare]

From RoboHub🤖 on 𝕏 (full commercial video in Chinese): https://x.com/XRoboHub/status/2076744784572760570 submitted by /u/Nunki08 [link] [Kommentare]

Update since: https://www.reddit.com/r/ROS/comments/1ugw66z/cubic_doggo_update_returning_to_basics_after_all/ Hello hello, I made some mechanical updates to Cubic Doggo 06R, just for it to lift its feet while walking. The black padding is measured to be around 4 mm thick. I really thought this would be simpler than the IMU, but with all the changes, this is as good as it can get. The servo load (3rd on for the feet joint) easily reaches 70%, so I have a feeling this is the best it can do. I hesitate to make the body's 3D-printed frame lighter because that can make it less sturdy, and most of the weight is from the servo and batteries (yeah, also, I get a bit lazy just thinking about all those bolts and screws). Any more suggestions would be great! Changes made are m The next step is to walk with IMU, and then finally going to do some simulation and RL. Original Cubic Doggo post. submitted by /u/SphericalCowww [link] [Kommentare]

Moxie is a beautifully designed social robot, but it also became a good example of one of the biggest problems with cloud-dependent consumer robotics. When the original cloud services were shut down, much of the robot’s functionality disappeared, even though the hardware itself was still perfectly usable. The OpenMoxie community created a way to run Moxie again using a local server. However, the standard setup normally requires a computer to stay connected, so I wanted to build something more compact and self-contained. I designed the OpenMoxie Pod, a standalone enclosure containing: Raspberry Pi 5 Geekworm X1205 UPS HAT Two LiPO batteries Transparent PETG light pipes for the power and battery indicators Physical power button, ventilation and cable routing The enclosure was designed in Autodesk Fusion, 3D printed, filled, sanded and painted to match Moxie’s original colour. The goal was to create something that could sit next to the robot and behave more like a dedicated piece of hardware rather than a temporary Raspberry Pi setup. This project made me think a lot about the long-term sustainability of connected robots. When the cloud disappears, the robot should not automatically become electronic waste. I documented the complete design, printing, finishing, assembly and testing process here: Video: https://youtu.be/zTcgEC35IKY?si=6yry3L8-WT_WVcjY I’m not affiliated with the original Moxie creators or its current owners. This is an independent fan project built around the OpenMoxie community software. I’d be interested to hear what other approaches people have used to preserve or revive cloud-dependent robots. https://preview.redd.it/hnsqiahq0ddh1.png?width=2560&format=png&auto=webp&s=98b00d294d76444d40323deb3875e224ad9297e1 submitted by /u/daxx2k [link] [Kommentare]

Created Simulation From LLM Output Background: I studied EECS and I'm now getting into robotics, mostly working through the simulation side of things. While digging into the sim pipeline I came across this repo: https://github.com/AlexKaravaev/world-creator It's a CLI that generates Gazebo and Mujoco simulation worlds from a text prompt. You type something like "warehouse with shelves and some obstacles for navigation testing" and it picks models from the Gazebo model database and places them for you. I think it's genuinely a great idea and ahead of its time. It's from ~2023, so it predates all the recent LLM progress, and the author was upfront that the model hallucinated a lot back then. With today's models this approach could work way better. Curious about a few things: Has anyone here used this or something like it in real work? Is prompt-to-world something you'd actually want, or is scene setup not painful enough to matter? From what I've seen so far, people complain way more about getting the robot itself into sim (URDF, meshes, inertia values) than the environment around it. Is that right? If someone built an upgraded version of this, what would the use cases be for you? Randomized scenes for RL training? Test scenarios in CI? Quick demos? I'm exploring building in this space, so honest "nobody needs this" takes are just as useful as feature wishlists. submitted by /u/Few_Film8907 [link] [Kommentare]

I’ve been teaching myself robotics over the last few months, and I wanted to share my latest project. The main goal was simple: Build a self-balancing two-wheel rover using PVC pipe as the chassis while designing as much of the hardware myself as possible. Nearly every structural part you see was designed in CAD and 3D printed. Features Self-balancing two-wheel rover Long-range LoRa remote control Live telemetry Custom handheld controller Custom 3D printed drivetrain Custom traction system Fully 3D printed electronics mounts Dual OLED displays on the handheld Motion-controlled driving (tilt to drive) Rotary encoder and joystick controls RGB status display Custom firmware written from scratch Drivetrain Instead of buying off-the-shelf wheels, I designed a modular traction system. The drive rings, traction pads, wheel hubs, motor mounts, and internal supports were all modeled and 3D printed. The body itself is simply a section of PVC pipe. I wanted to see how capable a robot could become using inexpensive materials combined with custom printed parts. Electronics Rover Heltec ESP32 LoRa BNO08x IMU TB6612 motor driver SX1262 LoRa radio WS2812 LEDs 2S LiPo Buck converter Dual geared DC motors Handheld Controller Heltec ESP32 LoRa 1.5” RGB OLED Built-in OLED MPU6050 IMU Hall-effect joystick Rotary encoder 2S battery Software Everything is programmed in Arduino. Current features include: PID balancing Heading hold LoRa communication Telemetry Battery monitoring RSSI display OLED UI Motion control Adjustable tuning What’s Next? Now that V1 works, I’m debating where to go next. Option 1: Build a rotating pan/tilt turret with an ESP32 camera, laser, and object tracking. Option 2: Start over on a V2 chassis using independent cantilever suspension, larger wheels, and a more capable drivetrain. Which direction would you go? submitted by /u/xxc87xx [link] [Kommentare]

I've been looking into modern robot learning datasets, and it seems like a lot of information can now be estimated from RGB video using existing models, such as: 3D hand pose Camera trajectory Depth Segmentation Point clouds Natural language task annotations That made me wonder where the limits are. What signals still cannot be recovered reliably from video and therefore need dedicated sensors during data collection? For example: Tactile/contact sensing? Force/torque? Eye gaze? EMG? Something else? I'm interested in understanding what data collection bottlenecks still exist for manipulation and embodied AI. submitted by /u/Tricky-Promotion6784 [link] [Kommentare]

Teaching my 13-year-old grandson programming using Arduino, Python, and AI. We are currently programming this small robotic arm. I originally built the arm for him 5 years ago for Christmas. Back then he just played with it, but now he is writing new code for it. The goal is to detect candies placed in front of it and drop them into a cup. How it works: A Raspberry Pi-based USB camera monitors the workspace. A Python script running on a PC detects the candies and sends G-code commands to control the arm. Hardware & Firmware: The robotic arm is powered by an STM32F103 microcontroller running Arduino-based firmware. submitted by /u/Available-String-891 [link] [Kommentare]

I'm trying to understand where the biggest supply gaps still exist in real-world data for robotics and embodied AI. I'm not referring to synthetic or simulation data, only data collected from the physical world. Some examples I'm thinking about: Dexterous manipulation Tactile/contact sensing Bimanual tasks Warehouse/logistics Industrial assembly Mobile manipulation Long-horizon household tasks Human demonstrations vs. robot-generated data For those working in robotics or VLA/world model research: What types of real-world data do you wish existed in much larger quantities? Are there specific verticals (manufacturing, healthcare, retail, agriculture, etc.) where data is especially scarce? Are there modalities (RGB, depth, tactile, force, audio, IMU, eye gaze, etc.) that are consistently missing? If someone were starting a company focused on collecting real-world robotics data, where would you say the biggest unmet need is today? I'd love to hear perspectives from anyone training robot foundation models, collecting datasets, or deploying robots in production. submitted by /u/Tricky-Promotion6784 [link] [Kommentare]

I built a testbed comparing two ways of governing a hospital delivery robot: a conventional task pipeline and one governed by a constitutional layer I call NA. The constitution works through directional asymmetry: claims about the world can only be demoted, never promoted, without evidence, and memory is append-only so the robot can not quietly rewrite what it believed earlier. Across 13 scenarios (blocked corridors, conflicting instructions, a patient in the path), the conventional pipeline completed safely 15.4% of the time. The NA-governed pipeline completed safely 100% of the time, and the failures it avoided were the interesting kind, where the robot’s confidence outran its evidence. The whole thing runs deterministically in Python so anyone can replay every decision, and I’m now putting it on a physical robot built on a Raspberry Pi 4. I have never done this before, am I reinventing the wheel here? Happy to share the code and answer questions about the architecture. submitted by /u/willybbrown [link] [Kommentare]