Put Quaddle on a patch of gravel and just wanted to see it walk. Its IMU (gyroscope + accelerometer) was trying to correct for the uneven ground in real time, but it just started wobbling — loose gravel is apparently brutal for a quadruped's balance.

What other terrains should Quaddle try?

It's a pair of animatronic eyes: two servos (left/right and up/down), a frame I designed and 3D printed, and an Arduino UNO.

The hardest part wasn't the mechanism, it was making it easy to program. I wanted someone who has never coded to get it moving without fighting with IDE installs, drivers and libraries. So I made a web app:

- Block-based programming (Scratch-style) in Spanish: "look left", "wait 1 second", "nod yes"...

- A simulator that shows how the eyes will move before you plug anything in.

- Plug the Arduino in over USB and upload straight from the browser (Chrome or Edge).

- Every block shows its C++ line, so you can see the real code or download it as an .ino.

Video of it working below.

I'd like to turn it into an educational kit eventually, but I'm still refining a lot, so I'd love your feedback:

1. What would you improve in the mechanism or design?

2. If you were teaching someone with this, what blocks or features would you add?

3. Anyone used Web Serial for something like this? Any pitfalls I should know about?

Happy to chat by DM if anyone wants to know more or has ideas.

Hice unos ojos animatrónicos y una app web para programarlos con bloques, sin instalar nada

Hola! Soy estudiante de Ingeniería en Control Automático y Robótica y llevo un tiempo trabajando en este proyecto personal.

Son unos ojos animatrónicos con dos servos (uno para los lados y otro para arriba/abajo), una estructura que diseñé e imprimí en 3D, y un Arduino UNO.

Lo que más me costó no fue el mecanismo, sino la parte de programarlo. Quería que alguien que nunca ha programado pudiera hacerlo moverse sin pelearse con instalar el IDE, drivers y librerías. Así que hice una app web:

- Programas con bloques en español (tipo Scratch): "mirar a la izquierda", "esperar 1 segundo", "decir que sí"...

- Tiene un simulador para ver cómo se moverían los ojos antes de conectar nada.

- Conectas el Arduino por USB y lo subes desde el navegador (Chrome o Edge).

- Cada bloque muestra su línea en C++, por si quieres ver el código real o descargarlo como .ino.

Les dejo un video de cómo funciona.

Mi idea es convertirlo en un kit educativo para que más gente aprenda así, pero todavía estoy afinando muchas cosas, por eso me encantaría su opinión:

1. ¿Qué le mejorarían al mecanismo o al diseño?

2. Si fueran a enseñarle a alguien con esto, ¿qué bloques o funciones le agregarían?

3. ¿Les ha tocado usar Web Serial en proyectos así? ¿Algún problema que deba tomar en cuenta?

Si alguien quiere saber más del proyecto, busca apoyarlo o tiene ideas, con gusto platico por mensaje privado.

This is TAKTO ONE, a tendon-driven hand exoskeleton I built for my master’s thesis. Each of the 12 finger joints has its own magnetic encoder, and the twin in the headset moves from those sensors and two IMUs, not from camera tracking, so a hidden finger still gets measured.

It’s all open source (CAD, PCBs, firmware, build guide), and you can play with the twin in your browser, no hardware needed:
https://takto.one
https://github.com/molanocortes/takto-one

I defend the thesis tomorrow, so questions are very welcome :)

Look at my robot spider. I can programme and let him to do whatever I want. Kick the ball, push the obstacles, wave to me . I can explore more.

The lab containers had working latches. The factory’s containers had been battered through repeated use, and the tables used to rotate them were rusted. Both changed how the robot needed to handle the task.

Jagdeep Singh, CEO of Rhoda AI, describes how the team adapted the robot using roughly three hours of additional data collected in the factory, after initially thinking it had mastered the process.

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

Galbot’s PASSAGE system helps humanoid robots adapt their whole-body movements to cluttered spaces by ducking, stepping over obstacles, or turning sideways. Tested on a Unitree G1, it completed 50 physical trials across 45 obstacle layouts without falling or requiring safety intervention. However, its simulated success rate dropped from 98.67% to 70.3% when avoiding all contact became mandatory, showing how difficult precise whole-body navigation remains.

Currently working on my final year project on building open source framework to manage the full stack development of agent swarms. I want to build this to support robotics developers and enthusiasts to specifically build heterogeneous and homogeneous antigenic swarms.

I don't want this to remain a thesis or simply a good theory of what should be done, but have it actually be utilized by robotics developers. I'm very interesting in making this as useful for the community by catering to any problem across the robotics stack, from simulation to telemetry.

What does your development stack look like, and what are your pain points? Would love to know.

Reach me: https://www.linkedin.com/in/anzonathan/

Try to drive (5min) a robot live across the internet, with live video feed and thermal sensor.

Opened session 17:15-18:15 CET. https://ros.iot4.eu

I connected my YAM arms (an emerging standard) with Astra for people to try out robotics models on actual hardware. They are live here. Astra (GPT6) is given a prompt to control the gripper given the camera images as inputs, and performs well across various manipulation tasks in a zero shot manner. Really when Astra came out, I realized that most people don't have robotic arms, and don't really have a good sense for how well stuff actually works. So I decided to let people access mine in a playground format. The website is designed for those who are curious to try it out once, and the API is designed for those who want to dig in deeper and try their own experiments.

Easier robot programming still leaves small manufacturers with a lot of integration work: tooling, fixtures, machine interfaces, safety systems and support when something stops working.

This article examines those deployment barriers through several small-manufacturer case studies. High-mix production adds another challenge, since changes in parts and schedules can require repeated adjustments to tooling and programs. Employees supporting the robot often have several other responsibilities.

The examples include robot loaner programs, outside integration assistance and training CNC operators to run unattended production. It also separates growing non-automotive robot demand from small-business adoption: the industry order figures cited don’t break purchases down by company size.https://www.automate.org/robotics/industry-insights/small-manufacturers-are-supposed-to-be-automations-next-big-market-what-s-stopping-them

My team and I recently tackled the problem of high labor costs, security and slow picking times in the quick commerce industry. We ended up winning 1st place at a recent hackathon with our proof-of-concept, We built an automated dark store where robots handle the order packing autonomously.

For the hardware prototype, we utilized the LeRobot SO-101 (SO-ARM101) 3D-printed robotic arm. Because the LeRobot ecosystem is open-source and backed by Hugging Face, it was the perfect platform to rapidly prototype the teleoperation, data collection, and imitation learning workflows needed to get the arm picking and placing reliably within the time constraints of a hackathon.

We put together a 1-minute pitch video demonstrating the setup in action.

Watch the demo here: https://x.com/DsouzaJovian/status/2110028875459932364?s=20

I would love to get feedback from this community on the kinematics and our approach. I am also happy to answer any questions about our experience training the SO-101, managing the vision datasets, or the general hardware configuration we used to pull this off!

One robot is cleaning the kitchen. Another needs to get in there to cook dinner. Both are doing what you asked, but now one has to wait. Who decides?

I don’t want to be settling arguments between appliances 😄 If I have to constantly coordinate them, I’ve just given myself a new job.

I’d rather have one home “brain” that knows my priorities and manages the devices accordingly. I tell it we’re usually home by 6 and want dinner ready. It figures out when to clean, when to cook, and what needs to change if something runs late.

That brain wouldn’t need a body, and it could coordinate other home systems too. But I’d decide how much freedom it gets, when it needs to ask me, and which systems stay separate. Maybe I want my alarm system or cameras completely outside its control.

Personally, I’d want it running locally, with remote access when I’m away. And it should work with different brands. Buying one robot shouldn’t lock me into that manufacturer for everything else.

How would you handle this: one home brain coordinating everything, or robots negotiating with each other? And when they can’t agree, does the problem just come back to us?

Want to know where do cobots usually fail? Motors, actuators, gears, electronics etc... Very specifically if we program to do the same task for say 2-3 years...running for 18 hours a day, which parts of the equipment breaks with usage or has a usable life?

Most of the users I know havent faced the issues yet but the cobots (Chinese make) have run for like 5-10K hours only. Some UR users swear by no problems on equipment itself?

Does anyone have a valid one-to-one SG 90 servo model? I needed to finish building my 3 DOF arm. I need a housing around the horn to make a move, but the one I currently have is too small and I don’t really feel like modelling it myself.

Also, what do you guys think? I can’t seem to make it as cool as you guys’

I want to later on reduce the base size and add it onto a rc car I built to make it more of a rover

Hey, I had created a new UI for robotic arms that you can access and experiment with remotely.

I connected my YAM arms (an emerging standard) with Astra for people to try out robotics models on actual hardware. Astra (GPT6) is given a prompt to control the gripper given the camera images as inputs, and performs well across various manipulation tasks in a zero shot manner. Really when Astra came out, I realized that most people don't have robotic arms, and don't really have a good sense for how well stuff actually works. So I decided to let people access mine in a playground format. The website is designed for those who are curious to try it out once, and the API is designed for those who want to dig in deeper and try their own experiments.

Hi everyone, I'm Vishnu, a software engineer at Zoho. I'm applying to the BITS Pilani M.Tech in Robotics and Autonomous Systems for working professionals, and I'm looking for someone in the field who'd be willing to mentor me through it.

I'm not just after a signature. I come from a software background and want to move seriously into robotics, so I'd value someone who can:
- Help me connect what I'm studying (control, perception, planning, autonomous systems) to how things actually work in industry
- Point me toward the right projects, tools and skills to focus on
- Give honest feedback as I progress and help me shape a path into robotics roles

In return, I'll respect your time — short check-ins a few times a week on days that suit you, and I'll come prepared with specific questions.

BITS also requires a formal mentor consent as part of the application: a short email from your official work ID with your name, qualification, designation, organisation and experience. I'll share the template; it takes a few minutes.

If this sounds like something you'd be open to, or you know someone who would be, please comment or DM. Thank you!

I did this project and am looking to expand in the embedded sensor fusion direction, whats the feasibility of doing away with the camera and using sensors like Ultrasonic and angle sensors to train similar models ?

I’m updating the office “robot dojo” from my earlier simulation posts with actual Ouster OS0 data and a fixed iPhone camera.

This episode follows the sensor coming back online, its new scans being registered to the existing room map, and the camera/LiDAR alignment going through three iterations. The first solution looked good on flat walls but put the camera about 0.5 m sideways and 0.4 m too high. Matching a rendered Gaussian splat to the video, then adding my moving silhouette, exposed the ambiguity.

The next experiment was a walking human inside the twin: segment my body from each LiDAR frame → fit a capsule skeleton → colour it from the phone footage → estimate heading and gait → send the fitted avatar along paths in the room.

Some useful failures:

• The body clusters ranged from 45 to nearly 3,000 points per frame.

• Front/back ambiguity made the heading flip 180°; I used a global track plus walking direction to stabilise it.

• 23 frames contained mostly legs, so parts of the upper body are guessed.

• The gait model comes from one recording and about 13 m of walking.

The sensor capture is real; the displayed replay is recorded; the robot and generated avatar walks are simulation. The reported fit residuals are internal model checks, not independently validated motion-capture accuracy.

My EP10 build diary: https://www.youtube.com/watch?v=YlriQfsrjhc

For testing robot behaviour around a person in this twin, what would you validate first: human pose/heading uncertainty, timing between the sensors, or collision geometry? I’m especially interested in simple tests that would expose an unsafe or misleading model.

Disclosure: this is my own project/video, developed with AI agents. The episode mixes my recorded voice with disclosed synthetic narration using a clone of my own voice.

The cup is doing exactly what it should. Unfortunately, it’s also blocking parts of the hand you want to learn from.
In this clip, the worker holds the cup naturally. Some fingers wrap around its far side, and their visibility changes between camera views. The reconstructed hand overlay extends into those partially hidden regions.
For a small robotics team collecting demonstrations, that’s a useful test: can the system reconstruct the movement while the object itself obscures the hand?
Asking someone to change their grip just to expose every finger would change the demonstration you wanted to capture.
MEgoVista addresses this through hand-motion optimization over the full recording. It combines reliable visual observations with temporal continuity and anatomical constraints, giving the reconstruction information beyond a single partially blocked frame.
When a tracker draws fingers behind a cup, what would you check to decide whether the reconstruction is reliable?

https://arxiv.org/abs/2609.16684

Hi r/robotics, I'm Emre from Menlo Research. We're working on Asimov 1, an open-source humanoid robot.

We previously shared its locomotion policy and training code here. We've now made Menlo SDK public, so you can connect your own applications to the robot, control its movements and read its state.

If you're interested in building on it, a few parts are worth looking at:

• Movement and robot state: Send movement commands and read information from the robot to inform what your application does next
• Camera and audio: Connect applications to the robot's camera, microphone and speaker, for things like vision or voice interaction
• Examples and coding-agent support: Start from the included examples, with an SDK usage guide that coding agents can use when helping you write your application.

We've been using it to replay recorded arm motions, control the upper body through a VR headset and run trained policies on Asimov 1. The demo shows these workflows and how the team built them.

Alongside the SDK, we're open-sourcing Asimov Edge.

Edge is the software running on the robot that checks incoming commands and manages control between applications, a gamepad and other controllers.

A useful starting point is to connect to the robot and read its state, then work through an example before adapting it to your application. The SDK currently supports Asimov 1, and the source is available under Apache 2.0.

• Repo: https://github.com/menloresearch/menlo-sdk
• Docs: https://docs.menlo.ai/sdk

We'd be really happy to hear what you'd find useful, and get your feedback on the code and examples!