Changes between Version 14 and Version 15 of Burt-Research/SystemOverview
- Timestamp:
- Jan 23, 2018, 1:09:14 AM (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Burt-Research/SystemOverview
v14 v15 1 1 = BURT Research - System Overview = 2 2 3 {{{4 #!div class="left" align="left"5 6 [[Image(htdocs:therapy/SystemOverview/BURT-System-Overview.PNG)]]7 8 }}}9 3 10 4 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. … … 14 8 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. 15 9 10 11 {{{ 12 #!div class="left" align="left" 13 [[Image(htdocs:therapy/SystemOverview/BURT-System-Overview.PNG)]] 14 15 '''Figure 1: BURT system overview.''' 16 }}} 17 18 16 19 == Software Architecture Hierarchy == 17 20 18 BURT-Research offers a Research Environment that comprises two libraries, BurtSharp and BurtSharp.UnityInterface, and a Medical demo application. The figure belowillustrates the 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 capabilities and can develop their own research tools.21 BURT-Research offers a Research Environment that comprises two libraries, BurtSharp and BurtSharp.UnityInterface, and a Medical demo application. Figure 1 illustrates the 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 capabilities and can develop their own research tools. 19 22 20 23 … … 23 26 24 27 [[Image(htdocs:therapy/SystemOverview/SystemArchitecture.PNG)]] 28 29 '''Figure 2: BurtSharp and BurtSharp.UnityInterface software architecture hierarchy.''' 25 30 26 31 }}} … … 69 74 http://web.barrett.com/support/Burt_Documentation/MainboardApi/v1.0.0/ 70 75 76 == BurtSharp Control Loop Analysis == 77 78 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 489 Hz (Figure 3). Researchers can investigate through statistics the violations that are triggered when their developed controllers are overshooting particular time limits (i.e., Example11-ControlLoopTimingStats). 79 80 {{{ 81 #!div class="left" align="left" 82 [[Image(htdocs:therapy/SystemOverview/ControlLoopRate.png)]] 83 84 '''Figure 3. Control loop rate analysis for force and torque control modes.''' 85 }}} 86 87 88 Shortly, code and mono optimizations might increase the control loop rate closer to the mainboard ones. 71 89 72 90 {{{