Back to Humanoid Robotics

Humanoid Robotics

A robot that learns how you live

BELTH is developing household autonomy that goes beyond a fixed list of tasks. The direction is a robot that learns the environment it works in, the routines of the people around it, where things belong and how this particular household prefers things to be done.

Built by BELTH. Shaped by you.

The more it learns, the more it becomes yours.

Concept visual of a BELTH humanoid standing in a modern home interior
Concept visual of a humanoid carrying a tray through a living room

From installation to understanding

First, it learns the home.

A robot that only knows geometry can move through a house without understanding it. The first thing a BELTH robot is designed to build after installation is not a floor plan but a structured picture of the home: which room is which, what the surfaces are for, which objects matter and where they normally belong.

That picture is what later makes an instruction like "put this back" possible at all. Without it, every task has to be spelled out in full, every time.

  • 01Rooms and their function — kitchen, bathroom, bedrooms, hallway
  • 02Fixed structure — doors, tables, cabinets, worktops, the charging station
  • 03Objects that recur in daily use, and the places they belong
  • 04Zones the household marks as restricted or off-limits
  • 05Where a task normally starts and where it normally ends

The home becomes more than geometry. It becomes a structured world the robot can reason about.

Learning from you

Show it. Tell it. Let it learn.

Most household tasks are easier to demonstrate than to describe. The direction BELTH is building toward is a robot you can teach the way you would teach a person: do it once, explain what matters, and let it work out the rest.

"I am going to show you how I water the plants."
  • The person, and what their hands are doing
  • Which object is being used, and where it was taken from
  • Which plants are involved, and where they stand
  • The order the actions happen in
  • The result the task is supposed to produce
  • The constraints that matter — how much water, what must stay dry
Concept visual of a humanoid placing a bottle on a kitchen counter

What the robot is designed to take away

  1. 01Find the watering can
  2. 02Grasp
  3. 03Fill
  4. 04Navigate to the plant
  5. 05Pour safely
  6. 06Verify the result
  7. 07Return the watering can

The goal is not to replay a recorded trajectory. A recorded motion breaks the moment the watering can sits somewhere else. What is being developed is a representation of goal, objects, actions, conditions and expected result — so the same task survives a different day.

Studio concept visual of the BELTH humanoid platform

Interaction

You should be able to see what the robot is paying attention to.

Teaching a machine you cannot read is uncomfortable. The BELTH robot direction includes a head with two clear eyes and an integrated RGB-D camera, and an attention system that makes the robot orient toward whatever it is currently working on.

When somebody speaks

The head turns toward the speaker and the eyes orient with it, so it is visible who the robot is listening to.

When somebody teaches

The robot follows the hands, looks at the object being named, and then at the place it is being taken to.

When something is unclear

It can look back at the person instead of continuing — a visible request for confirmation rather than a silent failure.

This is an interaction system, not evidence of awareness. Visible attention exists so a person can tell what the robot has understood, and correct it early when it has not.

Improvement over time

Teaching is only the beginning.

A task should not stay frozen the way it was first demonstrated. The architecture is being built so that repetition, feedback and outcome verification can refine how a recurring task is carried out.

I showed it this yesterday. Today it does it on its own.

  • Repeated execution of the same task in the same home
  • Feedback from the household — this was right, this was not
  • Which grasps on which objects have worked before
  • Which routes through the home are reliable
  • What to do when a step fails, learned from earlier recoveries
  • Movement that no longer needs to be exploratory
  • Timing that fits the household rather than a default

Personalization

Same platform. Different experience.

Two robots can leave the factory with identical hardware and identical base software, and become functionally different machines — because they have been taught by different households.

Day one

BELTH A

Same hardware. Same base software.

BELTH B

Same hardware. Same base software.

Experience

Months of use in two different households

Months later

Concept visual of a humanoid carrying a tray through a living room

Household A

A house with a garden and a fixed weekly rhythm

  • Which of the eleven plants need water, and how often
  • The kitchen organised its own way — every item back in its place
  • A morning routine that runs before anyone is awake
  • Where the groceries go once they are unpacked
Concept visual of a humanoid placing a bottle on a kitchen counter

Household B

An apartment with two cats and shifting work hours

  • Which rooms the cats may enter, and which door stays shut
  • An evening routine instead of a morning one — tidying starts at 22:00
  • Coats and bags by the door, never in the wardrobe
  • Laundry twice a week, and the litter tray checked daily

Every BELTH starts the same.

None stay the same.

BELTH is being designed so that the same autonomy foundation can become increasingly specific to each household through learned routines, preferences and experience. The hardware does not change. The experience does.

Household memory

Useful because it remembers what matters.

Physical skill is only half of what makes a household robot worth having. The other half is context: knowing what recurs, what is running low and where things ended up. BELTH is developing this as household memory — held for the household, and editable by it.

  • Routines that repeat, and when they normally happen
  • Where objects were last put away
  • Preferences the household has expressed
  • Tasks that come back every week
  • Supplies that are running low
  • Appointments and reminders the household has shared

What this is intended to enable

During an ordinary task the robot notices the detergent is nearly empty.

"I am going shopping."

"The detergent is almost empty — you may want to add it."

This is the direction we are building toward: assistance that is proactive because it has context, not because it has been scripted. It is not a capability available on deployed robots today.

And it gets a name.

"What would you like to call me?"

During setup, the household should be able to give the robot a name of its own. Not to pretend it is a person — to make it easier to speak to, easier to address in a room where more than one thing is listening, and easier to live with.

It remains a machine. But it becomes a machine that knows your home.

Architecture

Learning never overrides safety.

Everything on this page describes a system that changes over time. That is exactly why the safety layer is designed to sit outside it — independent of what the robot has been taught, and authoritative over every physical action.

  1. Learning and task intelligence

    What the household has taught: tasks, routines, preferences, object locations.

  2. Independent safety layer

    Force, speed and distance limits, and the presence of people and animals. Not trainable from the household side.

  3. Physical action

    Nothing reaches the actuators without passing the layer above it.

What the household can teach

  • Tasks and the order of their steps
  • Routines and when they should run
  • Preferences and where objects belong
  • Zones the robot should stay out of

What it cannot teach

  • To move faster or closer around children
  • To ignore a person or an animal in the way
  • To disable collision or force limits
  • To bypass a safety rule because a task would be quicker

When the robot is uncertain, the design is to

  1. 01Stop
  2. 02Look again
  3. 03Ask
  4. 04Retry more slowly
  5. 05Fall back to a safe state

Learning sits above safety. Safety is never trained away.

Privacy and control

Personal should not mean uncontrolled.

A robot that learns a household will encounter things a household would not put online. That is an architectural requirement, not a policy note, and it is being designed in from the start rather than added afterwards.

Local processing where practical

Perception and routine household reasoning are being designed to run on the robot, so ordinary operation does not depend on sending the home elsewhere.

Explicit permissions

What may be remembered, and what may leave the robot, should be a decision the household makes and can revisit.

Different roles in one household

Adults and children should not have the same authority over what the robot learns and does.

Data minimisation

Keep what a task genuinely needs. A robot does not have to record a home to work in one.

Transparency

The household should be able to see what has been remembered about it, in terms it can actually read.

The right to be forgotten, locally

Removing a learned task, a remembered location or a household preference should be a normal operation, not a factory reset.

These are design principles and architecture requirements for a system under development. They are stated here as the standard we are building to, not as a certification of a shipping product.

The technology underneath

Learning is a layer, not a replacement.

None of this works without the autonomy stack beneath it. Learning and personalization consume that stack — they do not stand in for it.

Learning and personalization

Task learning from demonstration, household memory, owner feedback, refinement through experience.

  • Perception and localization
  • Semantic world model
  • Object memory
  • Task planning
  • Navigation
  • Manipulation workflows
  • Recovery logic
  • Independent safety
  • Efficient on-board compute
  • ROS 2
  • Simulation
  • Physical validation
  • Hardware integration

BELTH develops the software layer. The humanoid hardware comes from specialised manufacturers — which is also why this layer is designed to be portable across partner platforms rather than tied to one machine.

Engineers working on a mobile manipulator beside a simulation workstation

Product principles

Five things the product is built on.

These are the commitments the architecture is judged against, in the order they constrain each other.

  1. 01

    Autonomy

    The robot reasons about the physical world and acts in it, rather than following a fixed script.

  2. 02

    Safety

    An independent layer stays authoritative over every physical action, whatever the robot has learned.

  3. 03

    Efficiency

    A task-oriented architecture, so useful work does not require compute and hardware the task never needed.

  4. 04

    Learning

    Experience with a recurring task can improve how that task is carried out.

  5. 05

    Personalization

    Knowledge, routines and preferences become specific to one household rather than generic to a product line.

Autonomy is the foundation. Personalization is the product.

We are building toward household robots that do more than execute a predefined task list — robots that learn their environment, improve through experience and become more useful to the people they live with. If you build humanoid platforms, this is the layer that makes one platform worth choosing over another.