01 / Platform Robotics
Mobile manipulators and service robots operating beside people in unstructured environments.
- Perception
- Motion planning
- Human safety
Research effort
Intelligence where milliseconds decide
Fusiores explores a single question: how can the latency of local AI models — and of everything around them — be reduced without losing reliability and safety? This site documents where that work currently stands.
Target figures
These values describe the target range of the research — not measured product properties.
- Response time
- < 10 ms Response time Target for the closed control loop
- Local
- 100 % Local No cloud step in the decision path
- Power budget
- < 15 W Power budget Typical embedded target profile
- Status
- Open Status Work in preparation, not a finished system
Starting point
Autonomy begins where the network ends
Systems that move through the physical world cannot wait for an answer from a data center. An exoskeleton catching a fall, a rotor countering a gust, a manipulator working beside a person — each needs perception, judgement and reaction inside a single closed control loop.
Local models solve the network problem, but they relocate it: on embedded hardware every convolution, every memory access and every context switch costs time. Pushing latency down invites shortcuts that weaken exactly what matters here — dependable behaviour in the exception. That tension is where Fusiores works.
Visual — Embodied Platform Requirements
Four constraints
What a system has to be measured against before it is allowed into the physical world.
- 01
Real-time inference
What matters is the upper latency bound, not the mean. In a control loop a rare outlier is not noise — it is a failure case.
- 02
Data sovereignty
Sensor data never leaves the device. Processing, model and state remain entirely under the operator’s control.
- 03
Functional safety
Defined fallback levels and traceable behaviour. A speed-up that cannot be explained is not an improvement.
- 04
Energy efficiency
Quantisation, pruning and hardware-level kernels — models in the watt range instead of the kilowatt range.
Domains
Embodied systems
The platforms where this question becomes practical.
01 / Platform 
02 / Platform Unmanned aviation
Drone platforms with local navigation, obstacle detection and mission logic without a radio link.
- Navigation
- GNSS-denied
- Onboard vision
03 / Platform Exoskeletons
Wearable assistance systems that read movement intent in milliseconds and transfer force safely.
- Intent detection
- Force control
- Biomechanics
Research approach
How the question is worked on
Four steps that repeat throughout the work.
- 01
Measure
First make visible where the time actually goes — model, memory, scheduling or sensors. Without solid measurement on the target hardware, every optimisation is guesswork.
- 02
Compress
Quantisation, structured pruning and distillation shrink the model. The interesting part is less the speed-up than the question of which behaviour is lost along the way.
- 03
Integrate
The biggest lever is often not the model but the pipeline around it: hardware-level kernels, memory layout and how the whole thing sits inside a real-time operating system.
- 04
Validate
Hardware-in-the-loop and endurance testing show whether the speed gained holds up in the exception — and where a fallback level is needed.
Exchange
Interested in the topic?
This site sells nothing and currently offers no services. Questions, pointers from practice or a prototype to test on are welcome at any time.