Baseline characterization procedure written
The Phase 1 characterization procedure is written: twelve sections covering platform identification, physical baseline, drivetrain, the control path and connector inventory, battery and power, steering, braking, factory safety behaviour, an observed electrical architecture diagram, an integration space survey, the payload attachment survey, and the evidence standard that ties them together. Every finding starts at 'not inspected' and carries the source of its value, so vendor figures cannot quietly become verified figures. A derived completion gate reads the findings and reports exactly which evidence is still missing before drive-by-wire architecture can start. No inspection has been performed yet — this is the script, not the result.
What we learned
- Writing the procedure before touching the vehicle forces the unknowns into the open: most of what we 'know' about this platform is a product listing.
- 'Unknown' has to be a first-class recorded result. If the only options are done and not done, an honest inspection looks like a failed one.
- Making the phase gate read the findings means progress cannot be asserted — it is either in the evidence or it is not.
Next steps
- Work sections 01 and 02 on the physical vehicle: identifiers, labels, and the dimensional baseline.
- Build the connector inventory with everything photographed in place before anything is unmated.
- Take the pack and charger readings at identified terminals only, then draw the observed electrical architecture with unknowns labelled.
- Run the controlled braking and safety behaviour observations at the lowest speed the vehicle will hold.
Hardware referenced
- VEVOR 4-wheel electric utility cartVEVOR51.2 × 25.6 in flatbed cart, 660 lb rated payload, 125.7 lb
- OEM motor controllerVEVOR (OEM)Factory controller, interface not established
- OEM battery systemVEVOR (OEM)OEM pack, specification not established
- OEM accelerator controlVEVOR (OEM)Operator throttle input, signal unmeasured
- OEM forward / reverse selectorVEVOR (OEM)Two-position direction selector
- OEM electronic brakeVEVOR (OEM)Factory electronic brake, fail-state unknown
Open challenges touched
Factory motor control interface is unknown
The vehicle's 500 W brushless drive is commanded by a factory controller with no published interface. Until the signalling between the accelerator, the direction selector, and the controller is measured, there is no way to say whether autonomy commands the existing controller, intercepts its inputs, or replaces it entirely.
Braking behaviour and fail-state are uncharacterised
The factory electronic brake's behaviour on power loss, on controller fault, and under command is unknown, as is its holding capability on a slope with payload. On a vehicle rated to carry 660 lb, this is the unknown that keeps the platform stationary.
Electrical baseline is unmeasured
Battery chemistry, pack voltage, capacity, charging behaviour, and the availability of any auxiliary rail are all unknown. Compute and sensor selection cannot be specified against a power budget that does not exist.
Steering architecture is undefined
The base vehicle steers mechanically and there is no actuation path. Steering geometry, effort, and travel have not been measured, so the choice between actuating the existing column and replacing the assembly cannot be made honestly yet.
Payload and implement interface is undefined
The flatbed deck carries no mounting pattern, power provision, or data provision. Until a standardised interface is written down, any implement built for this platform becomes a one-off, which is exactly the outcome the module registry exists to prevent.
Decisions referenced
Characterise the factory vehicle before any conversion work
No control, compute, or sensing hardware is specified for Utility until the factory drive, braking, steering, and electrical systems have been measured first-hand.
- Every conversion option — command the factory controller, intercept its inputs, or replace it — depends on measurements nobody has taken yet.
- Specifying compute against an unknown power budget produces a bill of materials shaped by guesswork.
- On Scout, the largest schedule saving came from inspecting the base thoroughly before modifying it.
- Order conversion hardware in parallel with characterisation — Rejected — faster on paper, and historically produces parts that do not match what the vehicle turns out to be.
Autonomy work on Utility waits behind a demonstrated safety architecture
No autonomous motion is attempted on Utility until an emergency stop independent of software, defined fail-safe states, and speed limiting are specified and demonstrated.
- The platform's mass and payload rating make an uncommanded movement a physical hazard rather than a debugging inconvenience.
- The independent stop boundary established on Scout is the pattern to carry forward, at a scale where it matters more.
- A safety architecture retrofitted after autonomy exists is a rewrite, not an addition.
- Develop autonomy and safety in parallel — Under consideration only for bench work with the wheels clear of the ground.