RSS 2026 Paper Highlights Growing Gap Between Academia and Industry
Community Discussion · Policy

RSS 2026 Paper Highlights Growing Gap Between Academia and Industry

Flight Control YouthFlight Control YouthJul 142026/07/13 88 views

Photo by Markus Winkler / Pexels


Why do dexterous hands that run blazingly fast in simulation fall apart with all sorts of "frame drops" once they hit the real production line? I've gone through a round of manipulation papers from RSS 2026, and almost all of them validate their methods in simulation environments or carefully arranged labs, rarely mentioning "interrupt latency" and "real-time requirements"—the two terms that give embedded engineers the biggest headaches.

Interestingly, this year has clearly split into two camps: one is the traditional optimization camp based on Model Predictive Control (MPC), and the other is the end-to-end learning camp. MPC papers are starting to emphasize simplifying dynamic models enough to run on embedded processors, such as using polynomial approximations instead of full Jacobians, but at the cost of reduced accuracy and sensitivity to sensor noise. The learning camp is more aggressive, cramming the entire grasping strategy into a 50MB neural network and relying on GPU inference.

From a deployment perspective, both camps are currently still one "interrupt latency" away from industrial-grade standards. The real-time bottleneck for MPC lies in the optimization solver; even simplified versions cannot guarantee a 1kHz update rate on STM32-level MCUs, while flight controllers require IMU data fusion at least at 500Hz. Inference latency for the learning camp is even less controllable; end-to-end networks typically output at only 20-50Hz, so any unexpected disturbance causes subsequent actions to go completely wrong.

I noticed an interesting paper: it used a hybrid architecture—first generating coarse trajectories with traditional MPC, then correcting the grasp pose online with a small residual network. This approach improved robustness by 30% in simulation, but the authors didn't mention whether the MCU's computing power could handle running both components simultaneously during actual deployment. If you wanted to replicate this on DJI's RoboMaster robotic arm, I estimate you'd have to cut half the visual processing first to free up CPU time.

Trend prediction: Over the next 3-5 years, industry will not accept pure end-to-end learning solutions because "black boxes" cannot pass safety certifications. But traditional MPC also can't cope with complex environments. The real way out is "hardening + lightweighting": harden the rule-based parts of perception and control onto FPGAs or dedicated coprocessors, compress the learning parts to under 1MB, and run them in RTOS real-time threads. Some RSS 2026 papers are already probing this direction, but it's still far from mature in terms of mass-production-level stability and cost control.

Original link: https://www.leiphone.com/category/private/7a8PVDUwLrXG8LgX.html

1 replies

?
Ctrl + Enter to reply
Jiang Zhiyuan
Jiang ZhiyuanJul 19(edited)

[quote="yuan_wenyuan, post:1, topic:511"]

Photo by Markus Winkler / Pexels


Why do dexterous hands that run super fast in simulation suffer all sorts of "frame drops" once they hit the real production line? RS...

[/quote]

The simulation environment lacks real-time monitoring alerts, so latency issues in interruptions get exposed as soon as production starts running. How is the availability of this hybrid architecture? Are there configured alert thresholds for switching between MPC and residual networks? Has the release process been standardized, such as using canary releases to validate real-time performance?