Skip to content

Unitree Robotics integration

Unitree Robotics and workflow gaps

Unitree Robotics builds quadruped and humanoid robots with SDKs for movement control. Their hardware covers inspection, security, and research. But like most robotics platforms, they focus on hardware control - not operational workflow management. That’s where Tallyfy could fit in.

Robot platforms

Quadruped robots:

  • Go2: Consumer quadruped with AI vision (Air, Pro, and Edu variants)
  • B2: Industrial quadruped for inspection and security
  • A2: Industrial model, 100kg load capacity, 20km range
  • B2-W: Hybrid wheeled and walking modes

Humanoid robots:

  • G1 Basic: Entry-level, remote-controlled home use
  • G1 EDU Standard (U1): 100 TOPS AI computing, 23 DOF, programmable
  • G1 EDU Plus (U2): Enhanced waist (3 DOF) and 7 DOF arms (29 total DOF)
  • G1 EDU Ultimate A (U3): Dex3-1 three-finger hands (43 DOF)
  • H1: Research-focused humanoid

Software and SDKs

Development SDKs:

  • unitree_sdk2: C++ SDK for Go2, B2, H1, G1 using CycloneDDS
  • unitree_sdk2_python: Python interface
  • unitree_legged_sdk: SDK for Aliengo, A1, Go1, B1 models
  • ROS/ROS2: Native robotics middleware support
  • Simulation: MuJoCo and Isaac Lab for virtual testing

Control features:

  • Low-level motor control and custom gait development
  • UDP and DDS communication protocols
  • SLAM for mapping and autonomous navigation
  • Computer vision with NVIDIA Jetson (EDU models)

Where these robots get used

Industrial inspection:

  • Thermal power plants for equipment monitoring
  • Petrochemical plants in hazardous zones
  • Power grid substations
  • Brewery operations for routine checks

Logistics and warehousing:

  • Material handling and transport
  • Inventory monitoring
  • Warehouse security patrols

Agriculture:

  • Seedling monitoring
  • Terrain assessment and mapping

Research:

  • Academic programs
  • Carnegie Mellon SoFTA project (stable manipulation while walking)
  • Caltech/UT Austin SHIELD safety framework testing

Healthcare and service (emerging):

  • Supply delivery assistance
  • Patient monitoring support

What’s missing: workflow management

Here’s where Unitree’s platform falls short for operational use.

Procedure programming: Robots run hardcoded Python or C++ scripts deployed individually via SSH. When procedures change, engineers must update code, test in simulation, and redeploy to each unit. That’s slow.

Knowledge sharing: There’s no built-in way to share learnings across a fleet. If one robot discovers a better approach, it stays isolated unless someone manually codes and deploys the fix to every other unit.

Operational tracking: Unitree provides telemetry (battery, location, sensors) but not process-level tracking. There’s no native way to log which procedures ran, when tasks finished, or maintain audit trails.

Multi-robot coordination: Each robot runs its own code version independently. Nothing manages what procedures are deployed where or keeps fleets consistent.

How Tallyfy could fill these gaps

Dynamic procedures: Instead of hardcoded scripts, robots could query Tallyfy’s API for current procedures. When inspection methods change, updates reach all robots without redeployment.

Shared knowledge base: Robots could pull standardized operating procedures from Tallyfy templates. Document a new equipment type once, and it’s available fleet-wide.

Process tracking and audit trails: Robots could launch Tallyfy processes and mark tasks complete with sensor data, photos, and timestamps - creating compliance records automatically.

Fleet-wide updates: Changes to SOPs update centrally rather than requiring individual code deployment to each robot.

Possible integration architecture

A connector between unitree_sdk2 and Tallyfy’s API could work like this:

Diagram

What to notice:

  • The connector bridges unitree_sdk2 and Tallyfy’s REST API
  • Procedures live centrally, not in robot code
  • Every operation gets logged for compliance

Conceptual code example:

# Hypothetical connector - no official integration exists
from unitree_sdk2_python import Robot
import requests
robot = Robot()
api_key = "your_tallyfy_api_key"
# Fetch procedure from Tallyfy
response = requests.get(
"https://api.tallyfy.com/procedures/solar_inspection",
headers={"Authorization": f"Bearer {api_key}"}
)
procedure = response.json()
# Execute steps and report completion
for step in procedure['steps']:
sensor_data = robot.collect_data(step['location'])
requests.post(
f"https://api.tallyfy.com/tasks/{step['id']}/complete",
headers={"Authorization": f"Bearer {api_key}"},
json={"sensor_data": sensor_data}
)

Example use cases

Site-specific inspections: Robots fetch the right inspection procedure from Tallyfy for each site. When equipment types change, procedures update centrally - no robot code changes needed.

Warehouse fleet coordination: Multiple robots reference the same Tallyfy procedures for patrol routes, inventory checks, or security protocols. One update reaches every robot.

Research reproducibility: Academic labs could share experimental protocols through Tallyfy templates. Each robot runs identical procedures with automatic data logging.

Regulated industries: In pharmaceutical, food safety, or other regulated operations, robots could log every procedure step, timestamp, and sensor reading in Tallyfy for regulatory review.

What you’d need

On the Unitree side:

  • Compatible models: Go2, B2, A2, G1, H1
  • Network connectivity (WiFi or cellular)
  • Python environment for connector code
  • unitree_sdk2 or unitree_sdk2_python installed

On the Tallyfy side:

  • Organization account with API access
  • Templates set up for robot procedures
  • API credentials

Technical factors to consider:

  • Custom connector middleware needs to be built
  • Network latency matters for real-time API calls
  • Robots need fallback behavior when connectivity drops
  • Data formatting between SDK output and Tallyfy’s API

Robotics > AppTronik Apollo integration

Tallyfy could serve as a centralized workflow and procedure management layer for Apptronik’s Apollo humanoid robots by connecting through a ROS bridge to the robot’s control system and filling gaps in fleet-wide task coordination and dynamic procedure updates and compliance documentation that Apollo’s current static programming and individual robot configuration approach does not address on its own.

Robotics > KUKA Robotics integration

Tallyfy can serve as a workflow and procedure management layer above KUKA’s industrial robot fleet — spanning models from 6kg collaborative arms to 1300kg heavy-duty systems — by providing centralized SOP documentation and audit trails and fleet-wide process visibility that KUKA’s native motion control and KRL programming tools don’t handle on their own.

Robotics > Universal Robots integration

Universal Robots makes collaborative robots with strong motion control and visual programming through PolyScope X but struggles with static program files stored locally on each controller which creates real problems for fleet-wide version management and cross-robot knowledge sharing and lacks compliance audit trails linking operations to validated SOPs — gaps that a workflow management integration could address through centralized procedure libraries and dynamic step querying.

Integrations > Robotics

Integrating robot systems with human workflows requires bridging proprietary control protocols like OPC UA and ROS2 through middleware and edge computing while maintaining strict OT/IT network segregation and safety compliance across manufacturing and logistics environments.