ORION V2.0 API Reference

The official API reference for the Svan M2 quadruped robot. It details the technical specifications, network interfaces, and data structures required to interface with the robot and retrieve real-time telemetry.

Document: ORION V2.0 API Reference Manual: Svan M2 Quadruped Platform  |  Version: 2.0.0  |  March 2026

This documentation provides the fundamental endpoints and system-level access required by developers and researchers to build custom applications, autonomous behaviors, and advanced control algorithms on the Svan M2 platform.

1. System Architecture & Access Layers

The Svan M2 control interface implements a architecture designed to isolate low-level hardware control from high-level mission planning. This layered architecture accommodates diverse development requirements, categorizing access into two primary operational modes:

1.1 High-Level Control (Teleoperation & Autonomy)

This layer interfaces with the robot's native locomotion controller via predefined state transitions and velocity vectors.

  • Use Case: Direct human-in-the-loop teleoperation or programmatic endpoints for external autonomy stacks (e.g., ROS 2 Nav2, spatial SLAM algorithms).
  • Operational Scope: Allows operators or external mission planners to command global velocity vectors and state transitions while the internal controllers automatically maintain dynamic balance, posture, and gait generation.

1.2 Low-Level Control (Direct Joint Control)

This layer bypasses the native controller entirely to provide direct access to the actuator network.

  • Use Case: Strictly reserved for the implementation of custom control architectures (e.g., Whole-Body Controllers) or Reinforcement Learning (RL) policies.
  • Operational Scope: Requires the developer to stream explicit position, velocity, and feed-forward torque parameters directly to the 12 independent joint drivers inside a strict real-time control loop.
WARNING: Direct Joint Control bypasses controller safety. The developer assumes responsibility for maintaining dynamic stability. A low-level safety check exists at the motor driver, but prolonged high-torque commands can damage the actuator.

2. Method of Communication

To communicate with the Svan M2, users must configure a compatible network environment. The robot publishes state data and subscribes to commands over the Data Distribution Service (DDS) protocol. We support two primary communication methods, which are detailed separately throughout this reference manual:

2.1 ROS 2 (Robot Operating System 2)

The Svan M2 supports ROS 2 distributions (e.g., Humble, Foxy) utilizing the CycloneDDS RMW (ROS Middleware) implementation.

  • Target Application: Users relying on the broader ROS 2 ecosystem for spatial visualization (RViz), data logging (rosbags), and high-level autonomy integration.

2.2 Native CycloneDDS

Developers can interface directly with the DDS layer, bypassing the ROS 2 abstraction.

  • Target Application: Resource-constrained embedded systems, cross-language integrations (C, C++, Python, Rust), and custom high-frequency controllers.

Appendix A: Topic Quick Reference

Consolidated view of all ORION V2.0 communication topics for the Svan M2 platform.

InterfaceROS 2 TopicCycloneDDS TopicMessage TypeDirectionRate
Sensor Data/m2_metal/hw/sensor_datart/m2_metal/hw/sensor_dataxterra/SensorDataRobot → Client~500 Hz
High-Level Control/mission/joystick_datart/mission/joystick_dataxterra/JoyDataClient → Robot200 Hz (mandatory)
Low-Level Control/m2_metal/hw/joint_commandrt/m2_metal/hw/joint_commandxterra/JointDataClient → Robot≥200 Hz (mandatory)

Appendix B: Communication Requirements

ParameterValueNotes
DDS Domain ID0Default domain; must match on both robot and client
Network TopologySame subnetHost and robot must be on the same LAN segment
RMW Implementationrmw_cyclonedds_cppMandatory for ROS 2 pathway
Command Publishing Rate≥200 HzRequired to prevent safety watchdog timeouts
Watchdog Timeout~15 msMotors hold last state on timeout (zero-order hold)
DDS Configurationcyclonedds.xmlMust specify correct NetworkInterfaceAddress

Appendix C: Joint Index Mapping

The following table defines the mapping between array index (0–11) used in both SensorData and JointData messages, and the corresponding physical joint on the Svan M2. This mapping is consistent across all interfaces.

IndexLegJointAxis Convention
0Front-Right (FR)Abduction (HAA)Positive = Abduct outward
1Front-Right (FR)Hip (HFE)Positive = Flex forward
2Front-Right (FR)Knee (KFE)Positive = Extend
3Front-Left (FL)Abduction (HAA)Positive = Abduct outward
4Front-Left (FL)Hip (HFE)Positive = Flex forward
5Front-Left (FL)Knee (KFE)Positive = Extend
6Rear-Right (RR)Abduction (HAA)Positive = Abduct outward
7Rear-Right (RR)Hip (HFE)Positive = Flex forward
8Rear-Right (RR)Knee (KFE)Positive = Extend
9Rear-Left (RL)Abduction (HAA)Positive = Abduct outward
10Rear-Left (RL)Hip (HFE)Positive = Flex forward
11Rear-Left (RL)Knee (KFE)Positive = Extend
Note: Each leg follows the convention: [Abduction, Hip, Knee] with the ordering: FR → FL → RR → RL. The joint ordering convention and axis definitions are hardware-specific to the Svan M2 platform. Verify against the robot's URDF or kinematic model for exact frame conventions.