Robots that take the repetitive reach
Robotics here means machines on the floor, not the software that clicks through a screen. Arms, carts, rovers and sensors that pick, place, inspect or carry, so nobody repeats the same motion a thousand times a shift. A person stays in the loop wherever a miss would hurt someone or cost real money.
The rover, from every angle.
See the real rover alongside its 3D model, including the upright GSM modem, compact USB connections and an exploded view of the onboard components.
Download showcase · MP4 ↗Explore the rover in 3D
What "physical AI" actually means
Most AI you have met lives entirely inside a screen. It reads text, writes text, and if it gets something wrong you scroll up and try again. Nothing moved. Nothing broke. The cost of a mistake is a little time and some mild irritation.
Physical AI is the same family of techniques pointed at the world outside the screen, where a decision becomes a motor turning. A camera sees a part, a model decides what it is, and something with mass moves. That single difference - mass - changes every engineering decision that follows, because the real world does not offer an undo.
A chatbot that is wrong 2% of the time is a good chatbot. A gripper that is wrong 2% of the time is dropping something every fifty cycles, and what it drops determines whether that is an annoyance or an incident. So the job is not just making the model accurate. It is designing the system around the model so that the 2% is caught, contained, and handed to a person before it costs anything.
That is the discipline this page is about: not robots as a novelty, but robots as a dependable part of an operation that already has to run tomorrow morning.
The loop every deployment runs
- Sense - cameras, depth, lidar, encoders, force and whatever else the job actually needs. On a fixed cell the sensor sits still; on a rover the sensing moves, which is harder and often the only thing that covers enough ground.
- Decide - perception becomes a labelled understanding of the scene, and that becomes a plan: what to move, where to, along what path, and with how much confidence.
- Check - anything consequential passes a gate before it executes. Sometimes that gate is a confidence threshold. Sometimes it is a person. On a low-confidence read, the correct answer is to stop and ask, not to guess gracefully.
- Act - motion, with limits on speed, force and reach that were decided before anything was switched on.
- Verify - the system confirms what it just did, because an open-loop robot is a rumour. The result feeds the next pass, so drift shows up as a trend rather than a surprise.
What we build
Mobile roversDriven platforms that cover ground a fixed camera never will - carrying sensors along a route on a schedule instead of waiting for someone to walk it.
Pick and place cellsArms that take one repeated motion off a person: the same reach, the same grip, the same drop, done the same way on the thousandth cycle as on the first.
Inspection rigsVision pointed at a specific question - is it there, is it right, is it in the wrong place - with the answer recorded rather than just displayed.
Sensor integrationGetting cameras, depth, encoders and existing PLCs to agree on one picture of what is happening, on the same clock.
Human-in-the-loop controlSupervision screens, confidence gates and stop authority, so the hard calls reach a person with enough context to make them.
Back-office integrationThe part most robotics projects forget: getting what the machine saw into the ERP, dashboard or report the business actually runs on.
Why this is harder than software AI
It is worth being blunt about this, because the gap between a convincing demo and a system that runs unattended for a year is where most robotics money is lost.
The world does not hold still. Lighting changes through the day. A pallet gets set down four degrees off. Someone repaints a wall and your visual landmark is gone. Software AI is handed clean inputs; physical AI has to earn them, and most of the engineering effort goes into tolerating the conditions rather than into the model.
Calibration drifts. A camera that was accurate in January is slightly off by June, and nothing announces it. Systems that assume their own calibration are systems that fail quietly, which is the worst way to fail. Anything we build checks itself and says so when it has moved.
Latency is a physical quantity. On screen, a slow response is a spinner. On a moving platform, the delay between seeing and stopping is a distance, and that distance either clears the obstacle or does not. Budgets get set at design time, not tuned afterwards.
Failure is not symmetric. A missed detection and a false detection cost completely different amounts depending on the job, and treating them as one accuracy number hides the only thing worth knowing. We tune for the failure that actually costs you, and we will ask which one that is on the first call.
Recovery matters more than success rate. The interesting question is never "does it work?" - demos work. It is what happens on the run where the grip slips or the route is blocked, and whether getting back to normal needs an engineer on site.
Where a person stays in the loop
We do not build machines that make consequential decisions alone. That is not caution for its own sake - it is what makes the system deployable in a business that has real obligations to real people.
In practice it means three things. Anything that could injure someone or write off something expensive passes a human checkpoint first. Low confidence escalates rather than proceeds, because a model that guesses when it is unsure is worse than one that stops. And a person always has stop authority that does not depend on the software being healthy enough to honour it.
The point of automating a motion is to take a repetitive, wearing job off a person - not to remove the judgement that keeps the operation safe.
How a first deployment actually goes
- One motion, named - we pick the single reach, route or check worth automating first, and write down what "working" means in numbers before anything is built.
- Bench first - the loop is proven off your floor, where a mistake costs nothing and iteration is fast.
- Supervised pilot - it runs on the real site with a person watching, doing the real job at real speed, while we collect the failures that a bench never produces.
- Measured widening - only once the numbers hold do we add a second route, a second cell, or a longer unattended window.
- Handover - your team gets the controls, the documentation and the accounts. We stay because you want us to, not because you are locked in.
What this looks like in the field
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 - four driven wheels because infrastructure sites are not warehouse floors, battery-electric because much of the work happens in enclosed space - and connected it to the RAG-powered ERP their team already runs the job from.
The result is the loop above, running on a real site: the rover covers its route on a schedule, what it records is normalised and indexed, and staff ask the ERP questions in their own words and get answers grounded in what was physically there that morning. Site conditions reach the system without waiting on anyone's next walk.
Robotics and vision are the same project
Almost every robot worth building needs to know what it is looking at, and almost every camera worth installing eventually needs something to act on what it saw. We treat the two as one discipline rather than two quotes, because the seam between them is where split-vendor projects fail: what the vision can reliably detect decides what the motion can safely attempt.
If your problem is currently more about seeing than moving, start at computer vision instead - it is the same team either way.
From the homepage? This expands the Robotics & physical AI card in the first services grid. Jump back to that grid.
Have a motion you want off a person's plate?
Tell us the reach, the load, the ground it happens on, and what must never go wrong. You will get an honest answer about what is worth automating first - including if the honest answer is that a robot is the wrong tool for it.