SDK Introduction
SDK Overview
The structure of the motion control SDK is shown in the following figure:
Fourier Robotics' motion control framework is built upon a motion control system named Aurora. As the core control module of the robot system, Aurora interacts directly with underlying hardware components on one hand, including various sensors, actuators, and control interfaces, responsible for collecting system state data and sending motion and control commands to the execution layer. On the other hand, Aurora interacts with external systems through a DDS (Data Distribution Service)-based communication mechanism, enabling efficient publishing and subscribing of control commands, state feedback, and system information.
To facilitate user interaction with the Aurora service running within the robot's internal system, we provide a supporting Aurora SDK. This SDK offers unified, abstract interfaces for upper-layer applications, allowing developers to control robot motion behavior, monitor system status, and configure system parameters without directly dealing with underlying communication and hardware details. It supports various application scenarios such as algorithm verification, functional extension, and secondary development.
Furthermore, the Aurora SDK is encapsulated based on Fast DDS and provides an Aurora Client for Python. This client can run on the robot's internal NUC or an external PC, establishing a communication connection with the Aurora service in the NUC via DDS to send control commands and receive system status.
Aurora Introduction
The following is a brief introduction to the Aurora system.
What is Aurora?
Aurora is a system specifically designed for real-time motion control of humanoid robots. It plays a crucial role between the hardware layer and the upper software layer of the robot system. On one hand, Aurora interacts with hardware components such as sensors and actuators, collecting data and sending commands to them. On the other hand, Aurora utilizes a series of tools and libraries to create and execute motion control tasks. These tasks encompass various whole-body controllers for tracking targets such as linear velocity (for locomotion), Cartesian space control (for manipulation), and joint space control (for motion planning).
Aurora provides developers with a series of controllers to support high-level application development. Users can also create their own controllers according to Aurora's programming interfaces.
Centralized Data Structure and Task-Based Programming
Aurora's core features are its centralized data structure and task-based programming paradigm.
During Aurora's lifecycle, most work revolves around the creation, execution, and destruction of tasks. Each task is designed to achieve a specific function, such as reading data from sensors, processing data, or sending data to devices.
Aurora includes two types of tasks: Fixed Tasks and FSM Tasks (Finite State Machine Tasks). Fixed tasks are automatically created and destroyed during Aurora's lifecycle and are used to perform fixed sets of operations, such as reading sensor data, sending device data, and data publishing/subscribing.
FSM tasks can be dynamically created and destroyed during Aurora runtime. They implement a series of motion control operations based on finite state machines. Users can create their own FSM tasks by defining states and transitions and binding them to specified controllers.
Data exchange between tasks is accomplished through a shared data structure called RobotData. RobotData is a centralized data structure shared by all Aurora tasks, containing all the data required for task execution.
For example, a fixed task reads data from sensors and updates the corresponding fields in RobotData; an FSM task reads the current robot state and updates the command fields in RobotData; subsequently, another fixed task reads this command and sends it to the device.
Lifecycle Management
Task lifecycle management is implemented by the state manager. During the initialization phase, the state manager executes the task's init and enter functions. Subsequently, the state manager binds the task's execute function to a new thread and starts that thread to periodically execute the execute function. During the exit phase, the state manager executes the task's exit interface and destroys the thread.
When the Aurora program starts, it first performs a self-check to ensure all necessary hardware components are available; then it creates and starts the state manager, which will create and run all fixed tasks; thereafter, the state manager enters the default FSM state (at which point no FSM tasks are running).
When switching to a new FSM state, the state manager stops the FSM tasks of the current state and destroys their threads, then initializes new FSM tasks based on the new state configuration and creates threads to run them.
When a shutdown signal is received, Aurora stops all tasks, destroys all threads, and shuts down the motor drivers.
Obtaining the SDK
gitee: https://gitee.com/FourierIntelligence/fourieraurorasdk