BURT Research - System Overview - Documentation

BURT-Research offers a Research Environment that comprises two libraries, BurtSharp and BurtSharp.UnityInterface, and a Medical demo application. Figure 1 shows a high-level physical and software architecture overview of the BURT system.

Figure 1: BURT system overview.

BurtSharp is a client program to communicate with the Mainboard firmware through a CoAP/UDP-based server to control the BURT robot. BurtSharp provides the ability to monitor and respond to robot state information (position, configuration, fault states, etc.), basic control functions to specify robot behavior, and an interface to provide this functionality to Unity games. The BurtSharp control library is not real-time as it is built on top of Linux, which is not inherently real-time. BurtSharp uses similar communication protocol like ROS. Even though is fast, it is inherently best-effort in many cases and does not provide guarantees about the timing of control operations. ROS utilizes TCP/IP communication which is not able to achieve real-time communication over Ethernet. Although, BurtSharp uses the Constrained Application Protocol (CoAP) which was developed for devices constrained in terms of processing capabilities and power.

CoAP protocol

CoAP (​http://coap.technology/) communicates based on Representational State Transfer (REST) architecture and supports four modes of REST which are PUT, GET, POST, and DELETE. A client sends a request with any one of the four modes and the server will respond with a reply in accordance with the request. The CoAP supports two modes: reliable and non-reliable. For instance, we use the reliable mode for activating the robot and non-reliable mode for sending force data. Reliability in CoAP is handled by using Confirmable (CON) messages. For every CON message send to the server, this will be replied by Acknowledge (ACK) packages to the client. In essence, CoAP's job is to define the URI structure (a hierarchy of objects accessible by GET/POST); handle GET/POST requests; handle the ACKs for confirmable transmissions; deal with dropped, reordered, or duplicate packets. MessagePack's job is to encode/decode structured data without resorting to encoding numbers as text.

Software Architecture Hierarchy

Figure 2 illustrates the software architecture of the two libraries that the Research Environment consists of. BurtSharp is a client program that communicates and controls the BURT robot, and BurtSharp.UnityInterface is an extension to BurtSharp that allows use of haptic objects and fixtures with Unity. Researchers can use these two libraries to test their control and haptic modules and can develop their own research tools.

Figure 2: BurtSharp and BurtSharp.UnityInterface software architecture hierarchy.

BurtSharp Message Types

• The BurtSharp-CoAP client subscribes to observable resource group packages such as:
  • ServerUpdate
    • "position": [x, y, z]
    • "velocity": [x, y, z]
    • "joint_position": [j1, j2, j3]
    • "joint_velocities": [j1, j2, j3]
    • "timestamp": <u32>
  • RobotStatus
    • "handedness": u8
    • "Outerlink": u8
    • "Patient": u8
    • "Estop": u8

• The BurtSharp-CoAP client sends asynchronous NON-confirmable PUT requests to the mainboard-server through the “AsyncNonPutRequest” method. These requested messages can be one of the following control modes:
  • Cartesian Forces
  • Joint Torques
  • Cartesian Torques
  • Cartesian Forces + Joints Torques

• The BurtSharp-CoAP client subscribes at mainboard fault updates and to observable resource faults information such as:
  • MainBoardFault.NotReady
  • MainBoardFault.NoCanAtStartup
  • MainBoardFault.NoCoapAtStartup
  • MainBoardFault.OuterLinkDisconnected
  • MainBoardFault.HandednessUnknown
  • MainBoardFault.InvalidEepromCrc
  • MainBoardFault.EStopPressed
  • MainBoardFault.EStopLatched
  • MainBoardFault.InitFailed
  • MainBoardFault.TorqueLimitJ1
  • MainBoardFault.TorqueLimitJ2
  • MainBoardFault.TorqueLimitJ3
  • MainBoardFault.NotInHomingPositionAtStartup

The Mainboard-CoAP communication API below enables researchers to interface their own controllers listening to CoAP protocol. ​http://web.barrett.com/support/Burt_Documentation/MainboardApi/v1.0.0/

BurtSharp Control Loop Analysis

The mainboard is a hard real-time system and runs its control loop at 500Hz. At a period of 2ms, the mainboard transforms the input forces and torques to motor space, sends and receives messages and runs limits and safety systems as figure 1 shows. On the other side, BurtSharp subscribes to mainboard control loop messages through the BurtSharp-CoAP client, which runs in a separate thread “RunControlCycle()” and executes a callback to form the next control cycle output every time a message is received from the server “OnReceiveServerUpdate()”. We have found this to be more reliable than completely asynchronous communication from the mainboard. The BurtSharp CoAP-client thread executes the next control cycle every time a message is received from the mainboard-server and sends one message (“RobotCommand”) per control cycle to the mainboard. Preliminary experiments show that the control loop rate of the BurtSharp library reaches 489Hz when the PID controller is active (Figure 3). Researchers can investigate, through statistics, the violations that are triggered when their developed controllers are overshooting the default control update time (i.e., Example11 ControlLoopTimingStats). ​https://git.barrett.com/burt/software/burt-sharp/tree/dev-2.1.1/BurtSharp.Examples/Example11-ControlLoopTimingStatsAndMonitoring

Figure 3. Control loop rate analysis for the PID controller in force and torque control modes.

Shortly, code and mono optimizations might increase the control loop rate closer to the mainboard ones.

Benchmark

Firmware Version	BurtSharp control loop rate
1.2.2	489 (Hz)

For information on new firmware versions, hardware compatibility, and how to upgrade please visit: ​http://support.barrett.com/wiki/Therapy/FWUpdate