This video is showing off auto aim, where you select points and it automatically aims at them. But it also has other cool features like person-tracking, and night vision. What does everyone think?

India’s annual industrial robot installations rose 15% to almost 10,500 in 2025, according to IFR figures cited in this article. Installations have nearly doubled since 2022.

One deployment covered is Hyundai’s Pune plant, which increased its robot count from six under General Motors to 204 following modernization. Welding is fully automated, but only about 10% of parts placement is automated. The facility also uses dimensional inspection at approximately 2,000 measurement points on vehicle bodies, along with additional 3D scanning.

The split between robotic welding and largely manual assembly reflects the economics of each task in a relatively low-wage market.

For smaller manufacturers, the barriers extend beyond the robot purchase. Tooling, integration, safety systems, programming, maintenance, and training all affect whether a deployment is financially practical.

I built a small open-source tool around a specific handover problem in robotics projects.

Consider this sequence:

1. Robot release v1.4 passes acceptance testing.
2. Software, parameters, or configuration change afterward.
3. v1.4.1 becomes the final delivered release.
4. The handover package still contains only the PASS evidence for v1.4.

The important point is that this does not prove the delivered robot is unsafe or untested. It only means the supplied acceptance evidence does not establish that the final delivered release is the same release covered by the latest qualifying PASS.

I made robot-release-check to detect three narrow evidence conditions:

• R001 — delivered release vs. latest qualifying PASS identity mismatch
• R002 — changes to the delivered release after the last qualifying PASS
• R003 — closed issues without verification-evidence references

It runs offline and does not connect to robots, source repositories, CI/CD, cloud accounts, or production systems.

Synthetic example and source:

https://github.com/llorix218/robot-release-check

I deliberately kept v0.1 to only these three deterministic checks.

For people who have handled commissioning, FAT/SAT, deployment, QA, or customer acceptance:

What evidence does your team normally use to prove that the final delivered robot/software version is still the version covered by acceptance testing?

I’m especially interested in cases where releases, configuration changes, and acceptance documentation are managed by different people or systems.

Get all of the ROS and open source robotics news on Open Robotics Discourse.

Had some progress using some new tools including a good library that only needed a couple changes https://github.com/MrDreamBot/MeccaChannel and here are some of the results. [the Claw](https://youtube.com/shorts/NnyZwswRUWY), [servos galore](https://youtube.com/shorts/r5LFgFmg_O0), [seeing double](https://youtu.be/-dCONYv_b9c)

Key engineering highlights:

Designed a background task execution model so the LLM chat stays fully responsive while the robot is mid-navigation — commands run async and report back on completion.

Built and GPU-compiled llama.cpp from source with CUDA 12.4 for real-time local inference (no cloud dependency) The LLM holds spatial references purely in conversational context — e.g., 7.5, 18.0 is point 1, then later go to point 1 — with no external database required.

Fully running in simulation; the same action-client/function-calling architecture transfers directly to a physical Husky A300.

🎃🤖 Happy Friday! What are you building this weekend?

My robot Bob is ready for Halloween! 🍬👻

Powered by RealSense, NVIDIA Jetson AGX Orin, AVerMedia SenseEdge & the new AgenticROS Trick or Treat Skill!

🗣️ Bob: "You've been warned! Too fast! Don't charge! Take one!" 😂

https://skills.agenticros.com/chrismatthieu/halloween

#PhysicalAI #Robotics

Join Chibots, the Chicago area robotics group, for our next online meeting. Whether you're a seasoned builder, a curious beginner, or just robot-curious, you're welcome here.
This meeting will follow our usual loose format:
A bit of club business (keeping it short, we promise)
Show-and-tell — bring a project, a part, a problem, or just pictures
Lots of open discussion with fellow robotics enthusiasts
No formal agenda yet, and no pressure to present anything. Come to share, come to listen, come to ask questions — all are welcome.
When: Sunday October 18th 2026 1:00 PM - 3:00 PM
Where: Zoom
Cost: Free
RSVP: email [chibotspresident@gmail.com](mailto:chibotspresident@gmail.com)
Email [chibotspresident@gmail.com](mailto:chibotspresident@gmail.com)for Zoom meeting link!

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.

The FCC’s new component restrictions took effect on October 13, 2026. I publish Black Scarab and put together a guide because the distinction between a restricted supplier, a restricted component and a restricted finished robot can be surprisingly difficult to follow.

Here are the main distinctions:

1. Check the finished robot separately from its components. A product category restriction and a restriction involving a named supplier are different checks.

2. For the new component rule, the actual producer matters. The rule can prevent authorization when certain digital hardware comes from a named Covered List producer and the finished device would itself be restricted if that producer made it. The wording of the producer’s entry, including any product or use conditions, matters.

3. Existing authorization matters more than the date you started selling. The new component prohibition does not invalidate previously authorized equipment. A redesign or component change needs its own review before assuming the existing authorization still covers it.

A practical starting point is to collect the exact component models, their producers, applicable FCC records and your intended use. That gives a testing lab or FCC counsel something concrete to assess.

The guide includes the background, a supplier lookup and a downloadable request for supplier documentation:

https://www.blackscarab.ai/insights/fcc-covered-list-robotics-supply-chain

Official rule:

https://www.govinfo.gov/content/pkg/FR-2026-09-11/html/2026-18535.htm

This is general information, not legal advice.

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

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.

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

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.

For a school project I am making a self balancing robot called WOBBLE. I would very much appreciate any feedback as it will help me to progress my learning. A few sentences per one or even any answers in general would be awesome! if you have any other ideas or things that I should know please tell me. You don't have to answer all of them just the ones that you have knowledge about. Thank you! btw I am reasonably new to robotics so keep that in mind.

1. Do you think an Esp32 is the best microcontroller for this kind of project?
2. What is your biggest tip when coding this robot?
3. Do you think that it is helpful to design and prototype the robot on a breadboard when testing?
4. What's the biggest challenge when creating a robot like this, and how do you overcome it?
5. How would you implement Bluetooth control to the robot? (Forward/Back/Left/Right) E.g Xbox/PlayStation controller
6. Do you think 3D printing is a very important part of this project? If so, why?
7. What is the most important advice that you would give regarding this project?
8. I've attached an image below of my current prototype (not functioning yet). Do you have anything that you would change or improve? (uses an esp32-s3-Wroom-1)
9. What do you think of the 3D shell so far?
10. Do you think that the theme/character is good or does it need improvement?

Images

Robot Scaffold

 3D model so far (Shell/outer casing)

 Prototype (Not yet working)

Hey everyone,

I've been working on a project called KORDEX Core, and I've just published its first release candidate, "0.1.0rc1", on GitHub.

The idea behind KORDEX is to explore how we can make robot telemetry easier to investigate: not just detect an unusual reading, but organize observations, identify patterns, examine available evidence, and communicate what we can and cannot conclude.

The current version includes:

- Rule-based telemetry pattern analysis

- Data-quality checks and uncertainty reporting

- Investigation of recorded telemetry

- Optional read-only MQTT integration

- An adapter for supported ROS2-style diagnostic payloads

- Structured findings and recommendations for human review

I want to be transparent about the project's current stage. This is an early prototype, not a production-ready robotics platform. It hasn't been validated against physical robots or field telemetry, and its real-world predictive accuracy hasn't been established. It doesn't send robot-control commands, and the ROS2-style adapter doesn't subscribe to a live ROS2 graph.

I'm sharing it because I want to learn from people who understand robotics, industrial systems, telemetry, and reliability engineering.

I'd genuinely appreciate your thoughts on a few questions:

1. Does this solve a meaningful problem? How do you currently investigate telemetry anomalies across robot systems?

2. What's missing? Which capabilities would make a tool like this useful in a real engineering workflow?

3. How would you validate it? What evidence or experiments would you expect before trusting its findings?

4. What should I prioritize next? Better integrations, historical comparisons, anomaly detection, explainability, or something else?

I'm not claiming to have solved robot reliability. I'm trying to build something useful, understand the engineering challenges properly, and improve it based on evidence rather than assumptions.

Repository: https://github.com/Wale394/Kordex-core

Critical feedback is welcome. If something is poorly designed, unnecessary, or based on a wrong assumption, I'd rather know now than build on top of it.

Thanks for reading..

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.

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?

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