Back to overview

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.

Concept visual of three BELTH platform variants: a humanoid, a wheeled humanoid and a mobile arm

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.

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.

  1. 01

    Task-specific compute

    Target capability

    Not 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.

  2. 02

    Experience-based execution

    Under development

    A 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.

  3. 03

    Independent safety

    Under development

    Task 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.

  4. 04

    Built across robot platforms

    Target capability

    The 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.

Engineers working on a mobile manipulator beside a simulation workstation
  1. Perception
  2. World model
  3. Planning
  4. Navigation
  5. Manipulation
  6. 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.

  1. 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.

  2. 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.

  3. 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.

  4. 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 partnerships

We 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