Target platform. The hardware below is the prototype we are actually building on today.
Observe.Understand.Assist.
A modular autonomous rover being developed to help homeowners better understand and care for their property through practical robotics.
Sourced from platform metadata and the engineering log — it changes as the work does.
Derived by traversing the knowledge graph: objective, milestones, active areas, blockers, decisions, and risks. Nothing on this panel is written by hand.
Help people understand and care for the property they live on. Scout exists to spend time outdoors, notice what changes, and eventually take on the small, repetitive tasks of looking after a place — not by being clever, but by being dependable enough to be left to it.
ERDEN program · Ground platform 01
Q3 2026
Q3 2026
It is the least-advanced subsystem, and platform readiness is bounded by its weakest part.
Records marked provisional in the registries are carrying part of this platform's definition.
A full review assembled from the graph: readiness, risk, milestone progress, period-over-period change, and recommended next actions. Every conclusion cites the records it was derived from.
ERDEN Scout is prototype with overall readiness at early. 5 challenges remain open while the platform works towards "Power validation complete".
Help people understand and care for the property they live on. Scout exists to spend time outdoors, notice what changes, and eventually take on the small, repetitive tasks of looking after a place — not by being clever, but by being dependable enough to be left to it.
4 engineering areas are open on this platform.
8 hardware records referenced; readiness is developing.
5 modules mounted or declared compatible; least-advanced state is engineering.
4 of 6 decisions are accepted; 3 remain open.
0 of 9 subsystems are operational.
5 challenges referencing this platform are not complete.
7 log entries recorded; newest is 2026-08-01.
Working towards "Power validation complete"; 5 of 12 milestones are complete.
Q3 2026
Q3 2026
It is the least-advanced subsystem, and platform readiness is bounded by its weakest part.
3 log entries have been recorded since "Battery architecture fitted".
Overall readiness is early.
1 risk condition derived from the graph, alongside 19 validation findings in scope.
Records marked provisional in the registries are carrying part of this platform's definition.
Clears when the provisional flag is removed from the referenced records and real detail is recorded.
Compared against the preceding 30-day window (2026-06-09 to 2026-07-09). Dates come from the engineering log and the decision registry; records without dates are excluded.
Dated by first appearance in the log.
Dated by first appearance in the log.
Nothing closed in this window.
No module appeared for the first time.
Readiness is derived from current record states. The graph stores no history of those states, so a readiness delta cannot be computed without inventing one.
Overall readiness is bounded by the weakest supported dimension, so nothing else raises it while this one holds.
5 modules are mounted or declared compatible. Least-advanced module state: Planning.
Raises the platform's overall readiness level, which no other dimension can do while this one is lowest.
Overall readiness is bounded by the weakest supported dimension, so nothing else raises it while this one holds.
9 subsystems are tracked on the platform record. Weakest subsystem: Vision. 0 of 9 subsystems are operational.
Raises the platform's overall readiness level, which no other dimension can do while this one is lowest.
Open challenges are the platform's declared unknowns; each one holds work behind it.
5 challenges referencing this platform are not yet complete.
Reduces the platform's open-question surface and frees the linked engineering areas to progress.
Decisions that are proposed, revisiting, or missing an outcome leave dependent hardware and modules provisional.
3 decisions linked to this platform are unresolved in the decision registry.
Improves decision completeness, which is one of the five readiness dimensions.
It is the least-advanced subsystem, and platform readiness is bounded by its weakest part.
Derived by the platform brief from milestone, roadmap, subsystem, and blocker state.
Advances the earliest incomplete commitment the platform record holds.
Provisional records carry part of the platform definition without confirmed data behind them.
Records marked provisional in the registries are carrying part of this platform's definition.
Removes provisional flags from the definition and strengthens documentation completeness.
The highest gate stage whose conditions currently hold, with every evaluated condition and the records behind it.
Ready for review passes because Mission and current status are recorded on the platform. 8 hardware records referenced. 7 log entries reference this platform. No validation error is reported in scope.
Live graph conditions. There is no completion state: satisfying a condition removes its item.
26 conditions are currently true in the graph across 5 areas; 5 of them block a gate.
gate conditions
The challenge is in development at planning and references this platform.
Clears when: The challenge record's status becomes complete.
The challenge is in development at testing and references this platform.
Clears when: The challenge record's status becomes complete.
The challenge is in development at engineering and references this platform.
Clears when: The challenge record's status becomes complete.
The challenge is in development at integration and references this platform.
Clears when: The challenge record's status becomes complete.
The challenge is concept at research and references this platform.
Clears when: The challenge record's status becomes complete.
The module record carries no hardwareIds, so nothing in the graph states what it physically needs.
Clears when: The module references at least one hardware record.
The module record carries no hardwareIds, so nothing in the graph states what it physically needs.
Clears when: The module references at least one hardware record.
The subsystem records an engineering state but no record that implements it, so its state cannot be corroborated.
Clears when: The subsystem references at least one hardware or module record.
No module in the registry references this hardware record, so its purpose is not expressed as a relationship.
Clears when: A module lists this hardware id, or the hardware record reaches complete.
The subsystem records an engineering state but no record that implements it, so its state cannot be corroborated.
Clears when: The subsystem references at least one hardware or module record.
No module in the registry references this hardware record, so its purpose is not expressed as a relationship.
Clears when: A module lists this hardware id, or the hardware record reaches complete.
No module in the registry references this hardware record, so its purpose is not expressed as a relationship.
Clears when: A module lists this hardware id, or the hardware record reaches complete.
The module record's engineering state is research and its lifecycle status is concept.
Clears when: The module record's engineering state reaches operational.
The module record's engineering state is research and its lifecycle status is concept.
Clears when: The module record's engineering state reaches operational.
The module record's engineering state is planning and its lifecycle status is concept.
Clears when: The module record's engineering state reaches operational.
The module record's engineering state is research and its lifecycle status is concept.
Clears when: The module record's engineering state reaches operational.
The module record's engineering state is engineering and its lifecycle status is in development.
Clears when: The module record's engineering state reaches operational.
The decision registry holds this decision in a non-final status, so everything downstream of it remains provisional.
Clears when: The decision status becomes accepted or superseded.
The decision registry holds this decision in a non-final status, so everything downstream of it remains provisional.
Clears when: The decision status becomes accepted or superseded.
The decision is settled but the record carries no outcome, so its consequence is not in the graph.
Clears when: An outcome is recorded on the decision.
The record carries a placeholder flag, so part of the platform definition has no confirmed data behind it.
Clears when: The placeholder flag is removed once measured detail replaces it.
The record carries a placeholder flag, so part of the platform definition has no confirmed data behind it.
Clears when: The placeholder flag is removed once measured detail replaces it.
The record carries a placeholder flag, so part of the platform definition has no confirmed data behind it.
Clears when: The placeholder flag is removed once measured detail replaces it.
The record carries a placeholder flag, so part of the platform definition has no confirmed data behind it.
Clears when: The placeholder flag is removed once measured detail replaces it.
No documentation links are recorded on the platform, so reviews have nothing external to cite.
Clears when: At least one documentation link is recorded on the platform.
The record carries a placeholder flag, so part of the platform definition has no confirmed data behind it.
Clears when: The placeholder flag is removed once measured detail replaces it.
Direct and reverse dependencies for this platform, with the impact radius reachable through the graph.
Records this one points at
Records pointing back
Longest downstream chain
Where the engineering is actually happening right now.
Engineering is currently being performed on a modified Waveshare WAVE ROVER (FWD) development platform.
Using a donor chassis lets us focus on autonomy, sensing, software, and systems integration while the long-term ERDEN platform evolves through continuous engineering. The concept above is the destination; the bench is the present.
Everything on this page is documented as it happens, including the revisions that failed. We publish engineering, not marketing — the journey is part of the product.
Active engineering work, stated plainly. Entries stay here until they are genuinely resolved.
The first-revision printed motor brackets cracked at the fastener bosses under drivetrain load. Because the same bracket locates the encoder against the motor shaft, a compliant mount corrupts odometry well before it fails visibly. Revision two thickens the bosses and moves to a stiffer material; it has not yet been printed or loaded.
The onboard charger appears to bring the 3S pack up correctly, but termination voltage, termination behaviour, and cell balance at the top of charge have not been confirmed with an external meter. Until they are, charging stays supervised and the platform does not sit on the charger unattended.
The CSI camera is mounted but not yet streaming reliably from the Jetson. Open questions are the capture pipeline, frame timing, and what the camera adds to the 5 V rail once it runs continuously alongside compute.
The control link needs to arrive as a genuinely independent path — a transmitter, a receiver, a failsafe that triggers on link loss, and a stop that does not depend on the autonomy computer being healthy. Binding, protocol selection, and failsafe behaviour are all still open.
No figure is published for endurance because none has been measured. The pack has never been drawn down under a representative drive-and-compute load, and estimating it from cell capacity would be a guess presented as a specification.
Help people understand and care for the property they live on. Scout exists to spend time outdoors, notice what changes, and eventually take on the small, repetitive tasks of looking after a place — not by being clever, but by being dependable enough to be left to it.
Most of what goes wrong around a property announces itself early and quietly: standing water where there was none, a fence post moving, a gutter overflowing in the same corner each time it rains. A person notices these things eventually. A machine that walks the same ground regularly notices them sooner, and remembers what it looked like last month.
Scout is the first platform in the ERDEN program and it is deliberately modest. It is not a product and is not intended to be one. Its purpose is to give us a physical, instrumented base to develop control, perception, and navigation against — and to force the unglamorous problems into the open early, where they are cheap to fix.
Development is being documented publicly in the Engineering Log as it happens, including the parts that failed. A record that only contains successes is not an engineering record; it is marketing with dates on it.
Prototype integration. The base platform is torn down, understood, and reassembled with the pack and compute fitted. Power is on and behaving, and the measured power tree is the reference document for the platform. The drivetrain is waiting on replacement motor mounts after the first revision cracked under load, and the control link is being brought up. Nothing has driven under command yet.
Chassis torn down, catalogued, and reassembled. Custom motor and encoder mounts failed at revision one; revision two is in design.
Power tree measured and documented. Onboard Waveshare charge and distribution in use; charge termination still to be verified externally.
Jetson Nano mounted and powered from the regulated rail. Not yet carrying a workload; current draw under load is an open question.
CSI camera mounted. Capture pipeline, frame timing, and rail impact all still to be worked through.
Nothing integrated. Encoder feedback is unusable until the mounts are replaced, and everything here sits on top of that.
Active work. Transmitter and receiver selected; binding, protocol, and failsafe behaviour are being brought up now.
Weather sealing, thermal behaviour, and ambient sensing are all unaddressed. The platform has not yet been outdoors.
Deliberately untouched. No autonomy work begins before the platform can be driven and stopped predictably.
Intended integration point for status, telemetry, and scheduled tasks alongside the rest of a property's systems. Scoped, not started.
Getting a control link onto the platform that is low-latency enough to drive on and independent enough to stop with. This is the last thing standing between the rover and its first teleoperated drive.
The first custom part on the platform failed under load, and it happens to be the part that locates the encoders. Revision two has to be stiff enough that odometry is a software problem rather than a mechanical one.
Understanding what the onboard Waveshare power system actually does before anything depends on it. Charge termination, the regulated rail under compute load, and behaviour on brown-out all need measuring rather than assuming.
Bringing the CSI camera up on the Jetson and getting a stable, timestamped feed off the platform. Calibration and obstacle detection come after there is a feed that does not drop frames.
The platform charges in place through the external DC input and reports pack voltage and current from the onboard monitor. Charge termination is still being verified by hand.
Voltage and current visible from the integrated monitor, giving a usable picture of what the platform is drawing before anything else is added to it.
The chassis opens and closes with hand tools in a few minutes, and the internal layout is photographed and catalogued. Mundane, and the reason iteration is cheap.
Every rail traced with a meter rather than inherited from a diagram, including what stays live with the main switch off.
Low-latency manual control over an independent radio link, with a stop path that does not route through the autonomy computer.
Encoder feedback producing a local pose estimate. Gated on motor mounts stiff enough to hold encoder alignment repeatably.
A stable, timestamped visual feed off the platform — the prerequisite for calibration and any obstacle detection that follows.
Platform status, telemetry, and scheduled tasks surfaced alongside the other systems on a property.
Driving a route across real ground with an operator present and a conservative stop policy.
Returning to a dock and recharging without a person present, so the platform can work across sessions.
Resolved from the shared hardware registry. Components are defined once and referenced by every platform that uses them.
| Component | Description and specifications | Status |
|---|---|---|
| WAVE ROVER 4WDWaveshare | Four-wheel-drive rover base with an integrated ESP32 driver board, providing the chassis, drivetrain, low-level motor control, and — as we discovered on inspection — the platform's power system. 4WD skid-steer base, integrated ESP32 driver board
The base is more capable and more integrated than the documentation suggested. Most of the early engineering effort has gone into understanding what it already does rather than adding to it. | Prototype |
| Component | Description and specifications | Status |
|---|---|---|
| Motor and encoder mounts (custom)Designed and printed in-house | Brackets that hold the gearmotors to the chassis and locate the encoders against the motor shafts. The original set cracked at the fastener bosses under drivetrain load and is being redesigned. Printed brackets, revision 2 in design
Encoder alignment depends entirely on this part, so a compliant mount degrades odometry before it fails outright. R2 thickens the bosses and moves to a stiffer material. | In development |
| Component | Description and specifications | Status |
|---|---|---|
| Jetson NanoNVIDIA | Primary compute module running perception, state estimation, and the autonomy stack. Kept off the drive-control path by design: the ESP32 driver board holds motion, so the Jetson can be rebooted without the platform losing control authority. Quad-core ARM, 4 GB, CUDA-capable GPU
Mounted and powered, not yet carrying a workload. Current draw on the shared 5 V rail is one of the open questions for power validation. | Bring-up |
| Component | Description and specifications | Status |
|---|---|---|
| CSI cameraGeneric (IMX219 class) | Forward-facing camera on the CSI interface, providing the primary visual feed for perception work. IMX219 class, CSI-2, wide FOV
Mounted but not yet streaming into anything. Frame timing and current draw on the shared 5 V rail are both open questions. | Bring-up |
| Component | Description and specifications | Status |
|---|---|---|
| 3S lithium-ion packAssembled in-house from 18650 cells | Primary energy store for the platform. Three cells in series matched to the input window of the rover's onboard power system, sized for a working bench or yard session rather than maximum endurance. 3S (11.1 V nominal), 18650 cells
Capacity and runtime figures will stay unstated until the platform has drawn a full pack down under representative load. | Bring-up |
| Waveshare onboard power systemWaveshare | Integrated charge and distribution circuitry built into the rover's driver board. Handles pack charging, regulated rails, and voltage telemetry, replacing the custom distribution board originally planned for the platform. Integrated 3S charging, regulated 5 V rail, INA219 monitoring
Charge termination and current draw under load have not yet been verified with an external meter. Nothing runs unattended until they are. | Bring-up |
| External DC charging inputWaveshare | Barrel-jack input that feeds the onboard charger, allowing the pack to be charged in place. Keeping the chassis closed between sessions is the difference between a platform that gets used and one that gets rebuilt. DC barrel jack to onboard charger
Charging is currently supervised. Verification is an open challenge. | Bring-up |
| Component | Description and specifications | Status |
|---|---|---|
| ExpressLRS linkExpressLRS (open source) | Long-range, low-latency control link used for manual operation and as the independent path for commanded stop. 915 MHz, CRSF, low-latency
Range under tree canopy has not been characterised; required before unattended running. | Prototype |
Reusable capability packages compatible with this platform, drawn from the module registry.
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.
What is running today, what is being integrated, and what is only scoped. Engineering state is stated on every item.
JSON command interface to the ESP32 driver board over serial. Motion commands and telemetry both pass through here; it is the one software path that is known to work.
Reading pack voltage and current from the onboard monitor. Being cross-checked against an external meter before the readings are trusted.
Scripts for driving the board directly, logging telemetry to file, and replaying a session afterwards. Rough, and already the most-used code on the project.
Radio input mapped to drive commands with a failsafe that stops the platform on link loss. Active work, and the gate on the first drive.
Process supervision, configuration, and a single message bus shared by every on-board component. Scoped; nothing written yet.
CSI capture on the Jetson with timestamps that can be aligned to drive and power channels.
Encoder fusion producing a local pose. Waiting on hardware that can hold the encoders still.
Publishing platform state and accepting scheduled tasks from a home automation system.
Costmap-based local planning with a conservative safe-stop policy. Not started.
What was chosen, what was rejected, and why.
ERDEN Scout is built on a commercial 4WD rover base so early effort goes into autonomy and integration rather than mechanical fabrication.
Outcome Sound so far, with an unanticipated benefit: the base carries far more integrated electronics than expected, which shortened the power work considerably.
The custom power distribution board planned for the platform was dropped once the rover's integrated charge, regulation, and current-monitoring circuitry was identified during inspection.
Outcome Removed an entire electrical subsystem from the plan. The trade is that we now depend on behaviour we did not design, which is why charge verification is an open challenge.
Battery architecture was chosen to match the input window of the onboard charge circuit rather than to maximise capacity.
Outcome Pack is fitted and charging. Capacity under load remains unmeasured and is deliberately unpublished.
Manual control and the stop path terminate at the ESP32 driver board, independent of the Jetson, so the autonomy computer can fail without the platform losing control authority.
Encoder mounting was taken in-house to control encoder alignment. The first revision failed under load, and the approach is being re-examined rather than abandoned.
Outcome Revision one cracked at the fastener bosses. The iteration speed argument held; the material choice did not.
No payload module proceeds past research until the mechanical, power, and data interface is written down.
The actual engineering plan, in the order the work has to happen. Later phases are deliberately coarse.
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.
Engineering photography from the bench and the platform itself. Frames are reserved and captioned; images are added as the work is photographed.
Workbench — the base as delivered, before any modification.
9 May 2026
Prototype — chassis components laid out and catalogued during inspection.
16 May 2026
Electronics — charge circuit, regulator, and current monitor identified on the stock board.
13 Jun 2026
Electronics — 3S pack, charge input, and lead routing in the assembled bay.
27 Jun 2026
Mechanical — revision one bracket after the bench load test.
18 Jul 2026
Workbench — rover on blocks with the wheels clear, ready for link and failsafe testing.
1 Aug 2026
Prototype — Jetson Nano and forward CSI camera fitted to the chassis.
Outdoor testing — pending. The platform has not yet been driven outdoors.
Written as the work happens, including the parts that failed.
Working through the list of things that have to be true before the rover moves under command for the first time. Power is on and behaving, compute is mounted, and the drivetrain is waiting on replacement mounts. The remaining work is the control link: a transmitter and receiver bound, a failsafe that triggers on link loss, and a stop that does not route through the autonomy computer. We are writing the pre-run checklist before the drive rather than after it, on the theory that the first run is exactly when a checklist is worth having.
The first revision of the custom motor and encoder brackets cracked at the fastener bosses. The failure showed up on a bench load test rather than in the field, which is the good version of this outcome. The more interesting problem is that the same bracket locates the encoder against the motor shaft, so the part degrades odometry as it goes soft, long before it visibly breaks. Any encoder data collected in the last two weeks has to be treated as suspect.
Settled the pack architecture around what the onboard charger expects rather than around maximum capacity. A 3S lithium-ion pack built from 18650 cells sits inside the charger's input window, which keeps charging on the platform and keeps the onboard current monitoring meaningful. A larger pack with an external charger was the obvious alternative and was rejected: it would mean the rover leaves the bench to charge, and the integrated telemetry stops describing the thing that is actually powering the robot.
