How to evaluate robot SDK access and development support
Evaluate SDK access by building and running a small, documented task on the exact configuration you may receive. A repository link or “open SDK” label does not answer whether your team can read the needed state, develop the required behavior, run it on your model, or get help when versions change. Ask for the boundary in writing, then test it.
Clarify what SDK access means
Ask what the phrase “SDK access” includes for the specific SKU, software version, and accessories in the proposal. Separate user-facing actions from developer interfaces. Ask whether your team can read robot status, subscribe to data, call supported high-level actions, build an application, or issue lower-level commands. Also ask what must remain under manufacturer or operator control and what permissions, licensing, training, or account setup apply.
Request an explicit interface map: what is available, what is excluded, which components are optional, and which examples are supported on the delivered configuration. Public code is a useful starting point but does not establish identical access across product packages. AGIBOT’s versioned X2 documentation, for example, describes different secondary-development scopes for X2 Ultra and X2 EDU; verify the exact edition and current documentation before treating an interface as available (AGIBOT X2 product overview).
Inspect documentation and examples
Review the installation guide, API reference, example code, release notes, license, and troubleshooting path before judging development effort. Check the supported model and firmware, operating system, dependencies, network setup, and whether examples cover the task you need. Look for a clear distinction between read-only status access and commands that can change robot behavior.
Unitree publishes SDK2, a Python interface to SDK2, and a separate MuJoCo simulation repository. These sources can help a team inspect the shape of available software, but the offered model and current software versions still need confirmation (Unitree SDK2; Unitree SDK2 Python; Unitree MuJoCo). AGIBOT’s versioned Quick Start walks through secondary development on X2, including setup and sample programs; compare its documentation version with the offered hardware and installed software (AGIBOT X2 Quick Start).
Test the development workflow
Use a defined evaluation: install the documented tools, build an example, connect to the intended system, inspect status, and make a small change that does not exceed the approved test scope. Record the operating system, dependency versions, robot model, firmware, SDK release, network arrangement, error messages, and time spent resolving setup issues. Have the supplier identify any steps that require a credential or support intervention.
Simulation can help test code structure and concepts, but it is not proof that hardware behavior, timing, sensors, firmware, or safety constraints match. Unitree’s MuJoCo instructions distinguish simulation configuration and messages, including a note that a G1 test uses a different message type from the Go2 example. Treat that as a reminder to verify the robot-specific path and keep simulation and physical deployment separate in your records (Unitree MuJoCo). A successful simulation is one evidence item, not hardware acceptance.
Ask how support and updates work
Ask which organization maintains each interface and where developers should report issues. Clarify support coverage, response expectations, escalation route, documentation language, known compatibility limits, and whether assistance is included or separately arranged. For updates, ask how changes are announced, whether compatibility notes are published, how to roll back, and whether updates can affect stored data, custom code, or accessory support.
Ask who is responsible when the robot, SDK, dependency, or network changes. For a classroom or lab, identify the staff member who will maintain the development environment after the original integrator leaves. Do not assume that a public repository provides a service agreement, guaranteed response, or support for every commercial configuration.
Record evidence and open questions
Keep a compact rubric with the question, evidence, configuration, source date, owner, and status. Separate “documented,” “demonstrated,” “tested by our team,” and “confirmed in writing.” Mark unresolved access, version, licensing, training, or support conditions as decision gates. A score can organize discussion, but it is not an objective rating of a supplier.
Before purchase, ask the supplier to confirm that the tested workflow matches the proposed configuration and to list any difference. If the team cannot test before purchase, request a written demonstration plan and acceptance criteria. The useful conclusion is not “SDK included”; it is a specific statement of what your team can do, on which version, with what support and limitations.
Method and limits
This rubric uses official repository and versioned maker documentation to identify questions for an evaluation; it does not confirm compatibility for an unspecified robot package. Test only within the permissions and procedures for the exact system, and have technical staff review access and deployment. Models, software, documentation, and support terms can change. Maker-source check: October 20, 2026.