Update, 6 November 2026: This article records the previous MuJoCo showroom stage. According to MALONI’s new internal summary, the showroom now runs on an in-house simulation engine without the MuJoCo runtime. The details and scope of internal verification are covered in the new article about the in-house simulation engine.
This project makes the approach in From humanoid platforms to working robots more concrete: define a task, build application software and verify progressively what works. A dealership offers a clear setting in which communication, visitor decisions and movement must connect.
A visit to the virtual dealership
The scenario starts by identifying a visitor’s needs and selecting a displayed car. The assistant then accompanies the visitor to a presentation position and introduces the selected vehicle. Optional activities and a salesperson summary complete the visit. The transitions matter: receiving a presentation command should not start the presentation before the robot reaches its destination.
Development also covers interruptions. A visitor may ask a different question during a presentation, or an operator may interrupt and restart the scenario. Simulation makes these situations repeatable without organizing real dealership visits. The resulting summary remains information in the panel: showing it does not establish a CRM connection or actual delivery to a salesperson.
MALONI’s environment and scenarios, existing technology foundations
MALONI contributes environment design, integration and the application logic of the visit. The project builds on MuJoCo, a Unitree G1 model, an existing ONNX walking policy and calibrated velocity control. MALONI did not create those foundations. Its own work connects them to an assistant task and handles transitions between the steps.
According to the supplied documentation, the scene contains third-party visual models of the BMW X1 2013, Volvo XC60 Recharge 2023 and Chery Tiggo 8 Pro 2023. These are not MALONI CAD models, nor confirmation of current vehicle availability, prices or equipment. They provide a setting for scenario development. A future commercial application would need verified information from the individual dealership.
For an operator, the useful perspective is the whole visit rather than an isolated robot response. Where should assistance start, what should a visitor decide and when should a salesperson take over? A specific brief can describe these steps before hardware selection. Adapting to another dealership brand would require more than replacing a logo: vehicle information, the space and customer handover rules would all need another review.
Dialogue does not set joint positions
The development documentation separates dialogue and visit logic from low-level motion control. Requests pass through a command queue into the control loop. A language model therefore does not directly set robot joints. A visitor’s question, the presentation state and an ongoing movement belong to different parts of the system whose coordination must be checked.
Navigation uses a known static map. It takes a direct line-of-sight route when available and uses A* planning for more complex paths. Simplified collision envelopes represent obstacles separately from detailed visual geometry. Planning therefore does not need every detail of a car body or furnishing. This describes navigation in a known virtual scene; it is not evidence of dynamic avoidance of real customers.
A web panel for development work
The web panel supports operation and state monitoring, letting the developer work through a visit and observe its current stage. Text dialogue runs locally; voice features are optional. Current documentation describes an English scenario and support for older Czech text commands. This does not establish verified Czech voice operation from microphone input through processing to the assistant’s response.

Historical tests and the work still ahead
The internal documentation records 37 successful showroom tests on 23 October 2026, including dialogue scenarios and control. This is a historical internal result taken from the supplied material. It was neither repeated nor independently verified for this article. It is not presented as the current test count of today’s version or as an operational reliability measurement.
Reported cases include a complete visit, presentation interruption, rejection of a premature presentation, reset, connection loss and navigation routes. These help examine behavior beyond an ideal sequence. The records also state that a live microphone, cloud voice and the complete graphical workflow were not fully verified together end to end. Passing component tests cannot establish verification of the whole application.
Simulation supports returning to the same task and finding errors before hardware trials. It does not itself establish operational safety, physical robot capabilities or deployment readiness. Moving into a real space requires separate checks of movement, perception of people and obstacles, interruption behavior and supervision rules. Those trials can provide a basis for deciding on a specific pilot.
AiMOGA as a direction, hotels and shops according to demand
“We are developing our own solution with the aim of adapting it to dealerships of different brands. Depending on demand, we also want to prepare simulation environments for hotels, shops and other services. We currently use G1 in simulation, but want to specialize in AiMOGA in the future,” says Rostislav Sikora. Universal means intended adaptability to different customers, rather than completed compatibility with every robot, system or operation.
Transferring control and scenarios to a real AiMOGA robot is not yet an evidenced result of this project. This is not a customer installation, a digital twin of a particular real dealership, a carmaker commission or joint development with Chery or AiMOGA. MALONI’s own design is intended as a foundation for further adaptation, with scope determined by the task, available interfaces and verification results.
Other services would also need a defined use case. A hotel brief might start with helping a guest find their way, and a shop brief with accompanying a visitor to a selected department. These are discussion examples, not announced finished features. Each environment brings different routes, information and situations requiring staff; a dedicated simulation is intended to capture these differences in a scenario first.
If you operate a dealership, hotel or shop and are considering a humanoid assistant, describe the visit, premises, languages, required information and handover to staff. Include the situations in which a person should take control. This supports a discussion of the scenario and first verification steps. It opens a specific development discussion; it is not a promise that a finished solution is available.
Related development and project preparation
More humanoid programming examples
- MALONI has an in-house humanoid simulation engine. Its virtual showroom runs without MuJoCo
- Aimoga Mornine in a CHERY showroom: a MuJoCo simulation
- MALONI Humanoid: Czech conversation and robot vision in MuJoCo
- Programming the Unitree G1 humanoid in MuJoCo simulation
- Unitree G1: Autonomous Object Transfer in Assisted MuJoCo Simulation
- Unitree G1 in MuJoCo: Motion Control and MALONI Software Development
- Unitree G1 at MALONI Robotics: Building Our Own Humanoid Robot Simulation Laboratory
Sources and further reading
- MALONI: from humanoid platforms to working robots ↗MALONI Robotics · 5 November 2026
- Unitree G1 simulation laboratory in MuJoCo ↗MALONI Robotics · related in-house development
The technical account comes from internal development documentation summarized by Rostislav Sikora in material supplied for this article on 5 November 2026. The complete documents and current showroom code were unavailable during preparation; their claims and historical tests were not independently reproduced. The WebP is an actual development screenshot of the simulation controls, reused from previously published MALONI material. It does not show a physical deployment.