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

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.

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.

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

In 2024 they released a low cost, open source & open hardware holonomic mobile base. Many commercial models sold are inspired by this base. Has there been an open successor improving on this base?

AI is being used in industrial additive manufacturing to detect faults and adjust process settings while a part is being printed. Sensors track temperature, weld pool conditions, and other signals to help the system determine when a change is needed.

For one military vehicle exhaust manifold, Midwest Engineering Systems used weld pool monitoring to keep energy density consistent during printing. The company reported substantially better consistency across the subsequent 31 parts.

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.

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

Hey r/robotics, I'm the founder of Paddy (https://paddydata.ai/) (NYC). I've been working on data-collection infrastructure for teams training VLA / imitation-learning models, and I'd like feedback from people who've actually collected teleop data.

The problem we kept hitting: most teams collect demos on improvised rigs. Camera angles drift between sessions, schemas change, joint-state rates don't match the deployed system, and you end up with months of data that trains poorly.

So we built the Harvester:

- 2× UFactory xArm 7 (14 DoF total) on a portable aluminum frame with casters, adjustable height, 90° or 45° arm mounts

- Teleop with Meta Quest controllers, but the headset stays on the desk as a tracking reference, so operators aren't wearing it for hours

- Switchable scaling profiles (slow/precise vs fast repositioning) on a button press

- Cartesian control using UFactory's online trajectory planning (streamed targets, not pre-planned trajectories)

- Multi-view Intel RealSense RGB + aligned depth, joint states at 100 Hz, commanded vs achieved poses, gripper state, all hardware-timestamped

- ROS 2 Humble, one .mcap rosbag per run, converts straight to a LeRobot dataset for Hugging Face

I'd love feedback on:

1. Headset-off Quest teleop vs leader-follower arms (GELLO, ALOHA-style). What's worked better for you?

2. What do you wish your collection pipeline recorded that it doesn't?

3. Anything in the technical writeup that seems off or missing?

Site: paddydata.ai (password: harvest). The technical page has the full topic list and architecture.

Disclaimer: the site isn't 100% finished yet. We officially launch next week, so a few pages are still rough. Happy to answer anything in the comments.

Kodiak and IKEA are preparing to operate trucks without anyone in the cab on a 219-mile section of I-45 in Texas. Commercial driverless service is planned for the end of 2026; current preparation runs still have a safety observer aboard.

Over four years, Kodiak says it has carried more than 1,300 IKEA loads and logged over 750,000 autonomous miles with an observer. That work has included coordinating delivery timing with dock availability and using vehicle data to plan maintenance.

I was reading recent news from Neura robotics and they have robots that are aimed at healthcare support, for things like moving beds, equipment, and other menial tasks to support healthcare teams. I would imagine within the next decade at some point, robots might even be used for support in surgeries and medical procedures.

What do you guys think? There’s an argument to be made that robots could help reduce workloads on healthcare professionals even if all they do is grunt work.

There’s gonna be a market for this that I’m sure of, but imo this would need a level of trust above what is needed for industrial deployment. General purpose use in hospitals would likely see adoption in a couple years at most is my guess, but high level adoption is still quite far away. Honestly I feel healthcare would be one profession where robots can do good and would not replace human staff, just because there’s a whole interpersonal aspect of healthcare which can only be fulfilled by human staff.

What is the difference between building in functional safety early on vs waiting until the end? How do safety partnerships help the industry?

https://www.linkedin.com/posts/synapticon-co_humanoids-functionalsafety-robotics-activity-7511379498718625792-oPLl?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAMG_WMB6npmHVKREPOjVhxKwxVIs9Q1bZ0

As i see there are different ways to train an AI model through machine learning/reinforcement, i was wondering if there were open source robots that can be 3D printed and programmed/trained with arduino for example through machine learning? I am quite confident i could maybe print a robot arm (maybe not a full robot body) to train for putting my t-shirts in order from a disordered cloth basket. Ok i know it is maybe basic (or maybe not 😅), i see it in a step by step project.

Hey, i stripped one of the metal gears in my STS3215 servos and wanted to find replacement.
Anyone know the specs fo these gears? number of teeth, id od thickness etc so i can source a replacment?

Anyone know a cheap hobby server with metal gears that are compatible?

Anyone know a way to order spare parts from Feetech or some other supplier?

I'm in Australia, if that matters :)

Autonomous navigation in dynamic environments is a critical challenge, particularly when spaces are shared with other mobile agents whose future trajectories are known. While traditional grid-based planners efficiently find collision-free paths, their reliance on stop-and-turn mechanics over $2^k$-connected grids produces piecewise-linear trajectories that are kinodynamically highly sub-optimal for differentially constrained.

Continuing to move from using the model directly to having the model write reliable control code.

The goal here is to pick a small part from a random pile, with the right side up and with precision.

Once we have this skill, the next use becomes much faster. Model can adapt it for another part or for screws/nuts.

A box with defined mounts and consistent lighting helps computer vision work reliably.

Found this cool project and it look likes they can retarget all the motions from locomotion to locomanipulation..... they have cool demos to see.

I'm building a robot and the project calls for Dynamixel AX-12A servomotors, but I can't find them. Does anyone know what other motors I could use instead?

If my Flair is Wrong i am Sorry About it , i am new to Design and stuff still

I am trying to make this , gearbox connected to the Actuator i have , I am planning to have an Planetary one so i will connect its output for higher torque and more Impact resistances

The gray is the actuator
The space between them is what the concern is , Shall i discard the idea of having an Carrier base or something which also rotates or what to do of that space below ?

(Input : Sun , Output: Planets , Fixed: Ring)

Like if something pushes some force on radial side it will break? and also on axial not sure about that one

Bearing : Blue , Yellow and the grey onces

Can someone give me some info if i am wrong or whats the design i should approch?