Robot ID cards, weight space and drone noise

Beijing wants a readable identity on every robot built in China, ros2_control just changed the interfaces hardware plugins depend on, and a Gazebo experiment shows a controller can be authored as weights instead of code. Also this week: streaming training, an embedded protocol, and drone noise at the zoning board.

China drafts one lifetime ID per robot

The Ministry of Industry and Information Technology opened draft measures for comment on 6 November that would give every complete robot made in China a lifetime identification code, fixed by the maker before the robot leaves the factory (MIIT notice, draft text).

It covers industrial, service and special purpose robots. One machine, one code, stored digitally and marked in forms people and machines can read. Makers register each product, including key components and software, on a ministry platform and file every code within 20 working days. Users could look up those records, and robots shipped earlier only need their serial numbers filed. The draft is silent on imports, fees and penalties, comments close on 5 December, and the effective date reads 202X (Asia Tech News).

The volume explains the interest: 794,781 industrial robots built from January through September 2026, up 29.1 percent on the year, and more than 28,000 humanoids already carrying a 29 character code under a separate standard.

Identity therefore becomes a record with lineage attached. If the platform exposes a query interface, and if component registration reaches third party parts, fleet managers gain a provenance path for recalls and firmware.

ros2_control marks Lyrical Luth stable

The ros-controls maintainers marked Lyrical Luth stable and released in ros2_control, ros2_controllers, control_toolbox and realtime_tools on 6 November, and the announcement opens with the breaking changes (ROS Discourse, repository).

The handle and export APIs deprecated since Jazzy are removed. Hardware components no longer implement export_state_interfaces() and export_command_interfaces(): interfaces are built from the <ros2_control> tag, and values arrive through set_state/get_state and set_command/get_command. Interfaces can no longer be built from a double*, because handles own their value.

Other changes surface later. switch_controller is strict by default, configure_controller accepts only unconfigured controllers, and a failing controller deactivates its whole chain, backported to Jazzy in 4.39.0. Update rates are rounded to the nearest achievable rate, backported in 4.41.0.

The additions are float32 and sized integer handles, INDIVIDUAL_BEST_EFFORT and REGEX interface claiming, a MagneticFieldSensor component, a cleanup_controller service, and a handle_exceptions parameter. Vendor plugins written for Humble or Kilted need migration work, and the activation state machine is worth re-reading in our guide to lifecycle nodes.

A navigation controller written as 738 weights

A ROS Discourse project asks whether directly authored network weights can produce useful navigation behaviour, with no training run behind them (ROS Discourse, write-up).

Two rooms, a doorway and a lidar equipped robot in Gazebo. The network is a 26 by 16 by 16 by 2 tanh MLP with 738 stored coefficients and biases, 78 nonzero in the final version, mapping reduced lidar readings to speed and steering. No map, planner or LLM call sits in the steering loop. The author says Fable 5.1 wrote and revised the weights after a weight-space programming essay, with no gradient based training, only iteration guided by activation traces when a doorway run failed.

Scan processing, command safeguards and a pose based lane scheduler stay ordinary code, and the three lap mission uses Gazebo true pose for lap closure. That split is the same one our Nav2 explainer describes from the classical side: learned reactive motion, guarantees outside it. It is simulation only, with a real robot run next.

LeRobot 0.7 trains without downloading the data

LeRobot v0.7.0 shipped on 5 November, and the number that matters is storage: almost 300 TB of open Physical AI data in LeRobot format on the Hub, trainable in place from the Hub, a storage bucket or LanceDB without a local copy (Hugging Face).

The stack was rebuilt for multibillion parameter world action models with FSDP2, HSDP, distributed checkpoints, FP16, EMA and Trackio. Four world action models join (Cosmos 3, Long-WAM, FLUX 3 Action, LaWAM) alongside four vision language action policies (G0.5, LingBot-VLA 2.0, DM0.5, Wall-OSS-0.5). Interactive rollouts let an operator switch subtasks or ask the policy what it sees without stopping the robot. lerobot-policy-server moves inference to a remote GPU, and the Unitree G1 gains NVIDIA’s SONIC whole body controller.

The streaming dataset path attacks the bottleneck our data refinery piece treats as the real cost: moving and curating episodes before training starts.

Proton shrinks the link to embedded boards

Clearpath published a write-up of Proton, a transport agnostic protocol for the microcontrollers inside a robot, presented at ROSCon 2026 by Tom Wallis of OTTO by Rockwell Automation (Clearpath, repository, ROS 2 bridge).

It sits on Protocol Buffers but swaps per device schemas for signals grouped into bundles, with a signal registry holding the latest value so a node queries state instead of chasing messages. No dynamic allocation by default, no RTOS, a CMake package with no protobuf dependency, over Ethernet or serial, plus a ROS 2 bridge that maps YAML bundles to topics through generated plugins.

The benchmark ran an ESP32 with simulated IMU data at 100 Hz against micro-ROS, Zenoh Pico and EtherNet/IP: a library about 12 times smaller than the next largest, about 30 times smaller than micro-ROS, about 22 times lower static RAM, and roughly 50 percent fewer packets than the average of the tested protocols. Those are presenter numbers on one board and one workload, and the talk does not claim it replaces DDS or Zenoh. The architectural point stands: standard interfaces at the boundary, a cheap wire inside the robot.

Drone delivery noise reaches the zoning board

IEEE Spectrum reported on 4 November from a Baton Rouge neighbourhood where Amazon Prime Air began flying MK30 drones in August from a distribution center 3.2 kilometres away (IEEE Spectrum).

The FAA environmental assessment for the site describes operations from 6 a.m. to 10:30 p.m., 1,000 daily deliveries, 100 of them in the early and late shoulders. One resident counted a drone every 48 seconds on a Saturday morning. A councilman says Amazon rerouted 70 percent of flights after the outcry.

The airframes differ: the MK30 weighs almost 36 kilograms, Wing’s largest drone is under 11 kilograms with payload, and Wing and Zipline lower packages on a tether so the aircraft stays higher. Amazon serves about 85 US municipalities and plans 500 by the end of 2026, Wing targets 270 US hubs by the end of 2027, and Uber and Zipline aim for 1 million deliveries a day by the end of 2029. Fifteen states and Harris County, Texas, sued the FAA on 28 September over environmental review rules for drone sites, and Cobb County, Georgia denied Wing a zoning request in April.

For aerial fleets, acoustic signature, approach altitude and hub siting are engineering constraints on the level of flight time. Acceptance decides whether a route exists.

Quick Bites

• A Zenoh plus RaptorQ prototype targets rovers on lossy links, using RFC 6330 fountain codes so bulk map transfers reconstruct without retransmission round trips, a 128 kbps token bucket by default, and signed commands that bypass background traffic (ROS Discourse).
• Lopsy is a ROS 2 workspace for a rod driven NiTi continuum robot aimed at steering chest catheters, including a C++ solver that maps rod tensions to joint angles with friction and bending stiffness (repository).
• LX Pantos is testing rack climbing warehouse robots with South Korean and Chinese partners, and says one cosmetics client cut warehouse space by about 30 percent after adopting robot storage and picking (Asia Tech News).
• The ROS 2 image pipeline still has no dedicated maintainer, and the weekly ROS news asks for someone to take over image_transport and point_cloud_transport, with mentoring from peci1 (ROS Discourse).