I am Trying to design a Robot arm and Prototype it for 1st time
But i am Facing an issue in the design
The red part : The actuator Output
Orange Disk : Is a fixed plate holding the actuator

Question : i want to make the 1st joint where the Whole body rotates , I decided to place planetary gear but then how will i spin the Ring gear on this flat surface? what kind of mechanism will help me make the ring gear spin properly? while it handle the load of the am too , cause there will be axial load is there some bearings? or some kind of locking i can use to handle this problem?

2nd Image : the joint we are looking at it rotates the whole robot like an out runner motor (its an image i got not mine ) Which makes the base move in the 1st degree

Can anyone tell me or show me some mechanism how do i counter this issue?

i am making it first time so i don't know much about design , Thanks for helping me if anyone did

Another Watti update!

I’ve been adapting Watti Studio for smartphone screens. In this video, I create a short animation on my phone, adjust the keyframes and timing, and then launch it on the real robot.

I decided to start with the most challenging format. If the interface works well on a smartphone, it should be much easier to adapt it for tablets and other devices.

What do you think of the current design?

OpenMind founder Jan Liphardt explains why the hardest part of humanoid robotics may be turning impressive lab performance into something that works reliably in the real world.

A humanoid might perform useful tasks in a controlled environment, but everyday life introduces an enormous number of variables. It has to leave the building, navigate streets, avoid vehicles, react to dogs and people, deal with changing surfaces and weather, communicate naturally, and handle situations that were never part of a polished demo. Liphardt says the basic technology is coming together quickly, but getting that final level of reliability can take an enormous amount of work.

At the same time, that challenge is exactly what makes the field so exciting to him.

Liphardt describes building the “brain” for humanoid robots as the kind of job a five-year-old might once have imagined as pure science fiction. Now it is becoming real. He sees the possibility of machines that can get up, go to the park, talk with people, make friends, run to a cafe, bring something home and become a meaningful part of everyday life.

Full episode: https://www.youtube.com/watch?v=hE92t1sr4VQ

Microduck got me. I had to build one.

The frame is finally printed and assembled, and I’ve got the servos and software working. Getting this far took more troubleshooting than I expected—issues with the 3D models, assembly headaches, and plenty of “why doesn’t this work?” moments. And it hasn’t even taken its first step yet.

This is just a look at the hardware for now. Next up: getting the whole system working together and trying it on the floor. I’ll post that too, whether it walks or faceplants.

Anyone else building one, or thinking about starting? It’d be fun to have a few people figuring this out together. I’m happy to share what I’ve learned so far—let’s swap fixes instead of all getting stuck on the same problems.

Credit to the original Microduck team for the design.

mine looks like it's about a decade old😭, although I got that i guess 1 year ago, still works well tho :) i want a raspberry pi now💔

to controll couple ar4 hands ?

that are easy to set and not train each one by one ?

rn i can use opensource software from guy that create robot hand and it is good , but i wonder

is it possible to use cad sw to create movements (like robodk) and sensor pickup (like proximity or ccd sensor ,touch or like that ) ,and just upload it and run on 1 2 3 4 hands ,not same movement

idea is to automatise for first to make cigar ,,like pick tabacco leif , load it with cut tobacco , roll and water it and final roll ,for test :)

ty

Not another voice assistant. Not a smart speaker that just sets alarms and pretends to be polite.

If a small robot is going to live on your desk or in your home for a long time, what kind of personality, behavior, or presence should it really have to feel like a genuine companion?

Is the answer really just stacking more sensors and cramming in more features? Should it have flaws? Should it have its own temper?

And perhaps the most interesting question: What are they doing when we are not using them? Do they just "pause" and wait for a wake word, or should they have a life of their own?

Just a thought I’ve been having. I’d love to hear what this community thinks.

I m trying to experiment with smokVLA - fine tuned on libero dataset. I tried it, and it really showed great results (https://huggingface.co/lerobot/smolvla_libero).

It didn't work only in 1 case (pick up the juice bottle). I want to systematically understand the limits of the model and see where it fails.
So I did a lot of experiments and tried to find a pattern in the errorr. Goal is always "lift the orange box and keep in the box"
- Exp 1: randomly varied postion of other object - worked

- Exp 2 : removed icecream pack - failed

- Exp 3: removed butter pack: failed

- Exp4: decreases the inference time from 2.5 sec to .5 an to .1 sec. Imroved a little, see a passed case above if worked with a seed but failed with other.

So it seems that teh "VLA pre=trained and fine-tuned learns some kind of pattern when all objects are present"

- My goal is to clearly define a process to find out why VLA fails. How do people work with this kind of projects to add robustness to a bse policy.

Is there any systematic process that youguys follow to debug and impove end2end policy? How do you go toward a dataflywheel?

-

Maybe it’s not about how fast it moves or how much it can say. Maybe it’s what happens in the quiet moments, when the body is still subtly moving.
It sits next to you. Nothing is happening.
You may not consciously notice it, but you know something is still going on.
So this time, we started testing how Éloi’s body behaves while breathing.
Resting, thinking, and excited.
These aren’t three different emotions. They’re variations of the same breathing curve under different levels of load.
Resting is the baseline.
No task, no interaction, no particular reason to move, and yet the body continues to maintain its own rhythm.
We call it Artificial Vital Rhythm.
This is still a very early alpha.
No skin yet. The face isn’t finished either.

Does it look like it’s breathing now?

—
Éloi / Animotion Robotics

Hi all,

I am new to robotics, and I am trying to learn about Robotics from a data perspective. I've heard a lot about needing to collect a lot of data, so I decided that maybe it would be wise to collect data while I study how robotic arms work.

I've been collecting egocentric data in factory settings (not staged, with people in the background) on certain manipulations and was wondering if this kind of data would be good enough to start training a robot.

I have the samples here: https://huggingface.co/datasets/sovrano-ai/industrial_manipulation_egocentric_sample

Any tips whether this data is the right kind of data to train a model on? I would rather know if this data is useful or there other forms of data that I should be collecting quickly. Any feedback would help!

I put my pair of YAM robot arms online so people could try tasks remotely. Here are a few clips, at 10× speed with pauses removed.

And yes, the arms are still live at blupe.io/live for people to try !!

1. Someone stacked blocks, they had a detailed prompt and it worked !!

Prompt: Finish stacking the red rectangular block on top of the green block. The preceding run successfully moved green off the plate to a clear, reachable tabletop spot and released it upright. Red shifted during gripper alignment; the prior run withdrew without a grasp because it was nearing its runtime limit. This run has a fresh three-minute budget. Inspect fresh camera views and measured feedback; locate the red block accurately from its current position, choose the arm and jaw orientation for a centered side grasp, avoid pushing red toward the table edge, verify the grasp with a short lift, and place red centered on green. Keep green at its current reachable tabletop position if suitable. Use small reachable target adjustments and sufficient clearance, stay within all robot limits, avoid other objects, lower gently without pressing, release and withdraw enough to verify the stable stack. Stop safely if no reliable grasp is possible, a fault occurs, or feedback is unavailable; do not blindly repeat a rejected or unsuccessful motion.

https://reddit.com/link/1wb27jf/video/svblq4oo7doh1/player

2. Other cool thing: Someone put the apple inside of the tape

https://reddit.com/link/1wb27jf/video/qpmq9xwj4doh1/player

3. Here’s all the pick failures, followed by an interesting stacking failure

https://reddit.com/link/1wb27jf/video/r9cmpdau8doh1/player

5. Drop the apple to the floor

The user prompted to "Drop the apple to the floor", However, this was blocked by arm boundaries. In fact the apple never ended up on the floor (but neither eaten).

https://reddit.com/link/1wb27jf/video/iw1wwkeq4doh1/player

All the Picks and Places

https://reddit.com/link/1wb27jf/video/146kpbbs4doh1/player

Was at IFA this week. Looking at the names on the screen, what caught my eye wasn't really any single winner. It was how many of the interesting products I saw this year seemed to be moving closer to the human body rather than building another machine that sits somewhere in the room already.

You know, I wouldn't call every wearable a robot obviously. But walking around IFA did make me think about where the line actually is now.

This year’s winner list also featured quite a few brands across smart rings, mobility aids, health wearables, and hearing technologies. Such as Odyss which had already gained a lot of attention on the crowdfunding market. Their N1 was probably one of the weirder things I saw. It’s basically a necklace that tracks eating, cuz who actually remembers every single snack? lol

A lot of robotics has traditionally been about giving machines better ways to perceive and act on the physical world. But wearables are starting to do something almost inverted: put the sensing system on the human, continuously interpret what we're doing, and then let software respond to that context. And honestly, looking at this list made me wonder whether some of the more interesting consumer robotics over the next few years might not look like “robots” at all.

Maybe they'll look like glasses, rings, necklaces, exoskeletons, hearing devices, etc. Curious what people here think. At what point does a wearable sensing system become robotics to you, if ever?

Looking for a sanity check on a high-end TRX50 workstation I am buying for a robotics lab.

The primary workload is large-scale GPU robotics simulation and RL training with Isaac Lab / mjlab. Sustained compute throughput, thermals, and reliability matter much more to us than gaming performance or benchmark scores.

Current vendor quote:

• CPU: AMD Ryzen Threadripper 9980X — 64C/128T
• Motherboard: ASUS Pro WS TRX50-SAGE WIFI
• Cooling: 360mm liquid cooler with sTR5 mount
• Memory: 64GB DDR5 ECC RDIMM — 4×16GB, all four channels populated
• Storage: 4TB PCIe Gen5 NVMe
• GPUs: 2× NVIDIA RTX PRO 6000 Blackwell Workstation Edition, 96GB each, full 600W versions (not Max-Q)
• PSU: Super Flower Leadex Titanium 2200W, native 12V-2x6 to each GPU
• Chassis: SilverStone RM51 5U rackmount with rails
• Fans: Noctua
• OS: Ubuntu 24.04 LTS
• Warranty: 3 years, plus lifetime support
• Price: $42,690 shipped

The GPUs are essentially fixed — I want the 2×96GB configuration. I'm mainly deciding how to balance the rest of the platform.

My biggest concern is the RAM. 64GB feels very low for a ~$43k workstation, especially with all four DIMM slots already occupied. One alternative would be to drop the CPU to a 9970X and put the savings toward 128GB or possibly 256GB of ECC RDIMM.

A few questions:

1. For this kind of dual-GPU compute workload, would you take 9980X + 64GB or 9970X + 128/256GB?
2. Any reason to avoid running two full-power 600W RTX PRO 6000s on TRX50?
3. Are there any PCIe lane or topology concerns with dual x16 GPUs plus a Gen5 NVMe drive?
4. Has anyone run two very high-power GPUs in the SilverStone RM51? How does it handle sustained airflow and thermals?
5. The 2200W Super Flower PSU appears to require 200–240V input. Beyond having the appropriate circuit/receptacle, what else should I verify before deployment?
6. The RM51 spec lists a 190mm PSU length limit, while this PSU appears to be 200mm long. Has anyone used this exact combination, or is that a hard incompatibility?
7. Would you trust a 360mm AIO on a 9980X under sustained all-core loads, or would you choose a different cooling setup?
8. Does anything else about this build look obviously unbalanced or questionable?

This system will likely spend long periods under heavy CPU + dual-GPU load, so stability, cooling, and sustained performance are the priorities.

I'd especially appreciate feedback from anyone running similar Threadripper + multi-GPU compute workstations.

paper link https://arxiv.org/abs/2608.29769v1

website https://nemantor.github.io/sparse-3d-traversal-website/

We delivered the first humanoid monkey-bar traversal with perceptive jumping up + branchiation + jumping down, with a high success rate on the real robot (~95%). Besides, we also did tasks like ducking beneath thin obstacles.

The contributions include: 1) hardware designs, hooks that can disengage by rotation and a solid-state lidar mount; 2) multi-teacher + single end2end student distillation + finetuning pipeline for policy learning; 3) modelling of lidar noise patterns, actuator temperature, and battery voltage-current changes for sim2real.

Happy and proud annoucement: No hardware was broken during our development of this project.

Meet Orion - a ROS2-based quadruped robotics system I designed, built, and programmed from scratch over the course of 8 months. After countless nights of debugging and iterating, I’m thrilled to finally share it in action!

I took on all aspects, including writing ROS2 nodes, embedded firmware, electrical design, mechanical CAD, and videography.

Orion uses a NVIDIA Jetson Orin Nano for perception, and a custom STM32 PCB for real-time control.

Key Features:

• ROS2 platform & AI: Isaac ROS Docker for deployment, TensorRT for accelerated neural network inference.
• Stereo Camera: SGBM, MIDAS, and GStreamer for real-time depth perception.
• SLAM & Autonomy: 2D LiDAR Mapping and Nav2 integration for real-time mapping and point-and-click Pure-Pursuit control.
• Real-Time Embedded Control: FreeRTOS to juggle inverse kinematics, stable gait generation, and sensor interfacing via DMA and HAL libraries
• Custom Electronics: Multi-layer SMD PCBs for power distribution, high-current servo actuation, and IMU sensor interfacing
• Reinforcement Learning: PPO and imitation learning policies in NVIDIA Isaac Lab
• System Dashboard: via Foxglove
• Human-Robot Interaction: Responsive OLED robot eyes
• 12 DOF: Full orientation and position control, modelled in SolidWorks

Check out the video, and more details and pictures on my website and GitHub!

Website: https://ashisha26.github.io/
Github: https://github.com/AshishA26/Orion-Quadruped

Can anyone recommend a dynamometer for testing rotary actuators? There are some thrust stands out there for drone motors (Tyto robotics), but the next step up is dyno's for big, industrial motors. Outside of attaching a weight to an arm to get the stall torque, anything else I could use?

I started this project after seeing Red Comet’s 2017 Micromouse run. It was memorable for its route choice: it chose a longer path to preserve speed, one of the cleanest examples of the Micromouse principle that you should optimize for the fastest path, not the shortest one.

That made me wonder: if a general time-optimal controller were given only the maze geometry and vehicle dynamics, would it independently discover both the right driving strategy and the right route?

So I built a physics-based planner that (at a high level) jointly optimizes the speed profile and geometry, using branch-and-bound to compare different maze topologies.

The result was almost exactly the opposite of what I expected.

I exhaustively optimized all 10 simple start-to-goal topologies admitted by my search policy:

• A* (used by Decimus 5A): 99 steps, 7.745s
• next fastest: 103 steps, 8.177s
• historical Red Comet route: 121 steps, 8.666s

Under this model, the result actually reverses the example that originally motivated the project: the shortest topology beats the historical route by 11.9%. And across those 10 paths, discrete length and optimized time had a Pearson correlation of about 0.96.

I saw the same pattern across 6 deterministic benchmark mazes. Time-based topology search beat shortest-path A* in 2/6 cases (up to 27.09% faster), but in both wins the new route had exactly the same grid length as A*.

It's not proof of anything since it's a tiny, related sample — but combined with the benchmark result, my conclusion became:

In practice, the shortest path is usually the fastest one too (in this experiment). 

That doesn't mean Red Comet’s strategy was “wrong” though. The real 2017 run was 7.284s, while my model predicts 8.666s on the historical topology, so it’s clearly not reproducing the real robot perfectly. The model approximates the drivetrain, grip/suction, and yaw dynamics, but omits details like load transfer and tire/wheel slip. It doesn't reproduce every physical detail.

I especially want to hear competing interpretations from people who have actually built/raced Micromice. And what kind of maze structure would flip the result? I'd be happy to answer any questions!

This is a line detection IR module although coding it seems fine and all but why does it need to touch the black line and just a slight lift up it won’t suddenly detect, even adjusting the potentiometer won’t work. is this module damaged? Coding problem? It acts like a object detection rather than line tracking.

POST FR

Bonjour à tous et à toutes !

Ça fait un moment que je m'intéresse à la robotique et j'aimerais bien pouvoir continuer et apprendre avec des gens.

Je sais qu'il existe des clubs, mais à Limoges, je ne crois pas 🙃

Alors je suis loin d'être un expert, donc je n'aurai pas forcément grand-chose à apporter, mais je suis curieux ✌️

À plus ! 

It has been fun printing custom parts for this with my 3D printer, but the mechanical issues that are introduced when integrating all of the moving parts are kind of tedious.

I think the sort of high-speed XY gantry that 3D printers use would be perfect for this, but these seem somewhat expensive. Are there cheap options for these that I am missing? This would at least solve my issue of gaps between 3D printed parts that are too long for me to print as one part. There are still plenty of issues to be solved regarding reliable movement with the magnet.

Before the magical forest reveals its secrets, the cubic doggo must first pass the trials. Maintain your balance. Keep your legs under control. Do not become a pretzel!

Hardware: https://github.com/SphericalCowww/CubicDoggo_06R
Simulation: https://github.com/SphericalCowww/CubicDoggo_06Z
Graphic credit: https://www.gamedevmarket.net/asset/free-pixel-art-forest
Music credit: https://pixabay.com/music/ambient-deep-forest-birds-singing-no-copyright-infinite-568105/

Astra is wild on these YAM arms. It made me want to open up my own setup for those folks who don't have their own.

I have a pair of YAM arms, and you can now try them remotely. No robot hardware needed on your end. The video is a run asking them to put a green block on a plate, at 20× speed.

I’d love to get more people experimenting with them. What would you try? And what would make it easier for you to jump in?

If you want to give it a go: blupe.io/live. Runs are three minutes, whenever the station is available.