Across conditions and tolerances
Designs are optimised across the whole envelope the robot will meet, including low light, glare, rain, dust and motion, and across the variation real components show against their datasheets.
Robotics and autonomous systems
Design the sensor for the decision, not the picture.
A design platform that optimises a robot's sensing hardware and its perception model together, for one operational decision. It simulates how light, optics and the sensor shape every signal, then finds the leanest configuration that still decides reliably across real conditions.
- Signal captured
- Power drawn
- Decision
- Path clear
The problem
Cameras are chosen for people. Robots don't look. They decide.
Most robots get the best camera the budget allows, and the perception model is trained on whatever that camera produces. The sensor ends up capturing far more than the task needs, while spending power, bandwidth, compute and mass, and it can still miss the one cue that matters.
- Wrong targetSharpness, resolution and colour accuracy describe what people like to look at, not what a robot needs to decide.
- Designed in sequenceOptics are fixed first and the model copes afterwards, so neither side can use what the other could do.
- Tight budgetsOn drones, field robots and edge devices, every milliwatt, gram and megabit shortens endurance or raises cost.
- Slow iterationEvery change of lens, filter or light means another physical build and another round of retraining.
The approach
One decision in. One buildable design out.
The platform treats the sensor and the model as a single system with a single job. It works backwards from the decision the robot has to make, through the physics of how a signal is formed, to the hardware and model that make that decision for the least cost.
-
1
Define the decision
What the robot must decide, what each kind of error costs, the conditions it will work in, and the limits on power, mass, data rate and price.
-
2
Model the physics
A physically grounded simulation of how illumination, optics, filtering and the sensor itself shape the signal that reaches the model, across the full range of operating conditions.
-
3
Optimise both together
Hardware and perception model are tuned as one, against how reliably the decision is made and what it costs. Image quality is never the objective.
-
4
Specify something you can build
An optical and illumination specification, a component list drawn from real parts, sensor settings, a trained model, and predicted performance with honest uncertainty.
-
5
Build, measure, recalibrate
Measurements from each prototype feed back into the simulation, so every build narrows the gap between what was predicted and what the hardware does.
What changes
Same robot, different starting question.
Design question
Image-first
Decision-first
What is optimised
How good the picture looks
How reliably the decision is made, weighted by what each error costs
Order of design
Camera first, model afterwards
Hardware and model together
Power, data, mass, cost
Whatever the chosen camera needs
Explicit objectives with visible trade-offs
Conditions and tolerances
Tested after the build
Designed for across lighting, weather, glare, motion and part variation
What gets captured
Everything in view
What the decision needs, and little else
Iteration
Rebuild, recapture, retrain
Simulate first, then calibrate on hardware
Trade-off explorer
Every watt buys some reliability. See where it stops paying.
For a given decision, the platform maps the leanest design that reaches each level of reliability. A camera chosen for image quality usually sits well above that curve: it pays for capability the decision never uses. Move the slider to set how reliable the decision has to be.
The leanest design needs a fraction of the conventional camera's resources.
Built to hold up
Lean, but never fragile.
A sensor designed for one decision has to keep making it when the world stops cooperating. Reliability is designed in from the first simulation, not tested in at the end.
Captures only what it needs
A sensor shaped around a decision collects less incidental detail. That means less data to move, store and protect if a device is lost or captured.
Calibrated to reality
Each prototype corrects the simulation that designed it, so predictions get closer to the hardware with every build.
Evidence for assurance
Every design ships with its operating envelope and predicted performance with uncertainty, ready for the validation that safety-critical and regulated deployments demand.
Applications
Wherever a robot carries its own power, a lean sensor goes further.
Field robotics and agriculture
Long days on battery, changing light and dirt on the optics. Spending power only on the cues that matter extends every shift.
Industrial inspection
Pass or fail, defect or sound. A decision this specific rewards a sensor built around it.
Drones, wearables and space
Where size, weight and power decide the whole platform.
Logistics
Fleets of robots, each a little cheaper and each running a little longer.
Defence and security
Capture less, transmit less, expose less.
Status
Early, deliberate, and looking for its first decision.
The programme is at concept stage. The first milestone is a single binary decision on a single platform, such as obstacle detection on a small ground robot or a pass or fail inspection call. The co-designed system will be compared with the best affordable conventional camera on decision reliability across conditions, power, data rate and component cost, then built and tested on real hardware.
- Stage
- Concept, moving to first prototype
- First test
- One binary decision, one platform
- Compared against
- The best affordable conventional camera
- Measured on
- Reliability, power, data rate and cost
Partnering
Bring a decision your robot has to make.
The programme is looking for an implementation partner with a real platform, a real operational decision and the conditions it has to work in. In return, you get a sensor and model designed for exactly that job, and the evidence to show what it saves.
Talk to INEVITABLE
Built by INEVITABLE, an AI research and development company in Salford, UK, working on AI for secure and constrained environments. Selected for the first cohort of the GCHQ Accelerator in Manchester.