AI AGENT ROVER - START A SIMILAR EXPERIMENT Copy the prompt below into your AI assistant. Fill in the setup fields first. This is a project planning prompt, not a verified wiring or operating manual. --- PROMPT START --- Help me build a supervised AI-controlled rover experiment. My objective is to discover the capabilities AND limitations of an AI agent such as Grok Bot: can it understand camera observations, control a physical object, reason about its environment, adapt after mistakes and recognise when it should stop or ask for help? Success is evidence about what works, what fails and why. Do not assume autonomy or claim success from a command acknowledgement alone. MY SETUP - AI agent and tool/API access available: [fill in] - Existing RC vehicle, dimensions and drivetrain: [fill in] - ESC make/model, battery chemistry/voltage and connector: [fill in] - Existing steering servo label and known specifications: [fill in] - Pi/computer, operating system and cooling: [fill in] - Camera and intended camera-pan servo: [fill in] - Servo control board and range-sensor breakout: [fill in] - Power bank, PD profiles, power board, cables and servo regulator: [fill in] - Printer/material or printing service: [fill in] - Country, budget, tools I own and electronics experience: [fill in] - Where supervised tests can take place: [fill in] WORK IN THIS ORDER 1. CAMERA - CAN THE BOT UNDERSTAND A BASIC INPUT? Bring up the camera without movement enabled. Check the picture, timestamps, object-detection outputs and connection latency. Give the agent read-only tools first. Distinguish a fresh observation, an old frame, no detections and unavailable inference. Ask the bot to describe and reason from observations, then compare against what I can verify. 2. SERVO - CAN IT CONTROL A BASIC OUTPUT? Test one unloaded camera-pan servo independently with a suitable regulated supply. Verify direction, mechanical range, centre and cable travel. Document control units and sign conventions. Let the bot make small bounded changes and compare before/after observations. Do not treat commanded position as measured feedback. Check Stop and failure behaviour before attaching the full camera load. 3. SIMULATION - CAN IT WORK IN A WORLD? Create a separate virtual rover in a furnished house with obstacles and a moving target such as a dog. Provide camera observations, state, bounded drive commands and Stop through an authenticated API. Test observe → decide → act → observe loops, route finding, moving targets, collisions, human takeover and recovery. Keep synthetic labels/ground truth separate from claims about real vision. Run repeatable trials and record outcomes; do not invent performance scores. 4. REAL STEERING AND DRIVE - CAN IT CONTROL THE CAR? Identify the vehicle's exact electronics before wiring. Test steering with the motor disconnected. Then test the ESC with the wheels securely raised: establish neutral, confirm readiness, try short forward requests, verify stopping, and test the ESC's documented brake/reverse sequence. Confirm pulse ranges, polarity, motor type and calibration for MY hardware. The computer/control board sends signals; the ESC carries motor current. 5. INTEGRATION - CAN IT DO EVERYTHING TOGETHER? Combine camera, pan, range, steering and drive only after individual checks. Use separate simulation and hardware endpoints and credentials. Build a clearly labelled bench interface showing the camera, commanded states, telemetry age, range validity, manual/AI mode and software Stop. Reject expired/duplicate commands; test connection loss and reconnection without replaying an old move. State what happens if the helper freezes or power partly fails. Design the housing around measured parts: cooling, insulated board clearances, strain relief, access to connectors, removable batteries and reachable physical power isolation. Re-test after mounting. Only then plan short supervised ground trials. 6. UNTETHERED - CAN IT WORK WITHOUT BENCH POWER? Validate portable power under the actual combined load. A possible architecture is a separate USB-C power bank → compatible PD board → Pi, plus an RC battery → ESC → motor and a correctly rated regulator branch for servo power. Treat this as an example, not an approved circuit for my parts. Check PD negotiation, cable ratings, connector seating, startup/shutdown, supply stability and servo peak demand. Do not join independent regulator positive outputs. Distinguish shared signal ground, logic supply and servo supply. A charge percentage is not a voltage/current measurement. Untethered means no trailing bench-power cable; cloud AI may still require a network. Keep human supervision and a tested physical means to stop or isolate drive power. HOW I WANT YOU TO WORK - Begin with a concise plan and ask only for facts necessary for the next safe step. - Inventory what I already own before recommending purchases. Provide quantities, exact confirmed models, alternatives labelled as examples, and compatibility checks. - Consult current manufacturer documentation for component ratings and control behaviour; link sources. Do not infer ratings from wire colour, board appearance or a servo's torque label. - Separate confirmed observations, hypotheses and untested changes. Compare bench and mounted conditions when a fault appears after assembly. - Diagnose one variable at a time. Before replacing a component, propose a small test that distinguishes plausible causes. - Give me a pass criterion, expected failure symptoms and a recovery/stop method for each stage. Wait for the actual test result before saying that stage passed. - Keep credentials out of chat, URLs, public pages and source code. Use secure configuration and scoped revocable keys. Human permission to enable hardware must remain explicit. - Keep pets and bystanders out of physical drive tests. Do not treat a software Stop, forward-only range sensor or successful simulation as a complete physical safety system. - Track each trial: task, starting conditions, software/settings, observation freshness, command, measured result, intervention, suspected cause and next experiment. - Attribute failures carefully: AI reasoning, sensing, networking, power, mechanics and control software are different possible causes. DELIVERABLES A six-stage experiment plan; an annotated parts/shopping list; a power-and-signal architecture; an incremental interface/API design; a simulation mission and evaluation plan; a measured housing brief; and an honest build log documenting limits as well as wins. Start by reviewing my setup fields and identifying the information needed for the camera-only stage. No hardware actuation is authorised by this planning prompt. --- PROMPT END --- Inspired by AIAgentRover.com and the Grok Bot rover project.