In order to identify the individual clients, client identification numbers are needed for the server. Each client sends sensor data packets including its unique identification number to the server side. The server receives and reads the sensor data packets and then generates the control data packets for each client. The compositions of the sensor data packet and the control data packet for the multiple-client NCS are provided in this section. The developed software architecture is also given in the last part of this section. For all software codes presented in this section, refer to Appendix.
4.2.1 Identification of Clients
In order for the server to identify the client that sent a data packet, the identification number of each client is included in the UDP packet from the client side.
Once the sensor data arrive at the server side, the server reads the identification number and then calculates the control data for the specific client. The algorithm to identify the client on the sever side is shown in Fig. 4-4.
4.2.2 UDP Packet Composition
With UDP, the composition of IP packet was developed. The composition of a typical 68-bytes-long sensor data packet going from the client to the server is shown in Fig. 4-5. It consists of a 20-byte-long IP header, an 8-byte-long UDP header, an 8-byte- long time stamp, a seven 4-byte-long sensor data values, and a 4-byte-long identification number. A time stamp is taken on the client side at sampling and the server sends it back to the client for identifying whether the arrived data packet is the expected data packet or a delayed one. Delayed data packets are discarded by the client. Using the identification number, the server can identify the client. Clients 1, 2, and 3 have their unique identification numbers as 1, 2, and 3, respectively. After sensor data arrive from the client, the server reads the last section of the data packet and identifies which client sent the data. Then the server calculates the control data for this client.
0
y
y
−1y
−2y
−3y
−4y
−5y
−6y
−7Fig. 4-5. Modified composition of a sensor data packet from the client to the server from [33]
The composition of a typical 56-byte-long control data packet transferred from the server to the client is shown in Fig. 4-6. It consists of a 20-byte-long IP header, an 8- byte-long UDP header, an 8-byte-long time stamp, one 4-byte-long current control data value, and four 4-byte-long predicted control data values.
0
u u1
u
2 u3 u4Fig. 4-6. Composition of a control data packet from the server to the client [33]
4.2.3 Network Interface for Client 3
For the network communication, socket programming is used. A client makes a socket consisting of a sensor signal and sends this socket to the server. After receiving the socket, the server reads it and makes socket of control data. Then, the server sends back the socket of control data to the client for its performance.
In this research, the data sockets that are transferred between the server and the client are of a user defined type (UDT). Client 3 with Microsoft Visual Basic 6.0 uses Winsock for data transmission. However using Winsock, we can transfer only string- data-type packets. In order to make network connection between Linux server and Client 3, an additional component that can convert data types is needed. This component is
called as Gateway in this research. Gateway makes UDT sockets for the server using string-data-type packets from Client 3 and produces string-data-type packets for Client 3 using with UDT sockets from the server. Software code for Gateway is written in C programming language on Linux. A schematic of network interface between Linux server and Client 3 is shown in Fig. 4-7.
Fig. 4-7. Schematic of network interface between Linux server and Client 3
Client 3 is controlled by Linux server over a wireless network. Hsieh [22] developed the wireless connection using with the Tamulink Wi-Fi access as shown in Fig. 4-8 [34]. The user on the server side could control the robotic wheelchair with Winsock. Since the controller was placed on the client side as in supervisory control, however, the server could not receive any feedback signal from the client.
Fig. 4-9 depicts the feedback control over a wireless network realized in this thesis of Client 3. The sensor data from Client 3 are sent to Gateway and the control data from Gateway are transferred to Client 3 over the Tamulink wireless network. Gateway is connected with Linux server over Tamulink wired network. In this system, the controller is placed on the server side. Its interface with Client 3 is shown in Fig. 4-9. The dashed arrows between Gateway and Client 3 indicate the Tamulink wireless network. + - Controller Server Side Sensor system Client Side Robot wheelchair Motion Gateway Wireless Tamulink Wired Tamulink Gateway Side
Fig. 4-9. Schematic of feedback control over the Tamulink wireless network of Client 3
The software program of Client 3 was written in Microsoft Visual Basic 6.0. Fig. 4-10 shows the user interface when the Client 3 program starts. All sensor signals are displayed in each window and are sent to Gateway.
The overall data-transmission architecture for Client 3 is depicted in Fig. 4-11. The dashed lines between Gateway and Client 3 indicate actual data-packet transmissions over the Tamulink wireless network. Gateway creates two sockets; ‘sd’ for Client 3 and ‘sockid’ for Linux server. The source code to create sockets is given as
sd = socket(AF_INET, SOCK_DGRAM, 0) sockid = socket(AF_INET, SOCK_DGRAM, 0).
When the sensor data socket arrives from Client 3, Gateway saves it with one socket and reads the data. The source code to receive packets is shown as
cr = recvfrom(sd, recv_msg, 10, 0, (struct sockaddr *) &client_addr, &clilen).
The length of sensor data is fixed as 10 bytes which does not include header data. The UDT packets for Linux server are made and sent as shown in Fig. 4-12.
The source code for sending UDT packets from Gateway to Linux server is given as follows.
nw=sendto(sockid, (const void *)send_buffer, send_buffer_size, 0,(struct sockaddr *) &server_addr, addrlen)
Linux server receives the UDT packets and makes the control data packets as shown in Fig. 4-13. The movement-commnad value can be 10, 7, 5, 2, and 0. The meanings of each value are described in Table 4-2. The UDT control data are converted to the string- data-type control data by Gateway.
0 u
Fig. 4-13. UDT control data packet created by Linux server
Table 4-2. Meanings of UDT control data for movement
value meaning convert as
10 Moving Forward fwd
7 Turn Right right
5 Moving Back back
2 Turn Left left
With the UDT control data packets from Linux server, Gateway makes another control data packets for Client 3. The source code for sending the control data is given as follows.
Switch(u0){ Case(10):
cw = sendto(sd, fwd, 5, 0, (struct sockaddr *)_ &client_addr, clilen);
break; Case(7):
cw = sendto(sd, right, 5, 0, (struct sockaddr *)_ &client_addr, clilen);
break; Case(5):
cw = sendto(sd, stop, 5, 0, (struct sockaddr *)_ &client_addr, clilen);
break; Case(2):
cw = sendto(sd, left, 5, 0, (struct sockaddr *)_ &client_addr, clilen);
break; Case(0):
cw = sendto(sd, back, 5, 0, (struct sockaddr *)_ &client_addr, clilen);
break; }
Client 3 receives and reads the control data with string-data-type. The source code for receiving and calling the motion function are given as follows.
Dim recData As String
Winsock.GetData recData ‘receiving the data packet Select Case recData
Case “fwd” Call Front Case “right” Call TurnRight Case “left” Call TurnLeft Case “back” Call Back Case “stop” Call StopRobot
According to the called motion functions, the robotic wheelchair moves with collision- avoidance. The Gateway program is included in Appendix of this thesis.
CHAPTER V
OPERATION AND TESTING
In the previous chapter, the designed software programs for each client or server system are presented. This chapter describes how the sampling period of each system is determined and tested. In order to obtain the sampling period of each system, the operation time for each control loop is measured. Based on the relation between the bandwidth utilization and the sampling period for each control loop, the ranges of the sampling periods to ensure stability are presented. In the last part of this chapter, possible combinations of the sampling periods are suggested and experimented.