Phases are sequencing, not commitments. Dates are coarse on purpose — hardware timelines that read as precise are usually wrong. Each phase closes when its outcomes are demonstrated on the platform, not when the calendar says so.
ERDEN Scout
Phases6CurrentPhase 2
ERDEN Utility
Phases7
Shared phases1
Payload interface
Acquire a known-good base and understand it completely before modifying anything.
Know exactly how the platform is powered, and prove it behaves before anything depends on it.
Make the platform drivable and stoppable by a person, over a link that does not depend on the autonomy computer.
Bring perception and household integration onto the platform, starting with a feed that does not drop frames.
Move the platform off the bench and onto real ground, supervised, with a conservative stop policy.
Operate across sessions without a person at the start and end of each one, and turn observations into something useful over time.
WAVE ROVER 4WD acquired and designated ERDEN Scout.
Full teardown, photographic inventory, and mechanical assessment.
Every rail traced with a meter and documented as the platform reference.
Integrated Waveshare charge and distribution adopted; custom board cancelled.
3S lithium-ion pack matched to the onboard charger and installed.
Charge termination, rail behaviour under compute load, and measured runtime.
Driven under command with a verified failsafe and replacement motor mounts fitted.
Stable timestamped visual feed running on the platform.
Status and telemetry surfaced alongside the property's other systems.
Driving real ground with an operator present.
A repeatable route completed without operator input.
Return and recharge without a person present.
Take the factory vehicle apart on paper before touching it: measure what it is, and write down what it does.
Decide how the platform will be commanded, on evidence rather than preference.
Establish the stop path and fail-safe behaviour before the platform moves under anything but an operator's hand.
Get the operator off the vehicle, with telemetry good enough to explain every run afterwards.
Repeatable routes across real ground with obstacle-aware motion and conservative stopping.
Turn the deck into an interface so work attachments stop being one-offs.
Useful work carried out repeatedly, across sessions, without a specialist present.
Drive signalling, braking behaviour, steering geometry, and the electrical system measured first-hand and written down.
Drive-by-wire, steering actuation, and the safety architecture selected and specified against the measured baseline.
The platform moves under software command with an independent stop demonstrated under fault.
Reusable capability packages tracked independently of any single platform. Each declares the platforms it fits and the phase that delivers it.
Camera capture, calibration, and obstacle detection feeding the local planner. The first perception capability intended to be reused unchanged across platforms.
Requires a rigid forward mount and a share of the 5 V rail; both are gated on power validation.
The documented mechanical, power, and data interface that lets payloads be swapped without platform changes. The dependency every other payload module sits behind.
Specification pending: mounting pattern, power budget, and data bus.
Autonomous return-to-dock and recharge, so a platform can operate across sessions without a person present at the start and end of each one.
Depends on reliable return-to-origin and a charge-state model that can be trusted.
Ambient sensing payload — temperature, humidity, pressure, and air quality — logged against position so environmental data is spatially meaningful.
Depends on the payload interface being specified first.
Thermal imaging payload for inspection tasks, aligned to the visual feed so thermal and visible observations share one frame of reference.
Requires the payload interface and a calibrated alignment to the vision module.
Commanded propulsion for the utility platform — speed and direction under software control rather than operator input. Depends entirely on how the factory controller can be commanded or replaced.
Blocked on characterising the factory controller interface. Nothing about command rate, resolution, or latency is known.
Steering actuation for the utility platform. The base vehicle steers mechanically; whether that becomes an actuated column, a replaced assembly, or something else is an open architectural question.
Steering geometry, effort, and travel all unmeasured. No actuation approach selected.
Commanded braking and the independent stop path for a vehicle heavy enough to matter. Treated as a safety subsystem, not a drive function.
The factory brake's behaviour on power loss and on controller fault is unknown, and that unknown blocks every motion test.
Pack characterisation, charging behaviour, and the auxiliary rails that compute, sensing, and actuation would eventually draw from. None of it is established.
Chemistry, voltage, capacity, charge behaviour, and available auxiliary power are all unmeasured.
Onboard computing for control, logging, and later autonomy. No hardware has been selected, because selection follows the power and control-architecture answers rather than preceding them.
No compute hardware chosen. Requirements depend on the drive-by-wire and safety architecture.
The operator link and the telemetry path off the vehicle, including the remote stop that must work independently of onboard software.
Expected to reuse the independent-stop boundary established on Scout, but nothing has been selected or specified.
Position and heading estimation for a wheeled work vehicle on outdoor ground. Nothing is instrumented; the vehicle currently produces no feedback of any kind.
No wheel feedback fitted. Pneumatic tyres make rolling radius a measured quantity, not a constant.
The layered safety architecture the platform needs before it moves without an operator on board: emergency stop, fail-safe states, speed limiting, and a defined behaviour on every fault it can detect.
This module gates the platform. A 660 lb-rated vehicle does not get automated motion tests before its fail-safe behaviour is specified and demonstrated.
Route following and obstacle-aware motion for the work platform. Deliberately last: it depends on every other module in this list being real.
No work has started and none will until drive, steering, braking, safety, and localisation exist.
