Understand robot specifications
Read a specification as a list of questions to test, not as a scorecard. Degrees of freedom, sensors, compute, and SDKs describe parts of a system; they do not guarantee that a particular task will work. Match each listed value to the exact model and configuration, then ask what evidence connects it to the job you need done.
Degrees of freedom are not a task score
Degrees of freedom (DoF) describe independent ways a mechanism can move. They help explain its possible motion, but do not tell you whether it can reach a target from your setup, grasp your object, hold a pose, move within a required time, or recover from error. Those questions also depend on joint ranges, geometry, control, end effectors, loads, software, and conditions.
The Modern Robotics chapter derives DoF from the freedoms and constraints in a mechanism, including why constraint assumptions matter (Degrees of Freedom of a Robot). Treat a count as a description that needs a counting convention. Unitree lists 23 total DoF for G1 and a 23–43 range for G1 EDU; AGIBOT’s versioned X2 documentation lists 30 for X2 Ultra, 29 for X2 EDU, and 31 for a newer X2 Ultra version (Unitree G1; AGIBOT X2 product overview). These maker-listed values are configuration-specific. Do not rank them directly across unlike models or counting conventions; verify which joints and options the delivered configuration includes.
Sensors describe inputs, not guaranteed outcomes
A camera, depth sensor, lidar, microphone, or inertial sensor tells you what information may enter a system. It does not establish that the robot will recognize the relevant object, locate it accurately, work in your lighting, or respond correctly when something changes. Sensor placement, field of view, calibration, software, compute, and environmental limits affect the result.
Ask what the full perception path does with each input. Which output is available to your application? What conditions have been tested? How does the system report uncertainty or loss of input? Does the delivered configuration include the sensor and software shown in the demonstration? Ask who can inspect the data path and what information is stored or transmitted. Treat “has a camera” as an inventory fact, not as proof of a vision capability.
Compute depends on workload and deployment
Processor names and memory figures matter only in relation to the software workload. Identify the task’s runtime needs: control frequency, perception pipeline, simulation, model inference, logging, and any external computer or network service. Confirm which processes run onboard, what needs a separate computer, and what happens if a network link drops. Ask for the supported operating system, software versions, thermal or runtime limits relevant to your use, and a reproducible example on the offered configuration.
Configuration differences can change the answer. AGIBOT’s X2 documentation lists different compute and sensor equipment for Ultra and EDU editions, along with different secondary-development scopes. That is a reason to verify the part number and documentation version on a proposal, not to infer that an interface or workload is available across the whole X2 line (AGIBOT X2 product overview).
SDK access has levels
“SDK included” can refer to very different access. A user application may expose preset actions; a high-level interface may expose supported tasks; a development kit may allow status queries or application logic; lower-level interfaces may expose joint commands or other controls. Each level brings distinct permissions, training, maintenance, and risk questions. Ask what your team may read, change, build, and run, and under which license and support terms.
Public repositories are useful evidence about available code, not proof that every product configuration supports every interface. Unitree publishes SDK2 and a Python interface to SDK2; its separate MuJoCo repository contains simulation examples. Confirm SKU, firmware, supported messages, accessories, and access with the maker or supplier (Unitree SDK2; Unitree SDK2 Python; Unitree MuJoCo).
Read specifications with a test plan
For each requirement, write the specification, the question it raises, and the evidence that would answer it. For example: “sensor listed” leads to “can the delivered system detect this object under our stated lighting?”; “SDK available” leads to “can our developer build and run the documented example on this SKU and firmware?” Use a simple status such as verified, unresolved, or not applicable, with a source and date.
Then test the complete use case. Include the exact accessories and software version, a defined start state, observable success conditions, expected operator actions, and failure recovery. Keep marketing descriptions, manual statements, demonstration results, and your own test observations distinct. A specification can guide a test; only the test can answer whether the requirement is met in your setting.
Method and limits
This explainer uses an academic robotics lesson and maker documentation to show why specifications need context. Listed values are not cross-vendor performance comparisons, and repository availability does not establish that a particular SKU supports an interface. Ask qualified technical staff to validate configuration and integration, and institutional reviewers to assess deployment conditions. Models and document versions can change. Maker-source check: October 20, 2026.