Axinome

Robotics and Physical AI

Robotics intelligence, developed for the real world.

We develop the software that lets robots perceive their surroundings, make decisions and carry out physical tasks. Our work connects applied research in physical AI with practical robotics engineering, and we test what we build on real hardware under documented conditions.

Planning illustrationAn illustrative top-down map of a warehouse floor. A planned path runs between shelving from a start position to a goal, with estimated robot poses and position uncertainty marked along the way and a range-sensor scan at the current position.

From a research question to a working robot

Many robotics results stop at a simulation, a paper or a single demonstration. We organise our work to carry a question through to software that runs on a physical platform, together with the evidence that shows how well it works and where it does not.

That means treating hardware, software, simulation and evaluation as one connected system rather than separate steps.

How hardware, software, simulation and evaluation relate in our workRobot software sits between the physical robot and its simulation, using the same interfaces for both. Data from hardware trials and simulated scenarios flows into evaluation, and evaluation findings feed back into the software.Robot hardwareActuators and sensorsOnboard computingRobot softwarePerception and planningControl and learned policiesSimulationRobot and scene modelsScenarios and synthetic dataEvaluationMetrics and test logsComparison with baselinesSDK and ROS 2interfacesSameinterfacesTrial dataScenario resultsFindings feed backinto the softwareHow hardware, software, simulation and evaluation relate in our workRobot software sits between the physical robot and its simulation, using the same interfaces for both. Data from hardware trials and simulated scenarios flows into evaluation, and evaluation findings feed back into the software.Robot hardwareActuators and sensorsOnboard computingRobot softwarePerception and planningControl and learned policiesSimulationRobot and scene modelsScenarios and synthetic dataEvaluationMetrics and test logsComparison with baselinesSDK and ROS 2interfacesSame interfacesTrial data · ScenarioresultsFindings feed backinto the software
Illustration How hardware, software, simulation and evaluation relate in our work

Applied research

Perception, robot learning, simulation-to-hardware transfer and manipulation, investigated with defined questions and measurable outcomes.

Read about our research

Software engineering

Custom robotics software, ROS 2 integration, sensors, mission tools and deployment, delivered as code your team can maintain.

See engineering services

Validation on hardware

Structured experiments on real platforms, with versioned software, recorded conditions and results that can be traced.

Development and validation in detail

Four connected research themes

Our research agenda follows the capabilities a robot needs to do useful work outside a controlled demonstration. Perception feeds decision-making, learned behaviour is developed in simulation, and every result is judged on hardware. These are current focus areas, not a list of finished results.

  • Robot perception and autonomy

    Sensor fusion, environment understanding, localisation, mapping, navigation and task execution.

    How can a robot keep an accurate, usable model of its surroundings when sensors are noisy, conditions change and parts of the scene are unknown?

  • Robot learning and physical AI

    Learning from demonstrations, reinforcement learning, embodied decision-making and the evaluation of learned behaviours.

    When does a learned behaviour work well enough to rely on in a physical task, and how do we show that with evidence rather than a single successful demonstration?

  • Simulation and transfer to hardware

    Simulation environments, synthetic data, scenario testing and assessing how simulated behaviour transfers to physical robots.

    Which results from simulation can be trusted on a physical robot, and how should simulation be built so that the difference is measurable?

  • Manipulation and human–robot interaction

    Object handling, task planning, operator interfaces and supervised interaction between people and robots.

    How can a robot handle varied objects and multi-step tasks while giving the people supervising it a clear view of what it is doing and an easy way to intervene?

Custom software and engineering

Alongside research, we take on defined engineering work: software and integration that a partner can use, maintain and build on.

  • Custom robotics software
  • ROS 2 integration and middleware
  • Hardware SDK and API integration
  • Sensor and payload integration
  • Mission planning and operator applications
  • Teleoperation, telemetry and fleet coordination
  • Edge deployment and infrastructure integration
  • Experimental tools and evaluation workflows

Typical deliverables include working prototypes, integration software, documented interfaces, experimental datasets, test reports and deployment support.

See engineering services

Simulation render of a ROBOTIS OMY collaborative arm on a laboratory table with test objects.
Simulation render ROBOTIS OMY collaborative arm in an illustrative tabletop workcell. Simulation render by Axinome; not a photograph of an Axinome facility.
Rainbow Robotics RBQ-10 quadruped robot shown standing, with a LiDAR sensor mounted on its back.
Manufacturer image Rainbow Robotics RBQ-10. Third-party hardware, shown as a reference research platform. Image: Rainbow Robotics.

Research across robot types

We keep task software separate from platform-specific code, so that work developed on one robot can be carried to another. The platform is chosen to suit the question: legs for rough terrain, wheels for long indoor routes, arms for handling objects.

The Rainbow Robotics RBQ-10 quadruped is one of the reference platforms we design our mobility and inspection work around. Rainbow Robotics makes the robot; our contribution is the software, sensing, mission integration and evaluation built on top of it.

  • Quadrupeds

    Mobility on stairs, slopes and uneven ground; inspection rounds; sensor research in outdoor and industrial spaces.

  • Wheeled robots

    Autonomous navigation, indoor logistics and long-duration operation on flat floors.

  • Manipulators

    Grasping, placement, assembly steps and other tabletop or workcell tasks.

  • Mobile manipulators and humanoids

    Embodied task research that combines moving through a space with handling objects in it.

View platforms

How we develop and validate

Each project follows the same sequence, and the last step usually leads back into development. Results are recorded against the software version and the conditions under which they were measured.

  1. Define the problem

    Agree on the task, the operating conditions and what success means, in terms that can be measured.

  2. Establish a baseline

    Measure how the task is done today, or how a simple reference method performs, so that improvement can be shown.

  3. Develop and simulate

    Build the software and test it in simulation and on recorded data, where failures are cheap.

  4. Integrate hardware

    Bring the software onto the physical platform with its sensors, payloads and onboard computing.

  5. Test in representative conditions

    Run structured trials in conditions that resemble the intended use, first in the laboratory and then on site where agreed.

  6. Evaluate and refine

    Compare results with the baseline, document what did and did not work, and decide what to change next.

Evaluation findings return to development until the agreed criteria are met or the limits are understood.

What a project may measure

Task completion rate
Share of trials in which the task is completed to the agreed standard.
Navigation reliability
Distance or time between navigation failures, and the causes of each failure.
Intervention frequency
How often an operator has to step in, and how long each intervention takes.
Perception accuracy
Error of detection, localisation or mapping against a measured reference.
Response latency
Time from a sensor event or command to the robot’s response.
Repeatability across test conditions
How much results vary across repeated trials, lighting, surfaces, objects and operators.

Examples of evaluation criteria we agree with partners. They describe what can be measured, not results we report.

Where this work applies

Potential applications that match our research themes. They describe problems we are equipped to work on, not completed customer projects.

  • Manufacturing and material handling

    Parts and materials still move between stations by hand, especially where products vary and layouts change.

  • Infrastructure inspection and condition monitoring

    Plants, tunnels and utility sites require regular inspection rounds that are repetitive and sometimes hazardous.

  • Warehouse navigation and logistics

    Warehouses change daily: aisles are blocked, pallets move and people share the floor with machines.

  • Hazardous-environment observation

    Some sites are unsafe or impractical for people to enter for routine observation.

  • Research and education platforms

    Laboratories and teaching groups need robots that students and researchers can program, test and compare.

Joint research and development

We work with universities, research institutes, hardware manufacturers and industrial organisations on projects with shared objectives, clear responsibilities and agreed handling of data and intellectual property.