A 4WD electric rover that reports into Hock Lim Engineering's AI-powered ERP
Hock Lim Engineering is a major PUB contractor working on the water infrastructure that serves Singapore's entire southern waterfront. We built them a four-wheel-drive electric rover - and, more importantly, the pipe that carries what it sees straight into the ERP their team already runs the job from.
Why a contractor needed a robot
Hock Lim Engineering does not have a small-site problem. As a major contractor to PUB, Singapore's national water agency, its work covers the water infrastructure serving the entire southern waterfront. That is a lot of ground, spread across sites that are often linear, often partially enclosed, and rarely convenient to walk end to end several times a day.
Site monitoring on work of that kind is mostly a logistics problem dressed up as a supervision problem. Someone has to physically be where the work is to know the state of it. Every progress note, every condition check, every "is that where we left it yesterday" costs a trip. And because the trip is expensive, checks happen less often than anyone would like, which means the gap between what the system says and what the site looks like grows quietly until something forces a reconciliation.
Hock Lim already had the better half of the answer: an ERP that runs their operations and an AI layer on top of it that their staff can actually ask questions of. What it did not have was a reliable way to be told what was happening on the ground without a person walking there to type it in.
The problem, stated plainly
An ERP is only ever as current as its last honest input. When the input depends on a supervisor finishing a walk, remembering what they saw, and finding a moment to record it, the record drifts - not because anyone is careless, but because the process asks a person to be in two places at once. The rover exists to close that gap: to make the site report itself, on a schedule, into the system that already decides what happens next.
What the walk was costing
DistanceWaterfront infrastructure work is spread out. Checking it end to end is a journey, not a glance, and the journey has to be repeated.
FrequencyBecause each check is expensive in time, checks get rationed. Conditions change between them.
ConsistencyTwo supervisors walking the same stretch record different things, in different words, at different levels of detail.
LagWhat the site looked like at 9am reaches the ERP in the evening, if it reaches it at all that day.
Recall"Has this changed since last week?" is a memory question when there is no comparable record from last week.
AccessSome stretches are enclosed, low, or awkward enough that sending a person is a decision, not a routine.
What we built, and why it looks like this
The rover is four-wheel drive and battery-electric. Neither choice was about specification sheets - both came out of where it has to go.
Four driven wheels because infrastructure sites are not warehouse floors. Loose ground, lips, grating, temporary surfaces and slopes are the normal case, not the exception. A platform that drives on all four corners recovers from a wheel losing grip instead of stopping the run and requiring a person to go and retrieve it - which would reintroduce the exact trip we were trying to remove.
Battery-electric because a meaningful share of this work happens in enclosed or partially enclosed space. A combustion platform in a confined stretch of water infrastructure is a ventilation problem and a permit problem. Electric is quiet enough to run alongside working crews, and it removes an entire category of conversation about exhaust before it starts.
The sensor payload is deliberately narrow. We did not fit every instrument that would fit. We fitted what answers the questions the site actually asks each day, because every extra stream is another thing to power, calibrate, store, and eventually defend when it disagrees with something else.
From wheel to work order
- Run - the rover covers its route on a schedule or on request, rather than whenever a person is free.
- Capture - it records the site as it goes, with position and timestamp attached to every observation so anything can be placed and compared later.
- Normalise - raw capture is turned into consistent, structured records. This is the unglamorous step that makes everything after it possible.
- Index - those records are embedded and stored so the ERP's AI layer can retrieve them by meaning, not just by exact field match.
- Answer - staff ask the ERP a question in their own words and get an answer grounded in what the rover recorded, with the underlying record to check.
Why retrieval-augmented generation, and not just a dashboard
A dashboard answers the questions you anticipated when you built it. Site operations do not work that way. The useful question is usually specific, unplanned, and phrased the way a foreman would phrase it - not the way a database schema would.
Hock Lim's ERP already had an AI layer built on retrieval-augmented generation. RAG matters here because it makes the model answer from the record rather than from its own training: the question is matched by meaning against the indexed material, the relevant records are pulled, and the answer is composed from those. It is the difference between a system that sounds confident and a system that can show you where it got that.
Connecting the rover to that layer meant the site itself became part of the retrievable record. The same staff who could already ask the ERP about a job can now ask it about the ground - and the answer is grounded in something that was physically there this morning.
We have written a longer, plainer explanation of the retrieval mechanism itself: how RAG uses cosine similarity.
Where a person stays in the loop
This is water infrastructure for a national agency. Our standing rule on robotics applies with more force here than anywhere else: a person stays in the loop wherever a miss would hurt someone or cost a lot.
The rover observes and reports. It is an instrument for keeping the record honest, not an authority that decides what happens next. Judgement calls, safety decisions and anything with a consequence stay with Hock Lim's people - the difference is that they now make those calls against a record that reflects this morning rather than last week.
The same principle is why the retrieval layer always exposes the underlying record behind an answer. If a supervisor does not believe what the system just told them, they can go and look at what it was reading. A system nobody is allowed to check is a system nobody should trust.
What changed
The point of the build was never the robot. It was closing the distance between what is true on site and what the ERP believes - and doing it without asking anyone to walk further.
Monitoring stopped depending on whether someone had time for the walk. Observations arrived in a consistent form instead of in whatever words the day produced, which meant they could be compared across days rather than just read once. And because the records landed in the system Hock Lim already runs operations from, nobody had to adopt a second tool to get the benefit.
The rover did not replace a supervisor. It removed the trip that was standing between a supervisor and an up-to-date record.
Why this had to be built, not bought
There are inspection robots on the market. There are ERP systems on the market. What there is not is a product that knows what Hock Lim's sites look like, what their ERP expects, and how their staff phrase a question - and the value of this build lives almost entirely in those three things lining up.
An off-the-shelf rover would have produced a stream of data in somebody else's format, landing in somebody else's portal, requiring a person to bridge the gap back to the ERP. That is the manual trip again, wearing a different hat. The integration was never the finishing touch on this project. It was the project.
This is also why robotics and software sat in the same team here. The drivetrain decisions and the retrieval decisions constrain each other - what the rover can reliably capture on rough ground determines what the ERP can usefully be asked. Split those across two vendors and the seam becomes the client's problem. More on how we approach robotics.
Where this goes next
Change detectionComparing today's run against previous ones automatically, so the system raises the difference rather than waiting to be asked.
Wider visionExtending computer vision on the captured feed to flag specific conditions without a person reviewing footage.
Route planningLetting the ERP decide what needs looking at, and dispatching the run from the work itself.
More groundAdditional platforms covering more of the southern waterfront under the same reporting pipeline.
The short version
A contractor responsible for water infrastructure across an entire waterfront needed its ERP to know what its sites looked like, without that knowledge depending on how many walks a supervisor could fit into a day. We built a four-wheel-drive electric rover suited to the ground it has to cover, and connected it to the retrieval layer their ERP already ran on, so the site now reports itself into the system that acts on it.
That is the kind of problem we take: not the one with a product page waiting for it, but the one where the answer has to be assembled from hardware, data and the way a specific business actually works.
From the homepage? This case study expands the Robotics & physical AI card in the first services grid. Jump back to that grid, or see the rest of the work.
Got something on the ground that your systems cannot see?
Tell us what has to be observed, how often, and where it needs to land afterwards. You will get a straight answer on whether a machine should be doing it - including if the answer is no.