Humanoid robot for research labs: the AGIBOT X2

A lab buying a humanoid is not buying a demo. It is buying an instrument that students will write code against for three or four years, that a PhD project will still be running experiments on after the grant that paid for it has closed, and that has to survive being handed to a different research group every semester. That changes what matters. A machine that looks impressive doing a fixed routine is worth nothing to a lab if nobody in the building can get inside it.

The SDK decides whether it is a platform at all.

AGIBOT publishes the X2's control layer, AimDK_X2, in both Python and C++, and its table marks customer-side development as supported on the X2 Ultra and not supported on the X2 Basic. That is the difference between a robot a lab can build coursework and papers on and a robot that performs a fixed set of tricks nobody can extend. Python gets a masters student from a working idea to a running experiment in an afternoon; C++ is what a lab needs when the experiment becomes a real-time control loop, and having both in one SDK means the same machine serves an introductory HRI course and a locomotion PhD without a rewrite in between. A closed stack with a demo mode answers neither question, however good the demo looks.

Degrees of freedom and reach are what decide the research questions the platform can actually support

, not a specification to admire. The X2 Basic runs 25 active degrees of freedom at 35 kg; the X2 Ultra runs 30 active degrees of freedom at 39 kg. Both publish an arm reach of 558 mm and a payload of up to 3 kg in specific postures and 1 kg or less across the full range. A lab running human-robot interaction studies on the behaviour it ships with is asking questions the Basic's 25 degrees of freedom answer directly. A lab whose research is manipulation, grasping under a learned policy, bimanual coordination, needs the Ultra's extra five degrees of freedom to even pose the experiment: fewer actuated joints is not a smaller version of the same study, it is a different study.

The two tiers map onto two kinds of lab, and that is the first decision to get right.

The Basic pairs with demonstration and HRI work that runs on what it ships with. Customer-side development is not supported on it, so a course in which students program the robot needs the Ultra. The Ultra pairs with perception and manipulation research that runs a learned policy onboard, on the NVIDIA Orin NX at 157 TOPS, walking at up to 1.8 m/s. If a lab's roadmap has a policy running inference on the robot rather than on a bench PC feeding commands over a link, the Orin NX budget is the number that decides whether the Ultra can carry it.

What the catalogue does not publish is worth naming.

AGIBOT's X2 manuals list more than 20 preset actions the robot performs on a voice command, and those exist for demonstration, not for a research programme; a lab building a thesis on top of a preset routine has built it on the wrong layer of the stack. There is also no published benchmark for either tier's manipulation success rate or grasp reliability on arbitrary objects: that number does not exist in any source available here, and a lab that needs it has to generate it itself, which is exactly what the SDK is for.

Two questions settle which tier and how many units a lab actually needs: does anyone need to run their own code on the robot, which AGIBOT's table supports on the Ultra only, and does the curriculum need one unit shared across a semester or several running in parallel. A one-week rental answers both before a purchase order is written: the Basic rents at 1500 EUR per week, the Ultra at 2500 EUR per week. That is cheaper than guessing, and faster than waiting on a specification sheet to answer a question it was not written to answer.