RoboCup 2027 moves to a separated MCU/Linux engineering architecture

The V2027-01 baseline separates MCU safety/navigation from Linux perception and observability, keepsArduino EFBusas transport authority and leaves Race fail-closed pending hardware qualification.

Why separate the two computing layers?

The rescue robot must keep essential motion, safety and navigation behavior under MCU authority even when a Linux application is delayed, disconnected or being tested. Linux can perform perception and higher-level analysis, but it is not a replacement for deterministic low-level control. This separation also makes test evidence easier to interpret: one can qualify the motor-control path without implying that an AI model or perception pipeline is already race-ready.

The V2027-01 architecture is an engineering baseline, not a fully qualified competition release. Its transport depends on Arduino EFBus, and the race capability remains gated by physical tests. Read theRoboCup Junior Rescue Maze projectandArduino EFBus projectfor the longer-term context.