Physical AI / Robotics / Small-data machine learning

Physical AI for the last mile of real machines.

FERN helps robotics and industrial teams learn from small local machine datasets, reduce real-world physical mismatch and make better tuning, validation and operating decisions — without sending sensitive machine data to the cloud.

30–500rows can be enough for an initial technical benchmark.
On-premdesigned for sensitive machine and production-cell data.
CPU-firstcompact inference path without cloud GPU dependency.
Advisorysupports engineers before any direct-control use case.
Main market

AI and robotics meet at the physical last mile.

Robot foundation models, simulators and control stacks improve general capability. Deployment still depends on how one actual robot, actuator, sensor or production cell behaves under real conditions.

The gap

Payload shifts, heat, surface effects, vibration, drift, wear and tolerances create gaps between expected and measured behaviour.

The FERN layer

FERN sits beside the controller and simulator. It learns a compact local response model from measured numerical logs.

The wedge

Start with robotics and industrial machines. Expand toward a broader on-prem physical decision engine for infrastructure and manufacturing.

Why now

Robots are becoming more capable. Deployment is still slow.

Category thesis

Large robotics models generalize tasks. FERN is designed to adapt the individual physical body: the specific actuator, sensor, payload, surface, heat profile, drift and hardware-state.

The first wedge is robotics. The broader opportunity is an on-prem physical decision layer for industrial machines, production cells, AI infrastructure and expensive engineering tests.

Customer ROI

Less manual tuning. Fewer failed tests. Faster deployment.

FERN is sold on practical engineering ROI: reducing the time and cost between “the system should work” and “this system works in this environment”.

The pain we reduce

Repeated setup cycles engineer time and slower cell launch
Failed bench runs rework, downtime and delayed validation
Unknown safe limits thermal, torque, payload and precision risk
Data-sharing friction sensitive machine data cannot leave site

Where ROI comes from

Shorter commissioning, fewer unnecessary tests, lower downtime, better understanding of operating limits and faster adaptation to new payloads, surfaces and cells.

For a pilot, ROI is estimated from customer baselines: engineer hours per cycle, cost per failed run, downtime cost and number of deployment changes per year.

What FERN solves for you

A local model for the machine in front of you.

FERN is not a robot brain, not a simulator and not a generic cloud AI platform. It is a narrow numerical layer for measured physical behaviour.

Real error response

Map how pose, payload, speed, temperature and setup affect measured error.

Operating envelope

Understand where performance is stable and where risk starts to grow.

Next test decision

Support the choice of the next useful bench run, setup point or validation step.

Local privacy

Keep sensitive tolerances, cell data and machine behaviour inside the customer environment.

For which systems

Best fit: measurable physical systems with limited data.

FERN is relevant when inputs and outputs are numerical, experiments are expensive and the system has structured physical behaviour.

Industrial robotspose error, payload, speed, repeatability, cell-specific setup.
Cobotsworkcell adaptation, surface effects, payload changes and safety boundaries.
Actuators and jointstorque, heat, drift, wear, response curves and failure boundaries.
Sensors and tactile systemsdrift, response curves, noise, temperature and surface effects.
Production cellsvibration, tolerance, cycle conditions and line-specific physical behaviour.
Mobile robots and dronespayload, terrain, thermal limits, battery and control-response envelopes.
Product direction

FERN Box: on-prem physical decision module.

The roadmap is a software-first, CPU-first module that runs on the customer’s own hardware near the robot, PLC, sensor gateway or engineering station — with a pre-configured appliance as an optional later step.

Box concept

A compact local engine that ingests numerical logs, fits and periodically refits a small response model on-site, and returns advisory outputs for the engineer or deployment workflow.

No internet required fitting and inference run on-site; data stays local
No GPU required CPU-first compact model, small enough to retrain locally
No full stack access numerical logs are enough to begin

How it fits

Input sensors, PLC, controller, telemetry, test logs
FERN layer response surface, benchmark, envelope, risk zones
Output engineer decision, setup action, next-test candidate
Mode advisory first; direct control only after validation
Status and roadmap

Clear separation between engine, pilot and box.

This keeps the story credible for investors and useful for professional industrial customers.

Available now

Technical engine

  • complex-valued FERN architecture
  • CPU and CUDA variants
  • degree sweep and model growth
  • depth probing and pruning
  • bagged ensemble workflow
  • compact inference model
Pilot workflow

Machine benchmark

  • customer dataset review
  • FERN vs baseline comparison
  • response surface and sensitivity
  • extrapolation check
  • operating-envelope view
  • Go / No-Go recommendation
Roadmap

FERN Box

  • automatic model-selection gate
  • ensemble-based uncertainty
  • ranked next runs (active learning)
  • unsafe-zone identification
  • local dashboard
  • industrial on-prem module
Why FERN, not other solutions?

Not another cloud AI platform.

FERN is a narrow physical decision layer for small-data machine behaviour, not a general-purpose robotics stack.

ApproachStrong atWhere FERN differs
Robot foundation modelsGeneral behaviour, perception-action learning, broad capability.FERN focuses on the actual machine and its measured physical mismatch.
Simulators / digital twinsVirtual testing, synthetic data, system-scale modelling.FERN works on real local logs and can be lighter than building a full twin.
Cloud AI platformsLarge-scale analytics and enterprise workflows.FERN is designed for local use when machine data is sensitive.
Classical response surfacesSimple, interpretable physical approximation.FERN aims to capture richer nonlinear response surfaces from small data.
Generic tabular MLStrong performance when enough representative data exists.FERN is aimed at small physical datasets where extrapolation and next action matter.
Science & team

Small data. Physical structure. Measured response.

FERN is built around numerical physical variables such as pose, torque, payload, speed, temperature, vibration, power, latency and error. The aim is not to replace the engineer, but to provide a compact decision model that makes the next physical action better informed.

Ivan Svetunkov
Co-Founder & CTO

Ivan Svetunkov

Ivan Svetunkov is Co-Founder and CTO, with a PhD in Management Science and deep expertise in applied forecasting, statistical modelling and data-driven decision systems. He has developed forecasting systems for software companies used around the world.

LinkedIn profile · openforecast.org

Sergey Svetunkov
Co-Founder & Scientific Lead

Sergey Svetunkov

Sergey Svetunkov is Co-Founder and Scientific Lead, currently a Research Associate at Imperial College London working on complex-valued autoregressive models. A Doctor of Economics with decades of research in econometrics, forecasting and complex-valued modelling, his work on complex-valued analysis underpins the complex-valued mathematics at the core of FERN.

LinkedIn profile

Pilot

Give us the logs. We show if FERN creates value.

The first commercial step is a technical benchmark that proves whether FERN can improve the customer’s next physical decision.

What we need

  • 30–500 numerical test rows for an initial benchmark
  • target state, achieved state and measured error
  • payload, speed, temperature, retries and setup variables
  • sensor, actuator or joint telemetry where available
  • business context: what decision should be improved?

What you receive

  • FERN vs baseline model comparison
  • response surface and factor sensitivity
  • operating-envelope and extrapolation-risk view
  • engineering ROI logic based on your cost assumptions
  • Go / No-Go recommendation for a deeper pilot or FERN Box fit

What we do not need first

We do not need source code, CAD files, full factory layout, cloud access, customer contracts or direct access to the production control system. Anonymized local numerical logs are enough to start.

Sample pilot report

A sample pilot report is included below. It shows the report structure: dataset summary, baseline comparison, FERN benchmark, response-surface interpretation, risk zones, ROI assumptions and a practical recommendation.

Sample pilot report

What a first FERN robotics pilot can produce.

The structure below is illustrated with a real worked example on a public robotics dataset (iCub arm inverse dynamics). Customer pilots follow the same structure on your own data, under an agreed evaluation protocol.

REPORT ID: FRN-ROB-SAMPLE-01 · WORKED EXAMPLE · PUBLIC DATASET

Robot-arm inverse-dynamics benchmark and next-run recommendation

A worked technical report showing how FERN is evaluated as a small-data physical decision layer — here on a robot-arm inverse-dynamics task (predicting joint load from motion), using the same structure applied to a robotic joint, actuator or cobot cell.

Robot-arm inverse dynamics (iCub, 4 DoF)
3,000 rows · public iCub set
Benchmark + advisory only
Go / No-Go for deeper pilot

1. Executive summary

The objective is to test whether a compact FERN model can learn the measured response of a specific machine from a small number of local numerical logs. The focus is not autonomous control. The focus is response-surface modelling, extrapolation review and next physical decision support.

Data fitDoes the dataset contain enough clean signal for a first benchmark?
BenchmarkFERN compared with RSM, XGBoost / LightGBM, MLP and Gaussian Process baselines.
DecisionRecommendation: deeper pilot, more data, different model or stop.

2. Dataset summary

Field groupExample variablesPurpose
Target statetarget pose, target angle, desired positionDefines intended machine behaviour.
Measured stateachieved pose, measured error, correction targetShows physical mismatch between expected and real behaviour.
Operating contextpayload, speed, temperature, surface, cycle countExplains when and why error grows.
Telemetryactuator state, joint current, vibration, retry countImproves response-surface and risk-zone interpretation.

3. Baseline comparison

FERN is compared against strong baselines on the same inputs and the same splits. Values are RMSE (root-mean-square error in N·m — lower is better) on a held-out interpolation test and a high-load extrapolation test. The goal is not to assume FERN wins everywhere, but to identify where it wins and whether the win is useful.

ModelInterpolation RMSEExtrapolation RMSEWhat it tells us
FERN0.1170.155Compact model; accuracy on par with the Gaussian Process at a fraction of the size.
Gaussian Process0.1130.160Strong small-data baseline; best on interpolation.
MLP (64,64)0.1180.163Basic neural baseline.
RSM (degree-2)0.1190.171Classical response surface; weaker under high load.
XGBoost / LightGBM0.1280.174Strong tabular ML; trails on this small, smooth task.

Compute cost and model size on the same task (single CPU; GPR trained on a 2,000-row subsample):

ModelTrain timeInference (600 rows)Parameters / size
FERN1.7 s0.7 ms306 trainable parameters
Gaussian Process74 s26 ms9 kernel hyperparams + 2,000 retained points
MLP (64,64)0.2 s0.3 ms4,801 weights
RSM (degree-2)0.01 s0.3 ms46 coefficients
XGBoost / LightGBM0.3 s2.0 ms500 trees · ~15,500 leaves

FERN matches the Gaussian Process on accuracy while training ~40× faster, predicting ~35× faster, and shipping as a 306-parameter model. This is the compact, CPU-first profile the FERN Box targets.

4. Response surface and risk zones

The report identifies where measured error is stable, where extrapolation becomes weak and which operating regions should be treated as higher-risk until more runs are collected. The output is advisory: it supports the engineer’s decision and does not directly command the machine.

RMSE by model and FERN predicted-vs-measured parity plot

Left: RMSE by model (FERN highlighted), interpolation vs high-load extrapolation. Right: FERN predicted vs measured joint load on the interpolation test set — points on the dashed line are perfect predictions.

Stable zoneKnown operating region with sufficient data density.
Review zoneRegion where model confidence or extrapolation strength should be checked.
Next-run zoneCandidate area where one additional test may reduce uncertainty or error.

5. ROI assumptions

ROI driverCustomer input neededReport output
Engineer timeHours per tuning cycleEstimated saving from fewer setup iterations.
Failed runsCost per failed bench or validation runPotential saving from better next-run selection.
DowntimeHourly cost of delayed cell launch or machine stopDeployment acceleration estimate.
Data privacyConstraints on sending logs to cloudOn-prem / anonymized-data deployment logic.

6. Practical recommendation

The final page gives one of three outcomes: Go if FERN is competitive and useful; Go with more data if signal exists but the dataset is too narrow; or No-Go if standard baselines are sufficient or the data is not a FERN-fit. In this worked example the outcome is a Go: FERN is competitive on interpolation (2nd of five models) and has the lowest extrapolation error of all, in a compact CPU-friendly model.

GoProceed to deeper customer pilot and FERN Box fit review.
More dataCollect targeted runs before product decision.
No-GoUse baseline model or another tool if FERN does not create value.