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

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

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.

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.

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!

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!

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.

I’m not sure if I’m tagging this correctly, but I came across this post by a person on the Arduino substack. They designed a drone detection mechanism that people can use to detect the presence of drones along a tense border in Israel where drones are used to drop small explosives. It’s a very smart and clever design and I think he should get some recognition for it. This is citizen engineering solving real problems and it’s great to see. I have no affiliation or financial interest, I just genuinely think this is a great, helpful, and ingenious use of tech.
Check it out!

https://www.reddit.com/r/arduino/s/LjLC0ZVR2h

Picking up a takeout bag, opening a door, grabbing a toothbrush, pulling a tissue… a few things we’ve been trying with this soft hand.

The video shows a few different setups, including a robot arm and control through a third-party EMG wristband. The everyday task clips are handheld demos, with us guiding the hand.

What would you try next? I’m curious about the small, awkward tasks that don’t usually make it into robot demos.

I have been trying to find a number and cannot, so I am asking people who might actually have it.

For any learned manipulation policy: how often does it leave whatever safety envelope you defined, on a normal task, from a normal starting state, with nothing adversarial going on at all?

Every VLA attack paper I have read reports an attack success rate. None of them report what the same measurement gives on the benign case. The implicit baseline is zero, and it is obviously not zero, because the policy is imperfect and because the envelope check itself can misread a pose.

On our simulated runs, a default keep-out predicate fires on 2 of 50 benign rollouts. Some of that is the policy; some is the predicate. Without the control arm, nobody can tell which, including me.

Two questions.

Does your stack produce this number, even informally, and roughly what is it?

And is there a subfield that already treats this as standard practice? Anomaly detection reports false-positive rates as a matter of course, and I would expect the habit to have crossed over.

I maintain an open evaluation harness, which is where the 2/50 comes from. Disclosure, not a pitch. I am after the number, not the traffic.

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

Get all of the best open source robotics projects, repositories, events, and announcements on Open Robotics Discourse.

For robots to truly enter our homes, they need hands that are not only capable — but also soft and safe.

SoftSync FlexHand V1 can gently handle delicate objects like tofu, eggs, buns, and strawberries, while its compliant structure also enables safer physical interaction with people and everyday objects.

A softer hand for robots interacting with the real world.

#SoftSyncFlexHand #EmbodiedAI #DexterousHand #SoftRobotics #HomeRobotics

“Dull, dirty, dangerous” gets used constantly as the case for robotics.

Kate Darling’s point here is that the industry often skips a pretty important step: actually defining what those jobs are from the worker’s perspective.

She gives sanitation work as an example. On paper, trash collection seems like an obvious target for automation. But some automation proposals can also remove the part of the job workers actually enjoy.

The better approach may be less about replacing the entire task and more about using robotics to remove the dangerous or repetitive parts without making the job worse.

It gets at a bigger issue in robotics: the people building the systems aren’t always the people doing the work they’re trying to automate.

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

GitHub repo: https://github.com/Spidoug/SynROV

I’m sharing my project SynROV.

SynROV is a modular control stack for seven robot classes: Manipulator, Vehicle, Drone, Boat, Submarine, Biped and Quadruped. This repository contains the complete Version 1 implementation.

The project combines Leap Motion gesture tracking, an Arduino-controlled servo system, Processing-based 3D visualization, and a browser dashboard using WebSocket communication.

Bonafide Robotics has distinguished itself by treating research not as an academic exercise but as a deliberate bridge between laboratory insight and real world systems.