Skip to content
RETIEB Labs
ROBOTICS
Get in touch
RETIEB Robotics

A long-term engineering initiative.

RETIEB Robotics is the physical-systems practice inside RETIEB Labs. It exists to develop machines that work dependably in real environments, and to build the engineering knowledge, tooling, and platform components that every robot we build afterwards inherits.

Program control

2 platforms
Platforms in development
2
1 prototype · 1 concept
Most recent activity
ERDEN Utility
8 Aug 2026 · 2 log entries
Leading focus
Power validation
ERDEN Scout · Testing
Priority challenge
Charging verification
ERDEN Scout · In development
Next milestone
Power validation complete
ERDEN Scout · Q3 2026
Last updated
8 Aug 2026
ERDEN Utility · from the engineering log

Program structure

Platforms2

  • ERDEN Scout
  • ERDEN Utility

Shared modules1

  • Payload interface
Newest engineering eventERDEN UtilityERDEN Utility platform selection8 Aug 2026Read entry
9
Log entries
17
Hardware
14
Modules
11
Decisions
11
Challenges
10
Focus areas

ERDEN platforms

Two platforms are open. ERDEN Scout is a small outdoor ground robot used to develop and validate the autonomy stack in real terrain. ERDEN Utility is a load-carrying work platform at baseline characterisation — a factory electric utility vehicle with no conversion work started. Further platforms will be added when they have engineering substance to report — not before.

Concept visualisation of the mature ERDEN Scout platform — a modular outdoor ground rover
ERDEN program · Ground platform 01Prototype

ERDEN Scout

A modular autonomous rover being developed to observe, understand, and assist — the first platform in the ERDEN program.

Shared modules1

Concept visualisation of the ERDEN Utility platform — an electric utility cart carrying garden soil along a stone walkway
ERDEN program · Ground platform 02Concept

ERDEN Utility

A load-carrying work platform being developed from a commercial electric utility vehicle — the second platform in the ERDEN program.

Shared modules1

Platform readiness

Each platform is read on its own terms — readiness is a ladder position derived from that platform's own records, never an average across the program.

  • ERDEN ScoutPrototype
    ERDEN program · Ground platform 01
    Early

    Paced by module readiness, integration readiness · 5 of 5 dimensions evidenced

    Hardware
    Module
    Integration
    Documentation
    Decision
  • ERDEN UtilityConcept
    ERDEN program · Ground platform 02
    Early

    Paced by hardware readiness, module readiness, integration readiness, decision completeness · 5 of 5 dimensions evidenced

    Hardware
    Module
    Integration
    Documentation
    Decision

Engineering activity

The five most recent engineering events across every platform, each linked to the log entry that documents it.

Current focus

Shared focus records, ordered by engineering state and labelled with the platform each one serves.

TestingERDEN ScoutPower

Power validation

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.

EngineeringRobotics-wideProcess

Platform documentation

Writing interfaces and procedures down as they stabilise, so the second platform starts from the first rather than repeating it. The engineering log is the first draft of that documentation.

ResearchERDEN UtilityElectrical

Baseline characterisation

Measuring what the factory vehicle actually is: drive and controller signalling, braking behaviour and fail-state, steering geometry, pack chemistry and charging, and mass distribution. Every later decision on this platform is waiting on these numbers.

IntegrationERDEN ScoutElectrical

Radio bring-up

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.

ResearchERDEN UtilityElectrical

Control architecture definition

Deciding how the platform will be commanded — whether autonomy talks to the factory controller, intercepts the operator inputs, or replaces the control electronics — and what the steering and braking paths look like in each case. Nothing is selected; the options are being framed against the baseline measurements.

EngineeringERDEN ScoutMechanical

Drivetrain mounting

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.

ResearchERDEN UtilityProcess

Safety architecture for a heavy platform

Establishing what has to be true before a vehicle rated for 660 lb of payload is allowed to move without someone on it: an emergency stop that does not depend on software, defined fail-safe states, speed limiting, and a specified response to every fault the platform can detect.

PlanningERDEN ScoutPerception

Camera integration

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.

PlanningERDEN ScoutTooling

Repeatable testing

Tooling that makes every run capturable, replayable, and comparable against the previous one. Without it, bench and yard time produce anecdotes instead of data.

PlanningERDEN ScoutNavigation

Trustworthy state estimation

Encoder feedback that can be characterised and relied upon, as the base layer under every later navigation capability. Nothing here is meaningful until the mounts hold the encoders in a repeatable position.

Open engineering challenges

Blocked work first, then whatever is furthest along. Every challenge states the platforms it affects.

In developmentTestingERDEN ScoutPower

Charging verification

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.

ConceptResearchERDEN UtilityElectrical

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.

In developmentIntegrationERDEN ScoutElectrical

Radio configuration

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.

ConceptResearchERDEN UtilityPower

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.

In developmentEngineeringERDEN ScoutMechanical

Motor mount replacement

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.

ConceptResearchERDEN UtilityElectrical

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.

In developmentPlanningERDEN ScoutPerception

Camera integration

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.

ConceptResearchERDEN UtilityMechanical

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.

ConceptResearchERDEN ScoutPower

Runtime under load is unknown

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.

ConceptResearchERDEN UtilityElectrical

Safety architecture for a heavy platform is unspecified

A vehicle of this mass and payload rating needs a layered safety architecture — emergency stop independent of software, defined fail-safe states, speed limiting, and specified behaviour on every detectable fault — before any automated motion is attempted. None of it exists.

ConceptResearchERDEN UtilityMechanical

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.

Latest from the engineering log

8 Aug 2026ProcessERDEN UtilityConcept

ERDEN Utility platform selection

ERDEN Utility is opened as the second ERDEN platform, starting from a factory VEVOR four-wheel electric utility cart: roughly 51.2 by 25.6 inches, 125.7 lb, rated for 660 lb of payload, driven by a 500 W brushless system to about 5 km/h on 13 inch pneumatic tyres. The vehicle is factory-standard. No conversion work has been done, nothing has been measured first-hand, and every figure recorded so far is vendor-published. The purpose of opening the record now is to have somewhere honest to put the characterisation work as it happens, rather than reconstructing it later.

8 Aug 2026ProcessERDEN UtilityIn development

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.

1 Aug 2026TestingERDEN ScoutIn development

Preparing for the first teleoperated drive

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.

View the full log

Mission

Build practical robotic systems that operate dependably outside controlled environments, and keep improving them for as long as they are useful.

We are not pursuing demonstrations. A system counts as working when it runs repeatedly, in the field, without a specialist standing next to it.

Vision

Autonomy in the physical world becomes ordinary infrastructure — reliable, maintainable, and unremarkable in daily use.

RETIEB Robotics is structured to still be running in a decade. Platforms will change; the underlying engineering capability is what we intend to keep.

Engineering philosophy

Foundation before features. Power, safety, and state estimation are settled before autonomy is layered on top.

Measure before claiming. Every capability on this site carries a status, and provisional figures are marked as provisional.

Small, instrumented steps. We prefer a modest platform that logs everything to an ambitious one that explains nothing.

Platform philosophy

Each robot is a client of a shared robotics platform: common runtime, telemetry, state estimation, control interfaces, calibration procedures, and test tooling.

That platform is itself part of the RETIEB Platform Foundation. Work done on one machine is expected to reduce the cost of the next one, in the same way software work compounds across the portfolio.

Engineering knowledge base

88 records · 341 relationships

Every record published across RETIEB Robotics, counted straight from the knowledge graph — not from any single platform's neighbourhood.

Programs1

  • ERDEN ProgramRETIEB Robotics · Ground systems

Platforms2

Hardware17

  • WAVE ROVER 4WDChassis · Waveshare
  • Motor and encoder mounts (custom)Drive · Designed and printed in-house
  • Jetson NanoCompute · NVIDIA
  • CSI cameraSensing · Generic (IMX219 class)

+13 more

Modules14

+10 more

Engineering logs9

+5 more

Decisions11

+7 more

Challenges11

+7 more

Focus areas10

+6 more