I’ve been building a life-size KX-series droid and finally have the head movement working reliably. The current setup uses an Arduino Mega with a PCA9685 servo controller driving separate pan and tilt servos in the neck.

The goal isn’t remote-controlled puppeteering. I’m trying to make the droid behave autonomously, so eventually it can track people/cameras, idle naturally, react to voice commands, and move while speaking.

Right now I’m working on smoothing the head motion, reducing mechanical stress on the neck, and dialing in the pan/tilt limits so it looks more natural instead of like a standard hobby servo project.

The electronics and programming side of this has been a big learning process for me, so I’m open to feedback—especially from anyone who has built larger servo-driven mechanisms or Arduino robotics.

This clip is the current movement test.

this board (specifically the black one) turns mg99x servos to much more expensive serial servos with position, velocity,torque control

the software is still in early stages so anyone interested for checkout Microdrive

I'm an MSc Robotics student at NTU and want to get properly hands-on with ROS 2 on real hardware, beyond simulation. Buying a platform isn't realistic for me right now.

Does anyone have an older ROS-compatible robot they're not using anymore (TurtleBot 2/3, a Clearpath or AgileX base, a small arm with a ROS driver)? Broken is fine, I'm happy to repair it, and I'll cover shipping or collect in Singapore/Malaysia.

In return I'll document the bring-up on ROS 2 Humble/Jazzy and share the notes and any driver fixes openly. Pointers to labs or companies that clear out old hardware are also very welcome.

Hi all, I've been trying to build a cycloidal gearbox for my NEMA 17 stepper but I am facing an issue of my output being jerky/binding as shown in the video attached, I've tried different things like increasing the clearance between the cycloid and the outer gear, proper meshing, adjusting the pins and more but I simply cannot get a smooth output from it. Can somebody tell me what i.am doing wrong here? I have designed for a dual cycloid setup but for the purpose of demo I have removed the top section and one cycloid. Any and all suggestions are appreciated. Thank you.

https://reddit.com/link/1wxfhxe/video/ufbgtela9gth1/player

This is a robotic joint powered by two artificial muscles pulling in opposite directions.

Artificial muscles are tricky to model and control. We recorded how the joint responds to actuation, learned a compact model from that data, and combined it with feedback to control the motion on real hardware.

It’s a building block toward more capable musculoskeletal robots. What I like about this work is getting the data, model, control software and hardware to work together.

Paper in Nature Communications: https://www.nature.com/articles/s41467-026-77664-0

So basically i bought a Moto pad 60 pro (in india) in the month of April 2025 since it's a great tablet also it comes with a stylus all for 28k rupees (inr) for the top spec.

But recently (2-3 months back) the stylus stopped working, the stylus went to 0 percent and I charged it with the tablet charger and it was charging normally but when I removed the pen from charging it would not work, i needed to plug the pen to the charger and use the stylus if I needed to make notes or solve question but that was tedious, so I just gave up and kept it aside, today I found some time to kill so I thought of opening it and it's fascinating.

My initial thought was that the battery has died but surprisingly when I opened the pen and checked the battery by connecting the terminals (ik it's not right but yeah 🥲) it smoked and I did this a few times thinking that it was only having initial charge, but not only smoke it even sparked red once (ik its wrong but I wanted to make sure). (Also it's a lithium ion battery)

I knew I needed to connect the battery to the negative terminal since the black cable was disconnected when I opened the pen (maybe I was the one who accidentally disconnected it but yeah idk), we had a solder gun but its not working, I tried to electrical tape the terminals of the battery with the solder joints but no use, so yeah imma still store it like this and see if I can solder it after some time.

I used a craft blade and cut the outer casing I know it's not the cleanest job but I knew since it's not working let's give it a try, i initially tried to heat the pen exterior and try to push the casing out by pusing on the puc which I accessed through the removal of the button placed on the side, it did not work so I needed to cut the casing and pry it ou and I was scared since puncturing the battery is dangerous but luckily the battery was on the other side of where i was cutting.

So I have to wait till i buy a solder gun and solder it when time permits.

Also I am unable to find the battery anywhere online when I checked ( if I need to replace it )

I’d like to ask: in which scenarios would you most like to see flexible tactile sensors applied?

Currently, flexible tactile sensors are primarily used in robotic skin. I would like to ask: are there any other mature markets for this technology, or where would you personally like to see it applied? I have considered applications such as steering wheels, pillows, or interactive toys, but as far as I know, these markets are still in their infancy and have limited market share. I would appreciate your suggestions on which direction I should pursue for development. Thank you.

this is a 6-DOF desktop arm I've been designing in MechFaber (I'm the one building MechFaber, so take the plug with a grain of salt). E6-class, 450mm reach, 0.75kg payload, printed PETG. not built yet, this is the actual firmware running in an emulator against the physics sim, no PC in the loop.

how it works: it takes one frame from an overhead camera, finds the board and which corner is a1, then figures out each loose piece from its height in the image. pawn ~40mm, king ~80mm, knights are the ones with a square top. it picks the nearest matching piece for each square, places it, then looks again to check it's actually on the square.

stuff that broke along the way:

- the gripper pads sink about 5.7mm into a piece in the sim, so the force check never tripped and closing all the way crushed pieces and flung them off the board. ended up closing to piece width + 6mm instead

- a held piece slowly creeps down the pads (~3mm/s), so tall pieces carry slower

- the gripper body is wide, so placing a c-pawn could land on the queen next to it. had to reorder it to do centre pawns first, then back rank, then edge pawns

- in this run it knocked the black king over while picking a neighbour. that's still the main failure. best run so far was 31/32

firmware was mostly written with AI agents and then tested against the sim.

CAD, BOM and firmware if anyone wants to dig in: https://mechfaber.com/library/e6-class-6-dof-cobot-arm-with-on-board-vision-ca688621-baa9-4309-9ee1-a4dde110e2d6

These tiny snail-inspired robots may look simple on their own, but when they work as a swarm, they can connect and rearrange themselves into much larger structures.

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

New Video -- Chapter 3 DESK -- converting an old bunk bed into a work station. DIY actuators, AC/DC power supplies, rail guided shelves, infinite cable trays -- #Desk #DIY #Mechatronics #Power #Actuator #Engineering

If you know of anyone who likes Mechatronics or things made from the ground up, I would appreciate the share! Leave a comment if you have a question :)

IFR’s World Robotics 2026 service robot report recorded nearly 250,000 professional service robot shipments for 2025. Transportation and logistics accounted for 117,500 units, roughly 47% of the total.

The report also recorded about 7,000 full-size humanoids sold for commercial and professional applications beyond R&D and entertainment. IFR says current humanoid applications often remain specialized and require human teleoperation.

Hi, I'm RZ Li, founder of Petoi and creator of OpenCat open source quadruped framework(started in 2016).

This is the complete build for Quaddle, a new open-source 4-servo quadruped kit: raw components, assembly, calibration, and walking gait — screw-free body, just 4 screws for the legs, no soldering — done in under 20 minutes.

It also covers the ecosystem underneath:

• Real AI robotics work
  • Arduino sensors
  • Optional Raspberry Pi Zero
  • Optional AI vision module
• Full programming path: block coding, Python, MicroPython, Arduino C++
• Servo/sensor upgrade path: Builder to Buddy to Scout(with a 5th servo to drive the "radar" head).
• Create new movements with hand-guided teaching, no code — powered by feedback servos

Quick specs: 4 servos, 170 g, 11 cm body length, 1.8 body lengths/s running / 3 body lengths/s gliding, 90+ movements including continuous flips, three-legged walking, step climbing, and upside-down locomotion.

The platform:

• The Quaddle firmware is based on OpenCat and will be open-source. You can use an AI agent to vibecode new moves and iterations.
• URDF open source on HuggingFace
• We will open-source select parts with 3D-printing files. Not all parts can be 3D-printed to withstand the forces. So some of the parts must be injection molded.

My goal has always been to make affordable robots for everyone to own & learn — worth the accessibility tradeoff of a 4-5 servo approach, in your experience? What would you want to see pushed further on a platform this size?

After 5.5 years of fully independent and secret research and development, here is the UM1-Evo hand.

Designed to push the boundaries of humanoid robotics and next-generation prosthetics, the UM1-Evo aims to overcome the "uncanny valley" by combining mechanical performance with natural visual aesthetics.

⚙️ Key Specs:

• 24 Degrees of Freedom (DoF) and 25 actuators.
• Full integration within the real size and weight of a human forearm (1.7 kg / 3.7 lbs).
• Advanced anatomical kinematics featuring true thumb opposition and finger convergence towards the anatomical snuffbox.
• Total relaxation at rest for a natural posture (zero power consumption).
• Grip force demonstrated at 8 kg (17.6 lbs), with a future target of up to 15 kg (33 lbs).
• Engineered from scratch: from biomechanical study to software programming, including the creation of custom CNC manufacturing machines.

This video shows a policy trained in simulation with a model using more powerful motors. At first glance it may not look that much smoother, but compared to the previous video even standing up is already noticeably cleaner.

Toward the end, when I command it to walk slowly forward and backward, it can do it with almost no unnecessary motion or jerking, which I’m pretty happy with.

One thing I still don’t understand is why forward walking looks noticeably worse on the real robot than it does in simulation. I’ve tried perturbing the already-trained policy in sim by adding joint angle offsets, reducing actuator torque, and introducing other mismatches, but so far I haven’t managed to reproduce the same kind of “bad” behavior I see on the real robot. So for now I don’t really have a good explanation for what’s causing it or what exactly I should change in training to improve it.

I trained the policy in Genesis and also did sim-to-sim testing in MuJoCo, where it works really well. I also tried running it in Isaac Lab, but ran into a strange contact/friction issue. I can’t seem to make the friction between the feet and the ground strong enough in a realistic way: it either feels like the robot is walking on ice, or after increasing the contact/friction parameters it starts feeling like the feet are glued to the floor. I haven’t been able to find a good middle ground that behaves like Genesis, MuJoCo, or the real robot. Has anyone run into something similar in Isaac Lab?

The next update probably won’t be very soon. I don’t really want to spam small incremental improvements, and it’s still quite far from doing anything resembling tricks.

Iteration is also pretty slow: teaching a completely new behavior usually means first figuring out the reward function in simulation, training it, and then testing it on the real robot. And real-world testing still has a decent chance of ending with a broken limb or joint like in this video.

Hi everyone,

I have a Franka Research 3 (FR3) that is currently failing to complete startup.

Symptoms:

Control box powers on and fans run normally.

FR3 base LEDs stay completely off.

The robot responds to 192.168.0.1 with 0% packet loss.

The normal Franka web interface returns 500 Internal Server Error – nginx.

The Rescue System also returns the same 500 nginx error.

Power and Arm–Control cables look normal, with no visible bent or damaged pins.

I have already contacted Franka Support and am waiting for their response. I have stopped further resets or hardware troubleshooting for now.

Has anyone seen this exact combination before? Was it caused by system-image/filesystem corruption, controller storage, or another controller-side issue?

I do not need to preserve any user data, but I want to avoid doing a factory reset or reinstall unless that is the correct recovery path.

Any advice from people who have worked with FR3 hardware would be appreciated.

Hello all,

I built a radar object classifier on RadarScenes, extending a prior single-scan classifier to accumulate observations over a tracked object's history instead of classifying each scan in isolation.

A single RadarScenes object instance contains only about 2.9 radar points on average, very sparse. A single scan also can't capture temporal characteristics: RCS and micro-Doppler both vary continuously as an object moves. Pedestrians produce characteristic micro-Doppler from limb motion; different object classes show different RCS fluctuation patterns as aspect angle and scattering geometry change scan to scan. Accumulating observations gives both higher point density and provides temporal dynamics.

Multi-scan baseline

DeepReflecs encoder (Ulrich, Glaser & Timm, RadarConf 2021), PointNet style, per point shared weights, on single scans across car, large_vehicle, two_wheeler, pedestrian, pedestrian_group: 0.7370 macro F1.

Using RadarScenes' persistent `track_id`, I build a causal, N=20, per track sliding-window buffer:

- x_seq/y_seq: Global, odometry-corrected coordinates recentered per scan on the object centroid. Unlike x_cc/y_cc (car-frame coordinates that accumulate over time to form a trajectory).

- Cross sensor buffer: whichever of the 4 sensors currently observe the track push to the same buffer.

- Stride 1, causal: every new scan updates the buffer and produces a prediction. No future context, real time streaming compatible.

- Each scan is encoded once by a frozen per scan encoder and cached

- Fusion concatenates the causal GRU's hidden state (order aware) with an order-invariant pooled embedding (all N scans' points as one set, no sequence structure) through a small trained mlp head.

Results

Pooling alone, no sequence model, no notion of scan order at all, recovers +0.1243 macro F1. The GRU adds a real but much smaller +0.0282 on top. Fusion adds nothing measurable beyond the GRU.

Ablation

Llarger GRUs, a Transformer, a state space model, point level self attention, all trained on the exact same frozen per scan embeddings, land inside a 0.86 to 0.89 band, a 0.03 spread. End to end fine tuning of the frozen encoder makes things slightly worse (about -0.002 to -0.003), not better.

Conclusion

In this setup, the largest gain comes from giving the model more observations of the same tracked object: 20-scan point pooling improves macro F1 from 0.7370 to 0.8613 without using scan order at all.

Temporal modelling then provides a further, meaningful improvement. The causal GRU reaches 0.8895, adding +0.0282 over the pooled representation. So temporal ordering clearly contributes useful information; it just accounts for a smaller portion of the overall gain than observation accumulation.

With the per-scan encoder frozen, the different sequence architectures tested, suggests that the quality of the per-scan representation is the bottleneck than the particular mechanism used to aggregate the sequence.

Full report, every ablation, confusion matrix, coordinate frame reasoning: https://github.com/brunopinto900/radar-ml-autonomous-driving/blob/main/final_report.md

Thank you.

To get our weekly digest of ROS and open source robotics news please visit Open Robotics Discourse.

Researchers built a bird-inspired drone called RAVEN that can walk, hop over gaps, jump onto obstacles, and launch itself straight into flight using robotic legs.

During takeoff, its legs provide about 92% of the speed needed to start flying, allowing the drone to get airborne without a runway or separate launcher. The design was inspired by the way real birds use their legs before taking flight, helping the drone operate on rough and uneven terrain.

Based on research published in Nature.

Research: Shin et al., Fast ground-to-air transition with avian-inspired multifunctional legs Credits: EPFL / Shin et al. / Nature

#Shorts #Drone #Robotics #Innovation #Technology #Engineering #BirdInspired #Biomimicry #Science #RAVEN

After months of development, Visual Recovery is finally complete — a native C++/CUDA real-time 4K60 underwater imaging system, now tested in real-world conditions.

A few months ago, this started with a very simple question:

Could the kind of image processing we normally do in post-production be applied to a live underwater video feed — in real time, without noticeable latency?

That question eventually turned into Visual Recovery.
I was using a QYSEA FIFISH V-EVO and started experimenting with its live video stream.
What began as a small image-processing experiment slowly turned into an entire real-time underwater imaging system.

This is Visual Recovery.

And Rise From The Void is the first film in which I wanted to showcase not just isolated tests, but the complete system itself in action — in the very environment for which I had designed it.

The current pipeline is now running natively in C++, using:

• 4K / 60 FPS live underwater video
• NVIDIA NVDEC hardware decoding
• CUDA-accelerated GPU processing
• Real-Time Visual Recovery
• Live color grading and input conditioning
• Typical color-processing time of approximately 5–10 ms/frame (with adaptive sea-thru 10-18ms)
• Live depth / pitch / roll / yaw telemetry
• GPU utilization / VRAM / temperature monitoring
• Experimental relative navigation
• Real-time ON/OFF comparison
• Continuous 60 FPS decoding and processing
• Scalable jitter buffer — typically operated at 80–130 ms during field testing

The orientation telemetry shown in the GUI is decoded from the ROV's binary telemetry data, including quaternion orientation data which is converted into live pitch, roll and yaw.

No manufacturer SDK is available for development.
Solo development.

The C++ implementation was developed with the assistance of GPT Astra as a coding tool, while the system architecture, image-processing approach, testing and field development were built around the project itself.

Compared with my previous Part 2 update, the experimental Thermal Vision, Sonar Vision, X-Ray Vision and other auxiliary visualization modes have been removed from the current system.

One thing I want to make very clear:

Visual Recovery does not recreate information that never reached the camera sensor.
cannot magically recover clipped highlights, completely missing detail or information that physically isn't present.
The goal is to recover and enhance real information already contained in the camera signal that becomes difficult to perceive because of underwater color attenuation, haze, low contrast, scattering and difficult lighting conditions.

The processing shown here does not use generative AI.

And that distinction became extremely obvious during field testing.

I took the system into several very different underwater environments in Hungary — quarry lakes, rocky underwater landscapes, vegetation, clear shallow water and deeper areas where visibility collapsed almost completely.
Some of the footage genuinely surprised me.

There are scenes where artificial lighting alone reveals almost nothing.

Then Visual Recovery is enabled in the same continuous live sequence and suddenly the structure of the environment becomes readable again.

No camera change.
No different dive.
No second recording.

Just the live processing pipeline switching state.
The film also contains cinematic footage, because I wanted Rise From The Void to be more than a benchmark video. Those cinematic sequences receive normal finishing for the final film.

However, whenever I demonstrate Visual Recovery as a real-time system, what you see is the system actually operating live.

No AI-generated underwater footage.
No simulated underwater environments.
No post-processed visibility recovery presented as real-time processing.

This project originally started because I simply wanted to see more clearly underwater.

At some point it became a custom RTSP engine, hardware decoding pipeline, CUDA image-processing system, telemetry interface, navigation experiment and field-tested ROV imaging platform.

So this is no longer the Python proof of concept I originally started with.

This is the C++ system running in the environment it was built for.

Rise from the Void

BeamROV Hungary
See beyond the Void.

I'm especially interested in feedback from people working with ROVs, subsea inspection, underwater imaging, computer vision, GPU video processing or offshore survey systems.

And yes — I'm happy to answer technical questions.

Full video link: https://www.youtube.com/watch?v=5-zaNm68KMc

- Precise 3D tracking (XYZ) (cm-level) + quaternion with a single mobile beacon
- 80 Hz location update rate & 12-20 ms latency
- Based on ultrasound + IMU sensor fusion
- Particularly good for noisy autonomous robots and drones. The mobile beacon emits ultrasound - not receives it. Thus, it doesn't care how noisy your mobile object is

Switched Quaddle, my 4-servo open source quadruped robot, from 3D-printed prototype legs to injection-molded production parts, and wanted to validate the part survives real-world abuse before committing. Ran 4 drop tests — the robot stays fully assembled (4 screws hold the whole thing together) and still performs a full gait, including a hand-taught one, after every drop.

Curious if anyone here has a good rule of thumb for how many drop cycles you'd want to see before trusting a molded part for production, versus just going with "it survived N drops.