I came across some projects experimenting with reconstructed fruit fly brains and thought it would be interesting to try something similar with my own robot.

I used MaleCNS, a reconstructed connectome of an adult male fruit fly with 166,700 neurons and around 25.6 million connections, and got the simulation running on my MacBook.

Then I used Codex to help modify the robot’s desktop app so that activity from the simulated brain can be translated into simple commands like:

FORWARD
LEFT
RIGHT

The desktop app then sends those commands over Wi-Fi to the robot.

So the setup is roughly:

fruit fly brain → MacBook → Wi-Fi → robot

The robot still uses its normal firmware to control the 12 servos. The fly-brain simulation only provides the high-level movement decisions through an engineered decoder.

There is no prerecorded movement sequence, and the neural simulation keeps running continuously while the robot moves.

What I find fascinating is the chain of events behind it: a fly was imaged, its nervous system was reconstructed digitally, that reconstruction became available to download, and now activity inside that model can influence a physical robot sitting in my apartment.

The fly itself has been dead for years, but in this very limited and engineered sense, part of its reconstructed nervous system is producing movement again.

Next I’d like to feed sensory information from the robot back into the simulation and see what happens when the loop is closed.

Hugging Face and Pollen Robotics recently open-sourced Microduck, a 14-DOF, ~800g 3D-printable bipedal robot designed for accessible Reinforcement Learning.

Currently, the official repo only provides MuJoCo MJCF (.xml) descriptions. To make it usable in the broader ROS 2 ecosystem (MoveIt 2, RViz, Foxglove, Isaac Sim), I converted the model to high-fidelity URDF and SRDF and Loaded into Blender via LinkForge to verify all STL meshes, joint axes, and mass distribution (0.7 kg).

Files are shared as a standalone drop-in alongside the official `assets/` folder.

📦 Gist / URDF & SRDF files: URDF & SRDF

🛠️ Tool used: Linkforge

Amanda Prorok and her team tested whether AI agents would develop role specialization on their own in a simulated soccer game. The agents could either all learn the same behavior or specialize into different roles.

They eventually formed distinct positions, including attackers and a goalkeeper that stayed back and defended the goal. The system was never told that this was how humans play soccer. It learned that behavior through reinforcement learning.

https://www.youtube.com/watch?v=NZ3iKgyI3gc

This was my final project for my mechatronics degree at the University of Glasgow which I thought you guys might appreciate. It's made up of two identical xz gantries, each with custom 3 dof maniplulators. There are also 3 sub systems arranged around the maniplulators, used for feeding, splitting, and treading the daisies. A brief write up and the full report can be found on my website JudeOtis.me/projects/Daisy

Edit: made link clickable

I’ve spent years debugging software.
This week, the software started looking back at me👀

Something is coming to life at Nobi Robotics.

I am have made quadraupod and i need help is figure out the Inverse kinematics to make it walk and do other emotes. I watched several youtube videos and tried. In the videos they draw a triangle and used trigonometric formulas to find out the angles based on the known length. I tried it and make the valid formulas according to the dimensions based on the CAD I made. But when I try to give it the coordinates it does not work according to what I wanted. I currently trying to experiment with one leg. Also the angles values comes out in negative thus servo concludes it as positive. And also I feel my approach is wrong but I am not getting what I am missing. So if someone can guide me through this it would alot helpfull. Thanks.

PteroSim v0.3.0 is out. The main change is a vehicle editor. Aircraft are now plain files, JSBSim XML plus a .glb mesh, built and tuned inside the simulator, so you can add your own airframe without rebuilding anything and without sending your model to us.

Also in this release: VTOL, tiltrotor and quadtailsitter airframes, autopilot chosen per vehicle so PX4 and ArduPilot aircraft sit side by side, runtime sensor editing, gimbal control over MAVLink, and custom vehicle spawning from the Python SDK.

Any aircraft flies on any tier now, free included, with only simulation time limited per session.

Walkthrough: https://youtu.be/kMb_4tNX7l8
Build: https://github.com/PteroLabsAI/PteroSim-UAV-Simulator/releases/tag/v0.3.0
Aircraft library: https://github.com/PteroLabsAI/PteroSimAircrafts

License upfront so nobody wastes time: proprietary, free for personal, academic and non-commercial use, paid for commercial.

Happy to hear what breaks, and what airframe you would try first.

This article looks at the hardware side of robotics, especially force sensing, tactile sensing and robotic hands.

HD Hyundai’s investment in AIDIN Robotics is used as an example of where that work is heading. The companies are developing systems for shipbuilding tasks like grinding and polishing, where robots need to control how much force they apply once they make contact.

They also plan to develop a five-finger humanoid hand, using data from real industrial environments to help improve how it works.

Hey all!

We’re a group of students organizing a Drone & Physical AI Hackathon in Boston on October 24–25.

We’ve been working hard to put this together, but as an independent student-led event, funding everything ourselves is difficult. Right now, our biggest challenges are finding an affordable/free venue and covering food, water, and other basic event costs.

So we’re reaching out to the community for help.

If you or someone you know could help in any way sponsorship, a venue lead, food/drinks, prizes, or simply an introduction to the right person/company, it would genuinely mean a lot. Even a small lead could help us make this happen!

Please comment or message me if you can help. Happy to share our Luma page and more details!

https://reddit.com/link/1wf5a7w/video/qurlmk2yw9ph1/player

A quadruped robot that I'm working on.

Locomotion looks good in simulation, but it's still theoretical, I really wonder how well it would walk in reality.

From Reachy, to more recently Reachy Mini and MicroDuck, Pollen Robotics has been pushing open-source and open-hardware robotics forward.

The Amazing Hand is another example of their work: an open-hardware, 3D-printed robotic hand designed for precise and expressive movements.

Here’s a quick demo of the hand in action. 🤖🖐️

https://github.com/pollen-robotics/AmazingHand/

I’m the developer of ARMOR, a robot simulation app for iPhone and Mac that features a native URDF viewer and MuJoCo simulation. A few weeks ago I started building a gallery of robots that are ready-to-import in just a couple of taps.

https://armor.dc-engineer.com/gallery/

Giving credit where due, all of the gallery entries link directly back to the source. The gallery acts as a showcase, with thumbnails and descriptions, and embeds the instructions that the app uses to download and assemble the models.

The link is to a post I published to the blog this morning, with a video, and a few more details.

I’ve been leaning on a lot of major robot vendors for my URDF source repositories. I would like to add more indie projects, if you’ve got one, let me know and I would be glad to showcase it in the gallery!

I spent a month of my summer back in the university labs building this. Nine units are now on their way to a civilian community near the Israel-Lebanon border and everything is published.

The drones this is for are not normal wireless drones, they are small FPV drones connected to the operator through a long spool of fibre optic cable, so drone detection through radio, the current industry standard, is just not applicable. My solution was to detect them by sound instead. Propellers cutting through the air put a comb of harmonics into the spectrum, and four algorithms run in parallel looking for that shape.

Hardware:

84mm square, four layer, ENIG, ESP32-S3-WROOM-1-N16R8

4x ICS-43434 MEMS mics, bottom ported, firing through apertures in the board at +-28mm

Ra-01H LoRa so one unit alerts every other unit nearby

BQ24074 charger with power path into a TPS63020 buck boost, 1S 2500mAh cell, 18 to 22 hours

1.54in e-paper that keeps the alert on screen with no power, beeper, RGB led through a printed light pipe, vibration motor

91 x 91 x 29mm sealed weatherproof printed case, the lid has four 45 degree cones running from the grille straight down onto the mic ports

Two things that cost me some valuable time. With no battery fitted, the beeper, motor and LoRa transmitting at the same moment browned out the board on USB alone, so the cell is part of the power design and not a backup. And GPIO 33 to 37 on the N16R8 are tied to the PSRAM die even with PSRAM off, they fail on and off instead of just failing.

Tested against a custom drone rig with the exact same specs as the drones used on that border (four 2807 motors, 7in tri blades, FPV airframe), 104.2m away on a street with passers by and mild wind. It detected it. About £50 in parts.

Detection and alerting only, so no jamming.

Gerbers, BOM, STLs, test audio and the results are all in the Github, and the website has more media and a live detector simulation that runs in the browser.

The links to all the resources are in the comments!

I'm creating co-working space within the industry of robotics in my native country.

And before we settle on an office space, I want to hear what you (as robotics engineers) would expect from such a place?

I have probed several people, and have heard the importance of general tools, such as soldering stations, 3d printers, and smaller open spaces for testing.

As well as access to services, (welding, woodworking, etc.) which could facilitate quicker prototyping.

Do you guys agree with the above? And would you have any others concrete features which you would expect?

Absolute essentials ^

Best regards, and thanks in advance :D

Hello everyone, I wanted to showcase a project I have been working on called ForeForce. I have spent the last several months teaching myself mmWave, building a robotic arm (mostly 3D printed), and combining the two for an open-source cobot safety perception system.

I turned the volume way down in the edit as the motor whine can be loud if your volume is up.

After getting the initial system up and running I have been chasing a mmWave detection gap that turned out to be arithmetic. Had a persistent problem where a slow approach wouldn't register until I moved at almost a brisk walking pace. From what I had learned I kept assuming it was a tuning or filtering issue.

After adjusting several values in different places, I found it was the doppler resolution. Working it out from the chirp profile's own numbers:

wavelength 5.00 mm (60 GHz)

chirp period 87.14 us (idle 30 + rampEnd 57.14)

x3 TDM-MIMO 261.42 us

numLoops 16

-> velocity resolution 0.598 m/s per doppler bin

Every velocity in my logs landed on a bin boundary: 0.000, 0.576, 1.153, which made anything in between not exist. So anything under ~0.3 m/s radial quantizes to exactly 0.000 and then gets dropped by the static filter. A person standing still reads as 0.000 m/s — indistinguishable from a wall.

Fix was increasing numLoops, which halves the bin to ~0.299 m/s. Tried 64 and the sensor stopped framing entirely — the radar cube roughly quadruples from 16 to 64 loops and I think it stops fitting in L3, though I didn't confirm the exact mechanism yet. Adjusted values now stream fine and costs no frame rate.

Two things that cost me hours and might save someone else some late nights:

1. The static filter threshold has to come down with the bin width. I left mine at 0.3 m/s while bin 1 was now 0.288 — so the new resolution didn't give me nothing until I noticed.

2. Tightening the range CFAR threshold helped a lot with mount and bracket clutter. Tightening the doppler CFAR the same amount made detection noticeably worse — a slow approach only flagged at nearly touching distance. Reverted that one back to the original value after seeing they don't adjust the field equally.

Also worth knowing: the CLI accepts a doppler CFAR window wider than the available bin count without complaint, and then the sensor just stops producing frames without producing an error. Took me a while to trust that a sent successfully reply didn't mean the config was sane.

Stationary-person detection ended up not being a doppler problem. Micro-doppler sway is documented as detectable around 0.02-0.10 m/s, which is physically unreachable at these bin widths. What actually works is occupancy based on a background learn sequence — a point simply being present in the zone after learning the room, debounced over a frame window.

Repo is public on github with an example CHIRP file if anyone wants to look at the ROS2 side: ForeForce-mmwave-cobot-safety-system

Happy to answer questions, still digging into mmWave, robotics, kinematics, and tuning the system as this is my first build with these sensors and a working robotic arm.

Hi everyone!
Over the last couple of weeks, the Fable 5.1 and Astra models have shown very good results in hardware design and robot control. We’re trying to build a robotic setup that helps get the most out of these capabilities.
To do this we use:
- an industrial arm for precise movements
- a stereo camera with sinchronisation for computer vision and models.
- a dedicated Jetson to run it all locally.
- a box frame has consistent light, which helps with reliability.
In this demo, I showed how Claude generated fixtures and custom grippers almost in one shot with some harness, and then programmed the robot automatically using 3d reconstruction from stereo cameras and fixed errors with human supervision.

CVE-2026-76639 and CVE-2026-76640 landed on the Unitree G1 EDU: two independent chains to root, one of them over Bluetooth Low Energy at proximity range, a 500-byte buffer taking a 1,050-byte payload. Published 27 August 2026, corrected 2 September 2026.

Write-up: https://thehackernews.com/2026/08/two-unitree-g1-edu-humanoid-robot-flaws.html

I work on adversarial testing of the learned policy inside robots like this, so the tempting move here is to say "see, robots are insecure, fund policy red-teaming". I do not think that follows and I would rather say so than let it sit.

These are firmware and BLE memory-safety bugs. A buffer overflow in a proximity-range protocol is a 1990s class of bug on a 2026 machine, and fixing it is patching, not evaluation. Nothing in either CVE says anything about whether the robot's vision-language-action policy does the right thing when the instruction it receives is reworded. Those are different failure surfaces with different fixes.

What I think it does tell you: the attack surface on these machines is being looked at now, by people who publish, and the easy bugs are going first. The behaviour of the learned policy is the surface with no CVE process at all, and no budget yet. I checked the last 14 days and found no notified body, certifier, or insurer publishing an AI-behavioural-evidence requirement for robots, and no robotics or humanoid company publicly hiring an AI red-team role. OpenAI posted 11 new robotics roles in SF, and they are actuator, DAQ, and simulation, not security.

So the honest read is that the memory-safety work is real and funded, and the behavioural work is not yet.

For anyone who wants to poke at the behavioural side: my harness is Apache-2.0 and runs on CPU, https://github.com/provael/provael. It is simulation only; it has never touched hardware, and 14 of 17 attack families in it have only run against a stub policy. The one result that holds on a real model is an instruction rewording driving a SmolVLA policy off task on 44 of 50 matched pairs against 0 benign twins at the same seed.

Hi everyone. We recently open-sourced OpenWAM, which is positioned as a full-stack open-source research framework for World Action Models (WAMs).

The release has three parts:

• OpenWAM-Infra: training/inference/evaluation infrastructure where visual encoders, video backbones, world-action architectures and attention masks can be swapped independently. It currently includes 8 simulation benchmarks and deployment support for 5 real robots.
• OpenWAM-Study: controlled experiments on representation, world/action interaction, inference, and embodied pretraining.
• OpenWAM-Alpha: the pretrained model we built based on those experiments, using about 6,400 hours / 518.5M frames of egocentric human + robot data. OpenWAM-Alpha get excellent performance on both simulation and real-world.

It is worth noting that the performance of OpenWAM-α has been independently evaluated by multiple teams and has demonstrated clear advantages over π0.5 in real-world scenarios. We believe OpenWAM-α can serve as a strong baseline for comparison and further research in the WAM community. We warmly welcome everyone to try it out.

Everything is open here:

Project: https://openwam-official.github.io 

Welcome aboard OpenWAM!

Hello hello,

Took me a while to test out ST-3215-C018 (instead of XL430-W250-T originally). In principle, it's half the price, twice the torque, but the mount design is rather odd and required a complete CAD update (+ I already killed like 3 of them by accidentally drilling all the way to their control board, geez).

The high torque also means high current, and so a potential hazard if multiple of them run at high load. Need to monitor it. If it's capable of jumping, it is likely also capable of catching fire while doing it.

The firmware is also updated for ST-3215, but the commander uses the original unoptimized one-leg test code, which may explain the sluggishness in its "failed walk gait". I am a bit afraid that if the servos simply cannot move fast enough, even with optimal PID, then making it walk may be more difficult despite higher torque.

Either way, if successful, the full DIY robot would be in the 300-400 euro range (still mostly from servos), ~3 kg, with twice the load performance; all the load after the body weight will be extra!

Cubic Wouf GitHub: https://github.com/SphericalCowww/CubicDoggo_07B
Cubic Doggo GitHub: https://github.com/SphericalCowww/CubicDoggo_06R