Overview¶

Flexiv RDK enables the users to connect their own workstation PC to one or more Flexiv robots via Ethernet (TCP/IP) connection and gain real-time or non-real-time access to the robot(s). Customized user programs can be created for easy integration with external software and hardware modules, such as additional sensors, industrial control systems, vision and perception units, digital I/O devices, other software libraries, etc.

Compatibility¶

Supported OS	Supported processor	Supported language	Required compiler kit
Linux (Ubuntu 20.04/22.04)	x86_64, arm64	C++, Python	build-essential
macOS 12 (Monterey)	arm64	C++, Python	Xcode Command Line Tools
Windows 10	x86_64	C++, Python	MSVC 14.0+

API access overview¶

The above supported OS and programming languages can form various [OS - language] combinations, and each combination is called an interface. For example, Linux Python interface and Windows C++ interface. In RDK, API access varies by interface: the Linux C++ and macOS C++ interface have full access to all APIs, while the other interfaces have partial access:

	C++	Python
Linux	Full	Partial
macOS	Full	Partial
Windows	Partial	Partial

More details can be found in RDK Library.

Real-time (RT) access¶

RDK provides real-time access to the robot: user commands and robot states are exchanged between the workstation PC and the robot at 1kHz with less than 1ms latency. Real-time commands, with the help of RDK’s integrated scheduler, can be generated from user programs running on the workstation PC to gain low-level control of the robot. The available real-time controls are:

Joint torque control (with compensation of nonlinear dynamics)

Joint position control (with compensation of nonlinear dynamics)

Cartesian pose control (with compensation of nonlinear dynamics)

Note

Nonlinear dynamics include gravitational, frictional, centrifugal, and Coriolis force/torque.

Note

How to identify methods that provide real-time access? They are always affiliated to one of the Real-time (RT) control modes.

Non-real-time (NRT) access¶

RDK also provides non-real-time access to the robot: users can send high-level operation instructions to utilize the robot’s plan/primitive pool, or discrete motion commands to leverage the robot’s internal motion generator that automatically smoothens the trajectories. In such case, all real-time computations are done by the robot, thus the requirements for network connection and workstation PC’s performance can be relaxed. The available non-real-time controls are:

Discrete joint position control (with internal motion generator plus compensation of nonlinear dynamics)

Discrete Cartesian pose control (with internal motion generator plus compensation of nonlinear dynamics)

Plan execution

Primitive execution

Digital IO control

Auxiliary instructions like enable, stop, auto-recovery, etc.

Note

How to identify methods that provide non-real-time access? They are the ones that are not affiliated to any real-time modes.

Feedback states¶

Despite the operations of the RDK client, feedback states are always published from the robot server at 1kHz. They include:

Measured joint-space states: joint position, velocity, and torque

Computed Cartesian-space states: TCP pose, velocity, and acceleration

Estimated states: external joint torque and external TCP wrench

System status: emergency stop, digital IO, fault state, etc.

Note

Although these states are updated and published by the robot server at 1kHz at all time, the actual frequency at which they are accessed is controlled by how fast the user calls flexiv::Robot::getRobotStates(). In addition, feedback delay is affected by the actual network latency.

Example workflow of a complex user application¶

A complex and highly customized user application usually requires a series of different operations from one or more robots and a user-defined state machine to manage the operations. This process can be achieved through the combination of various RDK APIs.

Using information obtained from sources like external sensors, digital inputs, robot states, etc. of one or more robots, check conditions can be created to trigger transitions in the user state machine, which will then put the robot(s) into suitable modes and issue commands accordingly. Below is an example workflow:

In one user program, two RDK library instances are initialized to establish connection with robot A and B respectively via two network cards, and both robots are enabled and operational.
Robot A task 1: go home. This is a unit skill (primitive) that the robot already knows, then Primitive execution mode can be used here. Refer to Primitives for more details on available unit skills and actions. When the termination condition is met for this task, the user state machine commands robot A to stop and wait for further instruction.
Robot B task 1: when robot A is stopped, compliantly follow the output from a user-defined real-time trajectory generator with user-specified stiffness. A tray is mounted on the end effector, and a cube with an april tag on it is in the tray. For this task, it’s best to use the RT Cartesian motion-force control mode. Thus the user state machine will first set robot B into this mode, then continuously command target pose to it.
Robot A task 2: assuming a camera is mounted on robot A and the user has implemented an april tag tracker program that can provide RDK with the grasping pose based on the estimated tag pose, when the camera on robot A sees the cube with april tag from robot B, the user state machine commands robot B to stop, then commands robot A to grasp that cube. In this case, the MoveL primitive can be used to command robot A to smoothly move to the grasping pose, then use methods from the flexiv::Gripper API to control a gripper to finish the grasping.
Robot B task 2: …