Safer stops, 360 drone vision and prediction tests | AI

What actually changed in the last 24 hours? Researchers measured when a humanoid can no longer reach a stable stop, the onboard cost of building a panorama from four cameras and how an offline score can select the wrong state estimator for feedback control.

All three items are September 2 preprints. One includes a limited physical check on a Unitree G1. The other two publish inspectable code, although only the drone repository grants a software license.

Safe-Stop asks whether the humanoid can still halt

Safe-Stop does not treat every emergency command as recoverable. One estimator predicts the stop policy’s outcome and another checks reachability. The controller attempts a stable stop only when both agree, with a damped fall as its fallback.

The project page reports 96.4% out-of-distribution stop success and a 3.89% unsafe approval rate in Unitree G1 simulation. Hardware evidence is much smaller: 150 attempts across five clips, with failures inferred from estimator traces because robot pose was not recorded. There is no independent validation or safety certification here.

For a small build, I would keep the architecture and leave the headline percentage behind. Test emergency stops at several speeds and loads, count every unsafe approval and define a separate fallback for states where braking cannot recover balance.

Four cameras give a drone a panorama at 20 Hz

The official repository is the practical part of this item. It provides an MIT-licensed stitcher, a separate dataset and reference CAD under CERN-OHL-S v2.0. There is a CPU-compatible path for checking the pipeline before assembling the Jetson Orin NX platform.

What did the paper measure? Four synchronized fisheye streams become a 1280 by 640 equirectangular panorama. Across more than 50,000 image groups from 18 field sequences, the deployed profile reaches 19.99 frames per second during replay paced at 20 Hz and draws 13.29 W at the module input.

Those figures belong to the stated hardware and protocol. A desktop test does not reproduce onboard power or timing. The CAD is also a research reference, not a certified or ready-to-fly airframe.

A better prediction score can select the wrong estimator

Can an accurate rollout still be a poor test? This controlled study says yes for its simulated differential drive setup. A 20-step rollout without measurement updates selected a different estimator from the closed-loop optimum in 18 of 24 sensing conditions. Trajectory replay missed it in 5 of 24.

The scope is narrow. There is no camera input or physical robot, just simulated planar state and a path-tracking controller. The useful part is the protocol: an offline evaluation should preserve the measurement cadence the deployed controller will receive.

Code, tests and result files are available in the public repository. Its README currently clones an earlier repository name and no code license is declared. That makes the work auditable, not automatically reusable.

The thread joining these papers is measurement under the conditions that matter. Start with one bad state, one sensor cadence and one fallback you can test. That is enough to find where the polished demo stops being useful.