Three different implementations of the designed teleoperation system are proposed in section 3.6. The implementations are based on: LUNA without network communication, LUNA with LUNA network channels and ROS with ROS-based communication. Implementation in LUNA and ROS is done in different ways. More practical information on how the LUNA and ROS applications and toolchains are set up, can be found in appendix E. Additional to the above mentioned implementations, an implementation in a single ROS program could be made as well. This implementation is described but not used for testing.
The first implementation corresponds with the ’ideal’ teleoperation system, without delay be- tween master and slave controllers. This implementation is done in LUNA without LUNA net- work channels in a single program. The architecture model and gCSP model of this program can be found in figures 4.5 and 4.6 respectively. The architecture model connects the main model containing the gCSP model with two timers. The timers generate the operating frequen- cies for the LWR interface and controller respectively. The gCSP model contains two sequential processes connected with a pri-parallel construction. One sequential process is interfacing with the Omega device and calculating the controller output. The other process is interfacing with the LWR. The priority is given to the LWR interface, as incorrect timing will trigger an er- ror in the communication with the KUKA KRC. Priority is required to pass control actions to the LWR without time jitter. If priority would not have been given, both sequential constructs could be executed in different orders. This results in an undefined execution order per itera- tion. Data is communicated between parallel processes via global variables. This is not a nice
Figure 4.5:Architecture model for implementation in LUNA on a single PC.
Figure 4.6:Main gCSP model for implementation in LUNA on a single PC.
implementation, as global variables could be altered by other processes. For now, the program size is limited an global variables are strictly maintained manually. The alternative would be to use nonblocking buffered channels, however these are not supported in the LUNA version with the DDS network communication.
The same implementation could be done in ROS. Here, a single node for the calculations of both controllers could be made. Device interfaces could be implemented as separate nodes communicating with the controller. The architecture of this implementation is depicted in figure 4.11. This implementation is not used for measurements.
The second implementation to be validated is done with LUNA network channels. Two LUNA programs with LUNA network channels have been made. One program is the master side con- troller and the other is the slave side controller, both including corresponding device interfaces. Master and slave programs are executed on different PC’s. The LUNA network channels pro- vide the communication between programs. The master controller architecture and main gCSP model can be found in figures 4.7 and 4.8 respectively. The master architecture connects the main gCSP model with two timers, four input and four output LUNA network channels. The timers generate the operating frequencies for the controller and communication. The four in- put LUNA network channels receive values corresponding to the slave controller output force (3 directions) and slave controller energy output. The four output network channels send the master position (3 directions) and master controller energy output.
The gCSP model of the master side consists of three different actions in parallel. The first action is to interface with the Omega device and to calculate controller actions. The energy commu- nication with the slave controller requires conversion between operating frequencies of the controller and communication. For these conversions, processes are added before and after controller calculation, as well as before sending and after receiving. As sending of data must occur synchronously, the sending of all data is done after the rate conversion of energy com-
munication. Data is received asynchronously, since the communication is done over a network with variable delay. Dummy processes without functional code are used to explicitly denote independent asynchronous receiving of multiple variables (to show that there is a parallel con- struct of multiple recursive readers).
The slave architecture and main gCSP model are similar to the corresponding master controller models and can be found in figures 4.9 and 4.10 respectively. Additional to the master-side implementation, a timer is used for the LWR interface. The LWR interface is connected in pri- parallel with the control actions and communication.
The third implementation to be validated is done with ROS network communication. Two ROS nodes have been created, corresponding with master and slave controller. Device interfaces are implemented as nodes interfacing between the corresponding master or slave device and controller. Master and slave controller nodes and device interface nodes are executed on two PC’s, a master and a slave. The ROS middleware provides communication between master and slave controller nodes. As ROS communication does not have a specified maximum speed, communication frequency is set to the same frequency as the controller. Since controller and communication frequency are the same, no rate conversion is required for this implementa- tion. Implementation is done by creating two ROS nodes, corresponding to master and slave controllers. The master controller sends the master device position and energy to the slave controller and the slave controller sends slave controller output force and energy to the master controller. Both nodes interface with their corresponding device interfaces. The overall archi- tecture is denoted in figure 4.12.
To keep delays as low as possible, messages communicated via topics should be received as quickly as possible after being sent. This suggested to use minimal buffer size for each topic. However, during preliminary tests, it was found that a significant amount of data was lost. Therefore buffered topics must be used, but the size is rather arbitrary, as buffers must be cho- sen ’large enough’, but too large buffers introduce more delay. Due to poor documentation on topic buffers and lack of time, this is not further investigated. A buffer size of 1000 is used for communication between master and slave controller.