Changes between Version 10 and Version 11 of Therapy/SystemOverview


Ignore:
Timestamp:
Jan 22, 2018, 4:00:03 AM (4 months ago)
Author:
al
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Therapy/SystemOverview

    v10 v11  
    1010BurtSharp 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.
    1111
    12 == CoAP protocol ==
     12== CoAP protocol == 
    1313
    14 CoAP 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.
     14CoAP (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.
    1515
    1616== Software Architecture Hierarchy ==
     
    6565  * MainBoardFault.NotInHomingPositionAtStartup
    6666
     67The Mainboard-CoAP communication API below enables researchers to interface their own controllers listening to CoAP protocol.
     68http://web.barrett.com/support/Burt_Documentation/MainboardApi/v1.0.0/
     69
     70
    6771== Control Loop Analysis ==
    6872