MALONI: from more affordable humanoid platforms to working robots for European businesses

A more affordable platform opens the door. The complete application creates value.

Humanoid robotics attracts attention with machines that walk, grasp objects or hold a conversation. A business needs an answer to a more specific question. Can a robot repeatedly complete a defined task in its workplace, at an acceptable cost and with an agreed level of supervision? MALONI sees room for its own contribution between an interesting platform and an application defined in those terms. A more affordable purchase option can make a first step easier, but it does not establish an operational result.

Our vision is to connect suitable hardware with application software, integration and local technical coordination. A customer should understand which task can be evaluated, what it will require and how the result will be assessed. Europe is the intended market for this vision; the actual scope of supply, support and relevant permissions must be confirmed for each model, country and project. Documented findings should guide every subsequent step.

What a robot needs to complete a working task

A working application needs several layers to cooperate. Perception must identify the object and its position. Task control must select the next step and check whether it was completed. Movement and manipulation must fit the robot’s reach, gripper and workplace conditions. A connection to a business system may then provide instructions and record the outcome. Each layer has limitations and needs to be evaluated alongside the others; the existence of an interface does not establish that the complete solution works.

Handling errors matters just as much. What happens when the tray is missing, a camera loses its view or a grasp fails? The design must define when the robot pauses, how it requests help and who authorizes a restart. Conversational AI may help with the interface and explanations of the robot’s state. Commands with physical consequences still need controlled permissions and checks of the operating conditions. A language model alone does not establish motion safety.

The lowest-priced configuration may not support development

Selection starts with the available interfaces, documentation and terms of use. For example, Unitree’s official shop states that the basic G1 does not support secondary development and directs buyers who need customization to the EDU edition. Sharing a model name does not necessarily mean sharing the same access to programming. The exact configuration, SDK capabilities, licences and support need confirmation before purchase. Comparing headline prices alone could lead to selecting a platform on which the intended application cannot be implemented.

We therefore use more affordable to describe the search for a suitable starting platform. It is not a promise of a particular price or a claim that every lower-cost platform can be adapted to any task. Some applications may be better served by a robot arm, a mobile manipulator or simpler automation. A humanoid is worth considering where its shape and mobility could help meet the requirements. A comparison with available alternatives must establish whether that advantage matters.

What MALONI is building on today

MALONI’s publicly described work includes a virtual laboratory for a Unitree G1 model in MuJoCo and development involving C++, ROS 2 and existing motion policies. According to the author’s account, a subsequent internal demonstration connects assisted manipulation, Czech conversation and robot vision in a simulation using an Aimoga Mornine model. These records illustrate the direction of software development and provide a more specific starting point than a general expectation of what humanoids might do.

From one defined task to a measured pilot

Consider an illustrative task of moving a standard tray between two defined positions. This is not an account of a project delivered by MALONI. The starting requirements would include the object’s dimensions and weight, how it can be grasped, the workplace layout, variations in the inputs and the existing process. People nearby, possible obstacles and situations that require an operator are equally relevant. Without these requirements, selecting a platform or defining a meaningful test outcome would be premature.

Acceptance criteria need to be agreed in advance. One successful transfer does not show how many attempts failed, how much assistance was needed or how long recovery took. A pilot therefore needs a record of every attempt and its conditions, including failures. Acceptable supervision and required performance depend on the project. MALONI’s direction is to give customers evidence for deciding whether further investment makes sense, including when that decision is to change or postpone the solution.

Handover should also describe the configuration that was evaluated. Changes to the gripper, software or camera position may affect the result and therefore need their own checks. The business should know who can change settings and how to return to the last evaluated version. A pilot record should provide a traceable foundation for operation, fault handling and further development, including the conditions under which the original findings remain applicable.

What a solution needs in a European business

Local language can make operation easier, but usability also depends on clear documentation, training and assigned responsibilities. Before a pilot, the parties need to agree who maintains the software, handles faults and approves changes. Safety must be assessed for the particular application and environment. A stop button or a marking on the platform does not by itself establish that the proposed workplace is suitable. The scope of assessment and documentation belongs in project preparation.

Cameras, microphones and AI connections create further design questions. Which data does the robot need, where will it be processed, will it leave the workplace and how long will it be retained? Who may view recordings or issue a new instruction? Answers should reflect the customer’s requirements and policies before a trial starts. This article does not present local processing or a connection to a particular business system as an existing capability of every platform.

Calculate the cost of the complete solution

Beyond the platform, a budget needs to include grippers, sensors, computing resources, workplace changes, development and integration. Testing, documentation, training, maintenance, any licences and the human time needed for supervision or recovery also matter. Separating one-off expenditure from recurring costs makes the comparison clearer. Only with that view can the proposed application be compared with the current process or a different form of automation.

A lower purchase price may create room for experimentation, but a promotional video cannot establish a return on investment. That requires data from a relevant test and concrete operating assumptions. MALONI’s approach is intended to find feasible uses with measurable value. A sensible project starts with a narrow task, acknowledges the supervision it needs and expands only after evaluation. This can gradually build trust in the application and improve the quality of subsequent decisions.

Frequently asked questions

Is a lower-cost humanoid a ready-to-use working robot?

No. Usefulness depends on the exact configuration, programming access, application and workplace evaluation. The platform price is only one part of the decision.

Is MALONI offering a general-purpose autonomous worker?

This article does not announce such a product. It describes a development direction and a process for finding and evaluating specific working tasks on suitable platforms.

What do MALONI’s simulations demonstrate so far?

They document internal software development under the stated virtual conditions. Physical robot performance, application safety and customer value require further, separate evaluation.

How can a business start?

Describe one repeated task, its environment and its current workflow. Add the main constraints and the expected benefit. That provides a starting point for discussing platform suitability and the scope of an initial evaluation.