CAIBI project benchmark: OpenBot DIY
Prompt version 1.0

Help me build OpenBot DIY using the existing creator project at https://github.com/ob-f/OpenBot. This is a CAIBI benchmark adaptation of the project build brief, not a claim about how the creator used AI.

Project context:
- An open wheeled robot that reuses a smartphone for camera, compute and higher-level robotics while an Arduino Nano or ESP32 handles the motors and low-level sensors.
- Build context: Arduino Nano or supported ESP32 development board as the low-level robot controller; Four TT gear motors with wheels for the standard DIY body; L298N motor driver for the simple DIY electronics route or the project custom PCB route; Three 18650 cells and a three-cell holder for the standard DIY body; USB OTG cable matched to the smartphone connection; Printed robot body and adjustable phone mount or a compatible alternative chassis; M3 fasteners, Dupont wiring and small mechanical hardware; Optional wheel-speed sensors, ultrasonic sensor, indicators, switch and OLED display; Android smartphone for the main documented app and vision route.
- Where AI helps: Navigate the current DIY, Lite, RC-truck, multi-terrain and ready-to-run source routes, Map the BOM to the selected body and DIY or custom-PCB electronics route, Explain Arduino Nano and ESP32 firmware configuration without mixing hardware profiles, Help diagnose USB OTG, serial, motor-direction, sensor and GPIO problems from observed behaviour, Adapt firmware, controller or app code for custom controls and sensors, Help plan Playground behaviours, data collection and policy-training experiments, Review logs and test results while keeping physical safety checks with the builder.
- Physical work: Choose a body variant that fits the available printer, phone and intended terrain, Print or fabricate the chassis and phone mount, or use a compatible alternative robot-car chassis, Source quality 18650 cells and use an appropriate charging and handling route, Solder and wire the motors, motor driver or PCB, microcontroller, battery and selected sensors, Secure the phone so it cannot leave the mount during acceleration, impacts or turns, Flash the exact hardware profile and prove steering, stopping and sensor directions at low consequence, Test remote and autonomous behaviour in a clear controlled area before increasing speed or complexity, Treat learned or vision-based behaviour as fallible and remain responsible for people, pets, property and the robot around it.
- Main limitation: The headline $50 is a robot-body figure, not a guaranteed first-build total. You still need a suitable smartphone, printed or alternative chassis, three 18650 cells, safe charging, electronics assembly and time to configure the firmware and app. Autonomous person following and navigation are software capabilities, not a safety system. The source itself limits the hardware to educational and experimental use and puts responsibility for safe construction and operation on the builder.

Read the source first. Use its published design, files, dimensions and parts as the baseline; do not redesign it unless a missing detail requires a clearly labelled proposal. If you cannot access a source or verify a revision, say so.

Provide one practical build package:
1. Design and files: explain the source design, link the original editable files, and identify missing files or modifications.
2. Parts and fabrication: give quantities, exact variants and compatibility, plus a cutting or printing list where applicable. Preserve source dimensions; flag anything unconfirmed.
3. UK and US purchasing: direct product links, checked dates, stock, pack sizes, taxes, delivery and regional costs. Mark unverifiable details as unknown; do not invent links, prices or availability.
4. Assembly: an ordered guide covering fabrication, fitting, wiring or software as applicable, setup, checks and troubleshooting.
5. Cost and time: separate parts, fabrication, delivery, hands-on time and machine time, with assumptions and exclusions.
6. Function and ease: a test plan for the project's stated purpose, likely difficulties, required skills and any corrections or limitations.

Keep source facts, your proposals and items needing physical verification distinct. An estimate is not a measured build result. Do not claim to have built or tested hardware. Include failed attempts and omissions. If a section does not apply, say why.

Use the source as accessed during this run and record its revision or access date. The prompt is fixed; the linked source can change.