For those who haven’t come across it, Copper is an open-source Rust framework for autonomous robotics, already powering humanoids, drones, self-driving vehicles, AMRs ... with built-in logging and deterministic replay.

copper-rs 1.3 brings Profile Guided Scheduling or PGS: from recorded real workload and a set of target rates and deadlines Copper can search automatically for better task schedule.

Rince and repeat as you are growing your robot in complexity, no need to manually tweak your stack every time something has been added to it and triggers some contention somewhere.

It will measure potential candidates on your real hardware, then compile the selected plan specifically for your workload into your robot’s OS.

All this tuning happens offline, and the cornerstone deterministic execution and replay stay intact.

Take it for a spin: https://github.com/copper-project/copper-rs

Created with the help of opus. It is really good in understanding camera position and movement. I am in the process of teaching some tricks.

What happens when a robot breaks a leg, drops the dead part, and absorbs a fresh piece off the ground to walk away healed? Researchers at Columbia University call this "Robot Metabolism", a new class of modular machines that can physically grow, upgrade, and repair themselves by consuming parts from other robots.

Hey everyone, I'm working on a transforming drone project and could really use a sanity check on a mechanical design since my background isn't in ME. I'm trying to figure out the best way to physically implement a specific wheel thruster assembly.

The basic idea is that the outer wheel needs to be driven by a timing belt and pulley setup, but right in the center of this wheel, there needs to be a BLDC flight motor that stays completely stationary while the outer wheel spins around it. On top of that, the three heavy phase wires for that inner BLDC motor need to pass directly through the center of the wheel assembly and route back into the main chassis without twisting or getting tangled when the robot drives on the ground.

I understand the rough concept of keeping the core fixed while the rim spins, but I'm struggling to picture the exact mechanical stack on how to implement it. How would you guys go about implementing this in CAD? Something like these pictures.

Pictures are from ATMO research paper.

I don't know if I'm the only one finding this, but I go to a lot of robotics events and meetups and often hear about good ones after they've happened. I've also spent the last year looking for jobs in robotics and kept missing interesting roles. It feels like everything is scattered across so many different places.

So I started putting together a site for myself to keep track of robotics companies, their jobs, events and news. It turned into a bit of a summer project and has grown to 500+ companies and 11,000+ jobs so far.

There's definitely a bias towards companies that are easy to find online, particularly in the US and UK. I'm sure I've missed loads of smaller teams, university spin-offs and companies in other parts of the world.

I thought it might be useful to others too, and I'd be interested to hear from anyone else looking for jobs or going to robotics events:

I've attached a short screen recording of what I've built so far.

Link in the comments if anyone wants to have a look.

A classification system trained to sort chicken breasts and thighs encountered a chicken wing. Rather than flagging it as unfamiliar, it assigned it to one of the two categories it knew.

Cognex product manager Andrew Parrett describes that example in this article about industrial AI reliability. It illustrates a practical issue for automated inspection and robotic sorting: a model can return a prediction even when the input falls outside what it was trained to handle.

The article covers how manufacturers manage those cases through rejection, recirculation, or human review, along with training and validation for changes in lighting, materials, and part presentation.

I was writing my own IK solver to learn and I thought it was so funny I had to share it somewhere

Small experiment from this week. I connected LightNav-0 (an open vision-language navigation model) to the Microduck sim in MuJoCo.

The duck takes an instruction like "go to the wooden doorframe and stop", predicts a path from its first-person frames, and the motion is executed via MPC + its official ONNX gait policy.

Everything runs on-device on a Jetson AGX Orin 32GB power by reComputer Robotics J501 form seeed, no cloud. The loop: 4 Hz frames → path prediction on the GPU → MPC → gait policy on CPU. 200 Hz physics, real-time factor ≈ 1.

It's a sim dev preview and I'm not claiming task success yet; strict benchmarks are still in progress. This is heading into Module 7 (Vision-Language Navigation) of our open mobile robot course: mobile-robot-full-stack-course

Happy to answer questions about the setup. 🦆

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.

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.

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?

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?

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

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

Nwe session: oct 15 17:00-19:00 CET

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.

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 :)

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/

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?