# Glove Prototype for Feature Extraction Applied to Learning by Demonstration Purposes
## 4 Results
When it is received, it also flags it to let the \"Update\" method know it needs to parse that data and update the hand object. Because it runs asynchronously, race conditions must be handled with care. If the data is received while parsing the previous data, it is possible to corrupt the data in the middle of parsing. So mutexes were used when writing or reading the shared resource assuring atomicity of  
Figure 4: Visual representation of the hand. the operations, blocking access of other operations to the shared resource while another operation is handling it. This asynchronous approach, summarized in Figure 5, makes it possible to decouple the speed of the microcontroller output and the game engine speed, solving the issues of synchronization. To test the UDP connection, a _Python_ script was implemented that inputs a user string and sends it through UDP to localhost. The server side (_Unity_ script) reads it and logs the result. The test revealed it was a viable solution, also capable of reading streams of data continuously. **while** True:  
msg = **input**(\"\")  
bytesToSend = **str.encode**(f\"_{msg}\")  
UDPClientSocket.sendto**(bytesToSend, serverAddressPort)  
Whether the solution could handle non-stop streams of data simulating high frequency data outputting was also tested. So, a script that just sends the value of an incremental counter in an infinite loop was implemented, and the asynchronous solution, in fact, was working properly. counter = 0  
**while** True:  
bytesToSend = **str.encode**(f\"Message:_{counter}\")  
UDPClientSocket.sendto**(bytesToSend, serverAddressPort)  
counter += 1  
The two last tasks the script must perform are the parsing of the received data and the update of the transform of the correct objects. The _Unity_ game engine has its own serialization implementation and includes JSON serialization and deserialization tools. It is only required to define the structure in a _C#_ class or struct, add the \"Serializable\" _C#_ attribute, and the JSON tools create the object from the JSON encoded string. Figure 5: Simulation program flowchart. [Serializable] public struct FingerPose { public SQuaternion[] joints; }  
[Serializable] public struct HandPose { public SQuaternion wrist; public FingerPose[] fingers; }  
The \"SQuaternion\" type is a custom serializable quaternion because the _Unity_ quaternion type does not support serialization by default. It just stores w, x, y, and z values and implements implicit operators to allow an easy conversion between the native quaternion type supported by _Unity_ so it can be used like so:  
SQuaternions_quaternion = new SQuaternion(0, 0, 0, 1); Quaternion quaternion = (Quaternion)s_quaternion;  
To perform the rotations on the objects, _Unity_ handles it when setting the property \"localRotation\" on the transform component. It expects a quaternion and sets its orientation in relation to the parent transform. One issue that immediately surged is that the microcontroller and the simulation were not using the same reference frame. Figure 6 helps visualize the frames of reference. The frame of reference transformation is defined by the transformation matrix from microcontroller frame to simulator frame \(\overset{S}{M}\mathbf{T}\):  
\[\overset{S}{G}\mathbf{q} = \overset{S}{M}\mathbf{T}_{G}^{M}\mathbf{q}\] \[\left[ \begin{matrix}w_{s}\\ x_{s}\\ y_{s}\\ z_{s}\end{matrix} \right] = \left[ \begin{matrix}1&0&0&0\\ 0&0&1&0\\ 0&0&0&-1\\ 0&1&0&0\end{matrix} \right]\left[ \begin{matrix}w_{m}\\ x_{m}\\ y_{m}\\ z_{m}\end{matrix} \right] \tag{22}\] \[\left[ \begin{matrix}w_{s}\\ x_{s}\\ y_{s}\\ z_{s}\end{matrix} \right] = \left[ \begin{matrix}w_{m}\\ y_{m}\\ -z_{m}\\ x_{m}\end{matrix} \right]\]  
Figure 6: Microcontroller and simulator frames of reference. So, before setting the local rotation of the objects, the frame of reference transformation is computed inside the function \"ToFrameOfReference\".