• Wednesday, October 21st, 7pm PT -- Gazebo Community Meeting on Multi-Robot Simulations
• Wednesday, Oct. 21st-23rd -- ROSCon UK at National Robotarium in Edinburgh
• Thursday, Oct. 22nd, 6pm PT ROS By-The-Bay at Intrinsic office in Mountain View. Speakers include Yutaka Kondo (developer of swift-ros2), Davis Foster co-founder of Agency Tool Co., Jose Diaz, co-founder of Thurst Robotics.
• Friday, Oct. 23rd, 9am PT ROS Office Hours. Come share your projects, meet our maintainers, and ask questions.

I've been working on an under-actuated drone that can fly with only one motor for the last few months. The propeller hub is 3D printed out of PPA-CF and has a hinge, so when the motor accelerates the blades lag behind and one pitches up while the other pitches down. By pulsing the motor torque 300 times a second, timed to the rotor angle, the drone controls its pitch and roll with the same motor that produces its thrust.

Along the way I also built a "poor man's high speed camera" - a camera flash synced to my camera and motor controller, so I could take images of the propeller at precise angles to analyze its behavior.

The mechanical simplicity hides a lot of software. At almost 20,000 RPM, a 0.2 ms control loop is already 20 degrees of rotation late, so I wrote custom firmware for the motor controller to compute the torque pulses on board. The body also slowly spins, so the drone gets its heading from an infrared "lighthouse" beacon in the corner of the room that it sees once per revolution.

The full video explaining how it all works is available on youtube: https://www.youtube.com/watch?v=Ndftcft6XhU

The code and CAD are open source on github: https://github.com/jyjblrd/single-propeller-drone

I posted here 8 months ago and am only now posting again, haha. This is how I've improved over the past 8 months:

MK5 V1:

The appearance was impressive, but... Yes, I lacked torque.

MK5 V2:

Hmm...

MK6 V1:

it walks!! it walks!! it walks!! 🐕🐕

MK6 V2:

Laser cut leg

Hell yeah😎😎

Two-arm guy

Two-leg guy

: w.i.p

DMs are welcome, and those who really want to see them can do so in Seoul😎

T h a n k y o u !

Following up on last week's MicroDuck experiment. Same brain, different body!

This time, I connected LightNav-0, an open vision-language navigation (VLN) model, to a MuJoCo digital twin of our DM-H65 two-wheel differential-drive robot. we are working on it.

The goal: "Locate the refrigerator in the room and stop beside it."

The video shows the full closed loop with 17 model predictions, including replanning and recovery when a predicted path expires.

Everything runs locally on a Jetson AGX Orin 32GB, powered by Seeed's reComputer Robotics J501.

To be clear: This is a simulation demo, not a validated navigation success. The focus is on getting the VLN model, robot control, and recovery behavior working together.

This is part of our open-source mobile robotics course:

https://github.com/Seeed-Projects/mobile-robot-full-stack-course

Would love to hear from others experimenting with VLN on real or simulated robots!

https://www.youtube.com/@ALMA.Industries

Chapter 3 Footnote 1. Building an Actuator, a PID Control Loop, and an Ultrasonic Distance sensor to detect and not crash into the ceiling. This will be used in Chapter 3 Desk -- Stay tuned for more!

More info about cad and STL

https://cults3d.com/en/3d-model/game/3d-printed-rocker-bogie-mars-rover-esp32-cam-6-wheel-robotic-platform

A side-by-side look at Éloi’s face and the mechanical structure underneath. One of them just happens to be dressed for the occasion. Somehow, this became our most dramatic photo from the lab. (Though we’re also getting some Coco vibes 🌸💀)

Animotion Robotics

I have created 42 customizable Gazebo & Blender simulation worlds for testing, benchmarking and improving projects that involves navigation, exploration, LiDAR and robot model setups ex.

The project is open-source and licensed with Apache 2.0 so you can use it freely.

Currently the worlds are 2D plan based environments with simple objects including mazes, offices, warehouses, forests, real world places, moving obstacle worlds and challenge orriented worlds.

I used these worlds mainly for testing my exploration project and wanted to share with you, but you can benefit from them for many various type of projects.

The Gazebo itself doesn’t have a good experience with creating and developing worlds so the project works via Python SDF asset generation. Which allows math calculations and easier customizations to be done.

GitHub Repository: mertgulerx/world-collection

I am also planning to add 3D and textured worlds to the repository especially required for Agentic Workflows, Perception, 3D Mapping, Object Detection and Robot Training in the future.

MK6 got stepped on by Spot.

It said it didn't hurt much lol.

I think this was the evening of the day I developed the MK6 V2 and participated in the Maker Faire.

2026.09.19 😎👍

Hi,

At Foxglove, we recently ran a free live session on building a robotic data platform that I thought the community would find useful. We'd love to hear your feedback!

EMG-Driven Robot Control vs. Traditional Control | PNP Robotics Validated on Franka + Dexterous Hand

Traditional robot control depends on pre-programmed trajectories, joystick teleoperation, and fixed control logic. While reliable for repetitive industrial tasks, it lacks flexibility, cannot perceive human intent, and struggles with unstructured, dynamic manipulation scenarios.

EMG-based control fundamentally changes human-robot interaction logic.

Surface electromyography signals capture neuromuscular activation prior to actual motion, enabling robots to decode human movement intention in real time. Instead of executing rigid preset paths, the robot moves naturally and synchronously with the operator’s muscle activity.

Key Technical Differences

🔹 Traditional Control

Fixed trajectories · Passive execution · High operational threshold

Suitable only for standardized, repetitive tasks

🔹 EMG Intent Control

Intention-driven · Real-time adaptive motion · Zero rigid programming

Enables compliant, delicate, and human-aligned dexterous manipulation

PNP Robotics Field Validation

We have successfully verified the EMG + dexterous hand control system on the Franka collaborative robotic platform.

Our implementation achieves:

• Real-time EMG signal decoding and motion intention understanding

• Synchronous control of 7-DOF arm and multi-joint dexterous hand

• Stable adaptive grasping and fine in-hand manipulation

• Natural, low-latency human-robot collaboration

This validation demonstrates that EMG-driven control effectively overcomes the rigidity of traditional robot control, providing a more human-centric, flexible, and intelligent solution for next-generation embodied intelligence and collaborative robotics.

#Robotics #EMGControl #HumanRobotInteraction #DexterousManipulation #FrankaEmika #EmbodiedAI #PNPRobotics #CollaborativeRobots #RobotIntentionControl

There was a discussion here a couple of days ago about using frontier LLMs and generated code instead of relying entirely on an end-to-end VLA.

A research team at the company I work for recently tested a related idea at benchmark scale: what happens if the coding agent itself becomes the closed-loop robot policy?

The agent receives RGB observations and robot state through a small programmatic interface. It then writes Python control programs, executes end-effector and gripper commands, observes what physically happened, and edits the next program from the resulting state.

So this is not an LLM selecting skills for a VLA underneath it. There is no learned motor policy generating the actions. The coding agent decides what to observe, which control program to run, and how to repair that program after a failed grasp or an unexpected state.

It also gets a Playground phase in which it can experiment with one scene. Successful procedures and failures are distilled into executable Skills and diagnostic Lessons, then frozen and passed to fresh agents working in unseen layouts.

The system briefly reached the top of RoboDojo-Sim before the leaderboard moved again. But the ranking seems less interesting than the architectural question. On the paper’s October 9 snapshot, this agent-based approach outperformed the evaluated VLA, world-action-model, and agent-plus-VLA systems without target-task fine-tuning.

The failure pattern is revealing too. It performed well on memory-dependent and open-ended tasks, but achieved only 13.25% success on precision tasks. Insertion and fine contact control remained major problems.

That makes me wonder whether the likely destination is:

1. coding agents replacing VLAs as the policy;
2. agents acting as the slower “System 2” above a fast VLA;
3. or agents remaining useful mainly in simulation, where latency and mistakes are cheaper.

Which direction seems most plausible to people actually working on robot learning and control?

Agility Robotics says its upcoming Digit 5 humanoid will use Nyobolt batteries to deliver 90 minutes of operation after a nine-minute charge. The targeted 10:1 run-to-charge ratio could support more than 20 productive hours per day in warehouses and manufacturing facilities. Early-access deployment is planned for the first half of 2027, but the company has not yet disclosed the battery capacity, cycle-life rating, or independent real-world test results.

This sample program is provided in the lesson plans available through the Edison robots website.

It seems to indicate I can use this program to either drive the Edison forward or turn depending on the number of claps.

However, once downloaded it only seems to do the turn no matter how many claps I do.

Any help would be much appreciated!

Hey everyone, will be starting a project soon on a rover design specially the trackpad of both the drive and 2 flippers. The bot I want to design, in the drives, will be normal roller type and will have 2 flippers at the front.

The main difficulty for me is, I have designed lower level mechanical designs like electrical boxes, painting pot and brush holder, but this level is totally new specially designing and fitting the trackpads with flippers.

Want your advices in terms of facing difficulties in designing the gaps properly and how efficiently can i design the whole drive system. Please, kindly let me know.

Thanks In Advance.

Hi everyone! Not sure if this is the right flair or subreddit for this inquiry but I am trying my luck!

Looking for a collaboration with someone who has made a fully functioning robotics machine (example: like the mars rover or something in that general field) that they would like to showcase next year.

CONTEXT: I am hosting a NYFW show in NYC next year showcasing my cyber/steampunk space inspired collection. I would like to showcase and collaborate with someone who would like to share their work on a stage. I am no where near well versed to make and create my own robotics, so I was hoping someone would be open to connecting the bridge of couture (high fashion) and science with me. It would be a demonstration on the catwalk or simply stationary in the middle while the audience could see the functions in person. The models would maneuver around the displayed robotics making sure your work is also being carefully considered and safe.

i’m happy to share concepts (think dystopian, commentary on space tourism and the implications of it and what that looks like for the future, etc) and the collection or any other context privately. if this is something you or someone you know would be interested in please comment or message me! If there is a better sub to post this I would be grateful for the recs!

Thank you!!

Drones are the next section

Online tools that run sample by sample on a flight controller's data, on a Raspberry Pi or an NVIDIA Jetson next to it. This issue splits the work into small points. Pick one, say so in a comment, and open a PR. Every point has a question it answers, a data source and a way to check it, so a first contribution fits in an afternoon.

How to take a point: comment "I take N", fork, work on a branch, open a PR that mentions this issue. One point per PR. Questions in the comments are welcome.

Ground rules for every point

- Each number on a page comes from a script of the repository that was run before the sentence was written.

- Synthetic data are labelled "synthetic" everywhere they appear.

- "Tested on a Raspberry Pi / a Jetson" is written only when the command ran on that board; otherwise "written, not run on the board".

- Sources are the papers named below, with page numbers.

## Data and adapters

1. **PX4 ULog reader.** Yield one dict per sample (time, gyro, accelerometer, GPS velocity, motor outputs, battery voltage) with `pyulog`. Check: a tiny ULog written by the test round-trips.

2. **MAVLink tlog reader.** The same fields with `pymavlink`. Source: the MAVLink survey, arXiv:1906.10641 (Koubaa et al., IEEE Access 2019).

3. **Synthetic flight generator.** Hover plus a circle, noise, one fault at a stated sample, labelled. The single source of data for tests and smoke runs.

4. **ALFA loader.** Load the fixed-wing fault dataset (arXiv:1907.06268, Keipour et al., IJRR 2021; data DOI 10.1184/R1/12707963) and its ground-truth fault times. Check: the 47 processed flights load and the fault time of each is read.

## Pipelines (each answers one question)

1. **Which part broke, and how many seconds after?** Residual of commanded against measured rate, a CUSUM detector with `reset_on_alarm=True`, a robust Mahalanobis score. Metrics: detection delay and alarm episodes per hour of normal flight. Data: ALFA (point 4). Related: Garg and Fan, arXiv:2309.09108.

2. **Is the GPS telling the truth?** Online comparison of GPS velocity with the integrated IMU. Inject an offset ramp into normal flights and say so on the page. Motivation: SemperFi arXiv:2105.01860 and Kim et al. arXiv:2407.15003.

3. **Is a propeller damaged?** Online spectrum of the gyro or accelerometer and a distance of the band energies from the healthy baseline. Related: Zhang et al., arXiv:2302.04410.

4. **How many minutes of flight are left, and how sure are we?** Online fit of voltage against current and time with an interval; the remaining time as a distribution. Source for the energy model: Alyassi et al., arXiv:1703.10049.

5. **Is the next move safe?** Distance to a geofence and to obstacles from the simulated lidar of `benchmarks/lidar_sim.py`, with the protection tools already in the library.

6. **Where is the landing pad, and is the camera moving?** `GlobalMotion`, `MotionMask` and `FrameAnomaly` on synthetic frames of a pad. Metrics: pixel error against the planted position and time per frame at 640x360.

7. **Is the radio link about to fail?** A drift detector on packet inter-arrival time and RSSI of a synthetic MQTT stream.

8. **Static against online.** The same fault data with a scikit-learn batch model and the online one; median of 20 seeds, time per sample, memory. The page follows `docs/finance/static_vs_online.md`.

## Boards

1. **Raspberry Pi to Pixhawk page.** Serial wiring, the PX4 parameters and the Pi settings, with each step checked against the PX4 documentation page (https://docs.px4.io/main/en/companion_computer/pixhawk_rpi.html). Mark every step you ran yourself.

2. **Jetson power modes page.** The `nvpmodel` modes of each Orin module and the time per sample of a pipeline in each mode, measured on the board you own.

3. **`edge_bench.py`.** Time per sample (median and interquartile range), 99th percentile, resident memory and CPU temperature for each pipeline on a given board, written to a JSON file named after the host. Include your board model in the file name. Results from a board you own are the most valuable contribution here.

4. **Dockerfiles for arm64 and Jetson, `install.sh`, a systemd unit and an MQTT bridge** publishing the score and the alarm episodes. Base image names come from the vendor documentation, with the URL.

## Also open

1. **ArduPilot.** The same adapters against an ArduPilot log, with the differences written down.

2. **A flight log of your own.** Run a pipeline on a log from your drone and tell us what it found, as a comment or a page.

3. **Spotted something in the plan?** A missing pipeline, a better source paper, a wrong sentence. Open a comment and it becomes a numbered point.

A new contributor can start with point 3, 13 or 18. The folder with the instructions, rules and papers is kept by the maintainer; ask here if you want a copy.

## Papers to read (one per area)

- **MAVLink, the protocol every point 1-2 and 16 talks to:** A. Koubaa et al., "Micro Air Vehicle Link (MAVLink) in a Nutshell: A Survey", IEEE Access 2019, arXiv:1906.10641.

- **Fault data and metrics (points 4-5):** A. Keipour, M. Mousaei, S. Scherer, "ALFA: A Dataset for UAV Fault and Anomaly Detection", IJRR 2021, arXiv:1907.06268.

- **Actuator faults (point 5):** K. Garg, C. Fan, "Neural Network-based Fault Detection and Identification for Quadrotors using Dynamic Symmetry", arXiv:2309.09108.

- **GPS and state-estimator attacks (point 6):** H. Sathaye et al., "SemperFi: A Spoofer Eliminating GPS Receiver for UAVs", arXiv:2105.01860; K. H. Kim et al., "Predictable by Design, Vulnerable by Nature: Security Consequences of Learnability in UAV State Estimators", arXiv:2407.15003.

- **Propeller faults (point 7):** W. Zhang et al., "Simulation-to-reality UAV Fault Diagnosis with Deep Learning", arXiv:2302.04410.

- **Battery and energy (point 8):** R. Alyassi et al., "Autonomous Recharging and Flight Mission Planning for Battery-operated Autonomous Drones", IEEE T-ASE 2023, arXiv:1703.10049.

- **Boards (points 13-16):** PX4 documentation, "Companion Computers", https://docs.px4.io/main/en/companion_computer/ and "Raspberry Pi to Pixhawk", https://docs.px4.io/main/en/companion_computer/pixhawk_rpi.html; NVIDIA Jetson Orin power modes, https://docs.nvidia.com/jetson/archives/r36.4/DeveloperGuide/SD/PlatformPowerAndPerformance/JetsonOrinNanoSeriesJetsonOrinNxSeriesAndJetsonAgxOrinSeries.html.

Know a better paper for one of these areas? Add it in a comment with the arXiv number.

link : https://github.com/tatopenn-cell/Dense-Evolution-Discovery/issues/266

This little robot arm was designed for educational purposes.

The goal was to build a small, simple 3D-printed arm capable of precise, smooth movements. The first version has 4 DOF, with room for future expansion.

The J1, J2 and J3 joints use factory-made POM gears from the main gear of a Tarot 450 model helicopter. These mesh with the factory-made metal gears on the round NEMA 14 stepper motors, which are designed for 3D printer extruders. Torque is transmitted to the J3 joint through a GT2 belt, allowing all the steppers to remain at the base of the arm.

J4 is driven by an RC servo. It has some backlash, which could be eliminated with spring preload.

The controller is an inexpensive 3D printer board, the BTT SKR Pico, equipped with quiet TMC2209 stepper drivers. These can detect motor stalls, allowing sensorless homing.

The gripper is made of flexible TPU. The servo pulls a central filament, causing the fingers to bend inward. It's a very simple design that tolerates small positioning errors without putting much strain on the servo.

To make the programming more interesting, we set ourselves the goal of building a robot that could play Nine Men's Morris by recognizing its opponent's moves using a camera.

This video was recorded the first time the arm was able to play a game. Its movements will become smoother and much faster as development continues.

We developed custom Arduino-based firmware for the Pico board. By feeding motion commands into a queue, it allows the arm to move continuously, with smoothly rounded transitions between movements.

All higher-level tasks are handled by Python code running on a PC.

When powered on, the arm first moves to its home position and then moves out of the camera's field of view. The software calibrates itself using the camera image and identifies the positions on the board. During the game, it watches the opponent's moves, calculates a response, and executes its own move.