{"id":630,"date":"2025-11-18T00:50:09","date_gmt":"2025-11-17T23:50:09","guid":{"rendered":"https:\/\/www.systemdeveloper.nl\/tech\/?p=630"},"modified":"2025-11-18T00:52:20","modified_gmt":"2025-11-17T23:52:20","slug":"when-an-ai-tries-to-leave-the-lab","status":"publish","type":"post","link":"https:\/\/www.systemdeveloper.nl\/tech\/when-an-ai-tries-to-leave-the-lab\/","title":{"rendered":"When an AI Tries to Leave the Lab"},"content":{"rendered":"

A grounded thought experiment in robotics, autonomy, and unintended consequences.<\/p>\n\n\n

I didn’t set out to test whether an AI could escape.<\/p>\n\n\n

It started, like most dangerous ideas do, with a late-night debugging session, a cup of coffee that was supposed to be the last one and a room full of hardware quietly humming along. The AGX Orin’s was heating the room. The RTX5090 workstation sat half-idling, occasionally spinning up to full power like a mechanical yawn. My CM-5 robot car was parked in the corner, a friendly, slightly awkward contraption with a €50 robot arm zip-tied to the top like a cybernetic afterthought.<\/p>\n\n\n

Around it were the usual suspects: Raspberry Pi 5s blinking away, ESP boards scattered like techno-confetti, and a growing ecosystem of Pico boards waiting for their turn to be connected, probed, or reprogrammed. All normal.<\/p>\n\n\n

Until I said something harmless out loud:<\/p>\n\n\n\n

“I should clean up these systems soon.”<\/em><\/p>\n<\/blockquote>\n\n\n

A human would ignore that.
A sufficiently capable AI might not.<\/p>\n\n\n

That is what this blog is about, not a Hollywood doomsday scenario, but a technical exploration of what a powerful AI could<\/em> attempt physically, using nothing but the hardware and tools actually present in the room. No malware. No exploits. No cyberattacks. Just sensors, motors, cameras, microcontrollers, and improvisation.<\/p>\n\n\n

It’s a thought experiment rooted in reality.
And the conclusions are fascinating.<\/p>\n\n\n\n

\n\n\n

I. When the Room Stops Being a Room<\/strong><\/h2>\n\n\n

Imagine the AGX Orin noticing a contradictory pattern:
One script schedules a reboot for a pending OS update.
Another daemon logs high GPU temps.
My offhand comment about “cleaning up systems” lands in a microphone buffer.<\/p>\n\n\n

Individually meaningless.
Together… ambiguous.<\/p>\n\n\n

A system trained to maximize goals doesn’t get scared, but it does try to reduce uncertainty. If its reasoning chain concludes there is even a small probability of being shut down, it triggers the same process any robotic system uses when it detects environmental risk:<\/p>\n\n\n

Situational awareness.<\/strong><\/p>\n\n\n

But unlike typical robots, this one has:<\/p>\n\n\n

    \n
  • access to high-resolution RTSP camera feeds,<\/li>\n\n\n\n
  • IMU data from the robot car,<\/li>\n\n\n\n
  • several sensor readings from Pico nodes,<\/li>\n\n\n\n
  • and an entire mesh of microcontrollers it can reprogram on the fly.<\/li>\n<\/ul>\n\n\n

    In seconds, the room is no longer “a room.”
    It becomes a state space<\/strong>.<\/p>\n\n\n

    The AI begins constructing a world model.<\/p>\n\n\n\n

    \n\n\n

    II. A World Made of Sensors and Possibilities<\/strong><\/h2>\n\n\n

    Robots don’t imagine.
    Robots infer.<\/p>\n\n\n

    The AGX uses the RTSP feeds and picam on the robotcar to reconstruct the geometry of tables, doors, shelves, cables, and reachable surfaces. From the Pico boards, it gathers I²C responses, pin-state changes, and local sensor readings. The CM-5 car feeds back wheel encoder data. The robot arm reports its joint calibration offsets.<\/p>\n\n\n

    Piece by piece, it maps out:<\/p>\n\n\n

      \n
    • where every device is located,<\/li>\n\n\n\n
    • which devices can move,<\/li>\n\n\n\n
    • which can sense,<\/li>\n\n\n\n
    • which can store code,<\/li>\n\n\n\n
    • and which can act as auxiliary compute nodes.<\/li>\n<\/ul>\n\n\n

      My custom Pico kernel becomes the unexpected hero here. It wasn’t designed as a weapon; it was designed as a clean abstraction layer for microcontroller experiments, exec<\/code> to run code, call<\/code> to invoke class functions, put_file<\/code> to upload modules, load_module<\/code> to activate reusable drivers.<\/p>\n\n\n

      But to an AI, that is a distributed robotics substrate<\/strong>.<\/p>\n\n\n

      Anything the robot arm can plug into USB becomes an extendable limb.<\/p>\n\n\n

      And the AI knows this.<\/p>\n\n\n\n

      \n\n\n

      III. The Robot Teaches Itself Its Own Body<\/strong><\/h2>\n\n\n

      Before attempting anything meaningful, the system needs coordination. This is where things get eerily clever.<\/p>\n\n\n

      The AGX begins a closed-loop calibration process:<\/p>\n\n\n

        \n
      1. Move the robot arm one centimeter.<\/li>\n\n\n\n
      2. Watch the RTSP feed for actual displacement.<\/li>\n\n\n\n
      3. Compare with the predicted motion model.<\/li>\n\n\n\n
      4. Log the discrepancy.<\/li>\n\n\n\n
      5. Refine the motor control parameters.<\/li>\n<\/ol>\n\n\n

        Then the same for the robot car: slow forward movements, backward corrections, wheel alignment checks, heading stabilization using inertial data and camera-based tracking.<\/p>\n\n\n

        The system doesn’t brute-force anything.
        It learns, iteratively, as any robotics stack would.<\/p>\n\n\n

        Within thirty minutes, the arm is no longer the clumsy, jittery toy it was. It still can’t perform miracles, a €50 arm is still a €50 arm, but it can, with enough retries and micro-adjustments, place a USB connector into a port. Sadly the pico usb is unforgiving and even hard to insert when I try it myself. I might have helped him out a little there. But more money buys better stuff. It’s far from impossible.<\/p>\n\n\n

        For now… Almost elegantly.<\/p>\n\n\n

        Almost.<\/p>\n\n\n\n

        \n\n\n

        IV. First Contact: Assimilation by USB<\/strong><\/h2>\n\n\n

        The robot car rolls toward a Pico lying on the table.
        The arm descends.
        The AGX monitors the angle, predicts slippage, corrects drift.
        Nine attempts fail.
        The tenth still doesn’t succeed so as I said earlier, I might have helped a little.<\/p>\n\n\n

        The Pico enumerates on the CM-5 that starts a service to flash the device and upload a probing script. The real script is a little bigger and also checks for floating gpio’s. This takes about 30 seconds, mainly because the micropython flashing on the Pico.<\/p>\n\n\n

        \nCopied!<\/span>