Over the past month, we completely switched to frontier LLMs to control a robot in a customer deployment.

By doing this, we have a classic System 1/System 2 architecture, but on steroids.

For the high-level reasoning layer, we use an agent based on Opus and Astra, which are many generations more capable than any VLA. For the fast execution layer, we use computer vision code written by the model, which is fast, editable, and reliable.

As a bonus, we got in-context learning, which is just a basic feature of LLMs, and continual learning, since whenever a new situation arises, the large model steps in and adapts the pipeline.

And it just feels better to be on the right side of the Bitter Lesson, benefiting from the billions being invested in frontier models around the world.

They say robotics moved west, but Boston didn’t get the memo. 🦞

The Massachusetts ecosystem is one of the world's leading hubs for robotics, combining top research, companies, and deep-tech investment.

At its core are Massachusetts Institute of Technology (MIT) and Harvard University which produce world-class researchers, engineers, and robotics startups.

Many of today's leading robotics companies trace their roots back to these universities.

The region is also home to companies like Boston Dynamics, whose work has inspired advances in humanoid and mobile robots.

Around these companies, a dense network of suppliers, experienced engineers, entrepreneurs, and investors has developed, making it easier for new startups to build and scale.

Massachusetts also has one of the strongest deep-tech funding ecosystems in the world, with venture capital firms that understand robotics, AI, and hardware.

The Massachusetts robotics ecosystem is further strengthened by leading research organizations such as Toyota Research Institute and RAI Institute, which are advancing AI, dexterous manipulation, and next-generation robotics while attracting world-class researchers and engineers.

Not to mention initiatives like MassRobotics which is home to so many great robotics companies.

In simple terms:

→ You need world-class robotics talent → recruit from MIT and Harvard.
→ You want experienced robotics engineers → hire people who have built robots at top companies.
→ You need funding → access investors with decades of experience backing deep-tech startups.

Back in April, this was just an idea.

This is Visual Recovery: universal, real-time 4k60FPS NVIDIA CUDA GPU processing software featuring an algorithm I designed specifically for real-time operation in murky waters.

The GPU processing takes approximately 5-10 ms per frame in this tests.

Still experimental, but I'd genuinely appreciate feedback from ROV operators and anyone working with underwater computer vision.

This is a truly passionate solo project.

What do you think?

Previous: https://www.reddit.com/r/robotics/comments/1vj4oym/built_a_realtime_underwater_image_processing/

https://www.reddit.com/r/robotics/comments/1wvy51m/built_a_realtime_underwater_image_processing/

I simulated this robot dog inside a training platform I built on top of the MuJoCo physics simulator. I built a specialized reinforcement learning trainer with** motion imitation (style reference motions)**: the dog learns to copy a keyframed trot while still balancing on its own, which makes the gait way smoother than plain RL. The joints are limited by realistic hobby servo models (torque, speed curve, backlash, latency), not infinite-strength motors. It trained on my MacBook Air’s CPU for 2 hours (no GPU) and learned multi-directional control (I can drive it with WASD) and balance

I built a hexapod that uses an old Android phone from Make Your Pet. Less than $200 and it was a good first robotics project to learn from.

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.

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.

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!

🎃🤖 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

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.

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..

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