Meet Adeept-Pi-Car aka Orion

ok first I will introduce you Adeept-Picar-B aka Orion. And I need to start with the Robot part first. I think for someone that will enter Robotics coming from software domain, is crucial to get familiar with the hardware part which is probably the unfamiliar and hence more difficult part.

And I must admit this the assembly of the robo, was the most difficult and most time consuming phase of this toy project. it took me 2 days to assembly and have the robot fully connected to the console to take control of it. But I think it was a necessary phase as I learned and understood the several components of the robot. Therefore, was easier to get started with the code as well

The important components

While there are several modules of the robot I will focus on the important ones that provide the basic functionality:

  • Drive motors -> Two DC motors that turn the rear wheels, controlled through Adeept's stock move.py driver.
  • PI Camera -> This provides the input for the Computer Vision and all the AI modules that we will use later.
  • Raspberry PI 4 (8GB RAM) -> Essentially the computing power of the robot. This is what powers the control loop, calling the actuators (motors, servos) and reading the sensors (camera, ultrasonic).
  • Servos (x3) -> Not just one "servo", there's a dedicated steering servo on the front wheels, plus a pan/tilt pair on the camera head. These are what let the robot turn its body and let the camera look around independently of the body.
  • Ultrasonic distance sensor -> Measures forward distance in centimeters. It feeds two things: the AI's own reasoning (e.g. "don't drive forward if something is closer than 25cm") and a separate, hardware-level safety watchdog that force-stops the motors if anything comes within 20cm , regardless of what the AI decides. This was the first moment it really hit me that "AI in control" still needs a dumb, deterministic backstop it can't override.

Software

Now we have our robot assembled. The natural step is to use a software to control the robot. I guess depending on the product/robot you buy , there is a specific software that is given to you to control the robot. In the case of the Adeept-PiCar-B, the code is a public github repo containing a web-server for the web UI where you can control the robot. This the code I used and built upon for my part of the code. Essentially what i added is a new folder (ai_control) that utilize the existing adeept code. There are two main components under this new folder, backends and brains.

  • Backends: this essentially is the service and the abstraction interface where the control of the robot (or mock robot) happens.It has functions such as drive, turn, look, stop, distance_cm (the ultrasonic reading) and capture_frame (the camera image).
  • Brains: The different AI control interfaces, the policy that decides what to do next. Importantly, a brain never touches the hardware directly: it only outputs a neutral action (drive, turn, look, stop, or "done"), and a single execute() function is the one place that translates that into real backend calls. That indirection is what lets me swap brains without ever touching the robot code itself. Today there are two working brains , an LLM agent (Claude, reasoning over vision + tool use) and a small trained VLA policy (pixels + instruction → action in a single forward pass, no network call), plus a third experiment fine-tuning a larger pretrained VLA model on the same data. The idea is that this brains folder keeps growing: any new kind of intelligence just plugs into the same interface.

Before I ever pointed this at the real robot, I built and tested the entire control loop against a mock backend, a small simulated 2D world running on my laptop, no hardware at all. It's the same idea as a local dev environment: get the logic right against a fake, then swap in the real thing unchanged. Only once that worked did I run the exact same code against the real PiCar.

Below is a diagram that conceptualized the architecture of the repo. Again, there are many brains (substrate independence theory) that drive the behavior of the robot. An abstract control backend of the robot. And two backends implement this. The real PicarBackend that control the real robot, and the Mock Backend that is used for testing purposes of the pipeline before the real execution.