Who can develop custom software for a Unitree or DEEP Robotics robot dog, and what to ask them
Updated 2026-11-05 · YUANZHI ROBOTICS engineering team
Buyers of a Go2, B2, AS2, Lite3, M20 or X30 discover the same thing a few weeks after delivery: the robot walks beautifully with the remote, and does nothing useful on its own. Autonomous rounds, mapping, reading gauges, reporting to a control room, docking: none of that comes in the box. This guide explains what the manufacturers actually provide, who can build the rest, what each option is good and bad at, how long it takes, and the questions that tell you whether a team has shipped robot-dog software before.
What the manufacturer gives you
Unitree and DEEP Robotics sell the robot, its motion controller, a phone app for manual driving, and an SDK. The SDK exposes motion commands (velocity, gait, stand, sit, recovery), body and joint state, the built-in sensors (the head LiDAR, cameras, IMU) and on the EDU and industrial models a computer you can run your own code on. The SDK is well documented and stable; it is the right foundation. It is not an application: there is no map building, no localization, no route planning, no inspection logic, no dock behaviour beyond what the controller does, and no operator interface beyond the phone app.
The manufacturers do not write site-specific software for customers. They point you to distributors and integrators, which is where the real choice begins.
The five sources of software
- A payload integrator with a running stack. Companies like ours build sensor payloads for these robots and run a navigation and inspection application on them already. Adapting a mature stack to your site is weeks of work, not months, and it arrives installed on the robot with a maintenance path. The limitation is that you are buying their architecture; if you want something structurally different, you pay for custom development on top.
- A university or research lab. Strong on algorithms, often with the exact robot on the bench, inexpensive for a pilot. Weak on reliability, documentation, user interface and support after the student graduates. Right for a research project; wrong for a system that has to run unattended.
- A freelance ROS developer. Can wire the SDK into ROS 2 and get Nav2 or an open-source SLAM running in a few weeks. The result depends entirely on the individual; stairs, docking, failure recovery and a usable interface are where freelance projects stall. Right for a prototype you intend to take over yourself.
- A general robotics software house. Capable, but if they have not worked on a legged robot they will spend your first months learning what an integrator already knows: how the robot behaves on stairs, what the LiDAR sees and does not, how the payload port trips, when the controller refuses a command.
- Your own team. The right answer when software is your product and the robot is a platform. Expect 3 to 6 months to a reliable first version with experienced ROS 2 engineers, and plan for the unglamorous parts: failure handling, operator interface, update procedure, logging.
What takes the time
In our experience the SDK integration is 10 percent of the work. The rest, in order of effort:
- A LiDAR-inertial SLAM setup that gives a clean map and robust localization on a walking robot, including offline map rebuilding with loop closure and removal of moving objects.
- Navigation that handles the places a quadruped is bought for: stairs, narrow doors, slopes, cluttered plant rooms, and recovery when it gets stuck.
- The inspection layer: stored points with robot pose and camera angle, scheduled rounds, readings, alarms and reports.
- An operator interface that a technician accepts: map, route editor, live video, one-button return, clear status.
- Integration with the customer's systems: alarm push, report upload, an API to maintenance software.
- Operations: installation on the robot, updates, logs, remote diagnosis, and a procedure for when the robot does something unexpected on site.
Timelines
Adapting a mature stack to a new robot of a supported model and a new site: 4 to 8 weeks including mapping and point set-up, most of it on site or remote with the customer. Porting a mature stack to a robot model the vendor has not run before: add 4 to 8 weeks for the mount, the interface and the gait tuning. Building from the SDK up with a competent team: 3 to 6 months to a first reliable version, longer if the team is new to legged robots. Research prototypes can be faster but are not comparable.
Questions that separate the experienced from the rest
- Can you demonstrate on my robot model, live: map a room, set two waypoints, navigate, return to the dock?
- Which SLAM and navigation stacks do you use, and what did you have to change in them for a quadruped?
- How is a software update installed on the robot, and how do I roll it back?
- What happens when the robot loses localization, meets a closed door, or runs low on battery mid-round?
- Who operates the robot day to day at your reference customers, and can I talk to them?
- What do I own at the end: a licence, source code, or both, and what do I need you for afterwards?
Ownership and dependence
Three arrangements are common. A perpetual licence per robot for the application with the source of the integration layer (drivers, SDK bridge, API adapter) handed over, which keeps you independent for maintenance. A full source transfer at a higher price, when the software must be yours. Development as a service, where you own what is built and the vendor is a contractor. In every case, insist that the robot is delivered with the software installed, that there is a written update and recovery procedure, and that the configuration (maps, points, routes) is stored in files you can read, so the system does not depend on one person or one company being available.
If you have a Unitree or DEEP Robotics robot and a job for it, tell us the robot model, the site and what the rounds should do; we will tell you honestly whether our stack covers it in weeks or whether it needs custom work, and what that work would be.
FAQ
Does Unitree or DEEP Robotics write application software for customers?
They supply the robot, its controller, a mobile app for manual driving and an SDK (motion commands, state, built-in sensors). Site-specific applications such as autonomous inspection rounds or a control room interface are not part of their offer; they refer customers to integrators and distributors.
What does the SDK let a developer do?
Send velocity and gait commands, read joint and body state, read the built-in LiDAR and cameras, trigger stand, sit and recovery, and on the EDU and industrial models run code on the onboard computer. It does not include mapping, localization, path planning, inspection logic or a user interface; those are built on top with ROS 2 and open-source or proprietary stacks.
Can my own engineers do it?
Yes if they have ROS 2 and robotics experience and 3 to 6 months. The parts that take the longest are not the SDK calls but a robust LiDAR-inertial SLAM setup, navigation that handles stairs and narrow doors, recovery from failures, and a user interface that operators accept. Teams without prior legged-robot experience usually underestimate the last three.
How do I check that a vendor has actually done this?
Ask for a live demonstration on your robot model, not a video: map a room, set two waypoints, have the robot navigate and return to a dock. Ask which SLAM stack they use and what they changed in it, how a software update is installed on the robot, and for a reference customer running the software unattended.
What does ownership look like?
Three common arrangements: a perpetual licence per robot for the application with source code of the integration layer; a full source transfer at a higher price; or development as a service where you own the result. Whichever it is, insist on the robot being deliverable with the software installed and a written update and recovery procedure, so the system does not depend on one person.