Robotics
Robotics at BELTH
BELTH develops the software layer that lets robots understand their surroundings and carry out tasks safely. The hardware comes from manufacturers; we build the intelligence.

Our role
Software intelligence for robotic platforms
A robot only becomes useful once it understands what is happening around it and picks the right sequence of actions by itself. We develop that layer: modular software that turns perception into safe action — independently of who builds the hardware.
- 01Perceive
- 02Localise
- 03Plan
- 04Navigate
- 05Manipulate
- 06Act safely
Robotics
Our robotics domains
Four directions, each at its own stage of development.
01Humanoid Robotics
Modular control software for humanoid robots in the home, care, industry and logistics.
Explore division
02In developmentCare and service robots
Supporting robots that fetch supplies and take pressure off care staff.
03In developmentIndustry and warehouse
Mobile manipulation for production, order picking and internal transport.
04Public Safety & Defence
Inspection, monitoring and situational awareness for critical environments.
Explore division
Autonomy architecture
Designed for efficient autonomy
Most autonomy stacks assume every subsystem has to run at full capacity all the time. We design it differently: heavier intelligence is engaged when the task calls for it, experience is reused where that is sound, and safety keeps its own authority — separate from task reasoning.
- 01
Task-specific compute
Target capabilityNot every action needs the same amount of thinking. The architecture is built so heavier reasoning is engaged when the task requires it, while routine or familiar execution can follow a lighter path. The intent is to avoid unnecessary processing, not to limit capability.
- 02
Experience-based execution
Under developmentA robot should not solve the same problem completely from zero every time. Known objects, known routes and previously successful task execution can be reused to reach a decision faster. Exactly how that knowledge is built and applied is being worked out on the humanoid platform.
Memory accelerates decisions. Current sensing remains authoritative.
- 03
Independent safety
Under developmentTask intelligence can request motion or an action, but it does not approve its own request. A separate safety layer retains the authority to allow, slow or stop, and does not wait for a full AI reasoning cycle to do so. The response to an immediate hazard stays independent of how hard the system happens to be thinking.
AI decides what to do. Safety decides what is allowed.
- 04
Built across robot platforms
Target capabilityThe autonomy layer sits above the manufacturer hardware interface rather than inside it. Communication runs through a robot adapter, so the same architecture can run on a humanoid, a wheeled humanoid, a mobile manipulator or a service robot. The manufacturer does not have to redesign the mechanical robot for it.
One autonomy architecture. Multiple robot platforms.
BELTH autonomy layer
- Orchestration
- Perception
- Localization
- Navigation
- World model / memory
- Manipulation
- Communication
Independent safety layer
- Allow
- Slow
- Stop
Retains authority over every requested motion, independently of task reasoning.
Robot adapter / SDK interface
Manufacturer platform
- Humanoid
- Wheeled humanoid
- Mobile manipulator
- Service robot
- Industrial platform
This architecture is in active development and validation. The maturity of each principle is stated above.
Architecture
Software designed across hardware platforms
Our architecture is not built around one specific robot. The same modules run on a humanoid, a mobile manipulator or a service robot, and are integrated and validated on a partner’s platform together with them.

- Perception
- World model
- Planning
- Navigation
- Manipulation
- Safety
For manufacturers
What this can mean for a robot manufacturer
Architecture choices only matter if they change something about the platform you build. Below is the technical effect of each one, and what it can mean for a manufacturer.
BELTH technology
Technical effect
Manufacturer impact
- 01
Task-specific compute
Technical effect
Less unnecessary heavy processing when the task does not require it.
Manufacturer impact
Potential reduction in compute and thermal requirements, depending on the platform architecture.
- 02
Experience reuse
Technical effect
Familiar objects, routes and tasks can reduce repeated planning and reasoning.
Manufacturer impact
Potentially more efficient execution of recurring tasks.
- 03
Independent safety
Technical effect
A separate local safety authority can override requested task execution.
Manufacturer impact
A clearer and more robust autonomy architecture, with safety separated from high-level task reasoning.
- 04
Robot adapter / SDK
Technical effect
Higher-level autonomy is separated from manufacturer-specific hardware interfaces.
Manufacturer impact
Potentially easier adaptation of the BELTH autonomy layer across different robot platforms or product variants.
These are design goals, not measured results. Integration always requires work on the specific platform. Real-robot compute, energy and performance benchmarks will be published after platform validation.
Collaboration
From software to working robotic systems
BELTH brings the intelligence. For the platform, the integration and the validation we work with manufacturers and integrators.
View partnershipsWe are looking for
- Humanoid robot manufacturers
- Service robot manufacturers
- Industrial robotics
- Mobile manipulators
- System integrators
- Hardware partners
Collaboration models
- Hardware integration
- Validation
- Pilot projects
- Joint development
- Licensing