This week, I continued trying to push my end of the integration to-do list to prepare for the integration. I tried a few different design concepts to implement the IMU side of the communications, which involves gathering data in a specified time frame, and then using the data to determine a swing type that will be sent to the game engine via bluetooth.
One concept that I tried was to accomplish the data collection and analysis entirely in the same C++ program that reads IMU data. For now, this idea is in the back seat, as I could not find a reliable C++ timer mechanism that will track time for us. Thus, I resorted to just moving the data collection to the same python script that will handle bluetooth connections. To do so, the Rpi will run two concurrent processes, one running the IMU data reading and Madgwick algorithm, and the other taking in that data as input through a unix pipe and then when the time is right, analyzing a window of that data. There was a slight issue of how the python timer jumps by quarter second intervals occasionally, which can throw of data collection, so I tried to adjust the implementation of data collection to rely on the python timer as little as possible, so that the error cannot propagate through different stages of the data analysis process.
For the data analysis process, during the swing window which is of differential time, I am taking the average orientation of the paddle during that window to establish what type of swing (lob, smash, topspin, slice) is being executed. To determine the speed of the paddle, and whether the paddle is swung at all, I am using the acceleration data. Through empirical testing, I found that the acceleration in the Z-axis of the IMU has an upward peak followed by a downward peak during a forehand, and a downward peak followed by a upward peak during a backhand. Thus, the goal is to identify if such peaks take place during the swing window, which can help us decide whether the swing occurred in time and what direction and power it was swung with. To help eliminate noise, I used a Scipy butterworth filter to smooth out the data, and then to determine the peak, we can first track what the acceleration reads before the window, and then integrate the values during the window to see what direction of peak we have. This is something that will have to be tuned going forward by testing it with the game engine in real time.
I also used CAD to design and subsequently 3d-print a box to hold our IMU system, which will be attached to a ping-pong paddle for gameplay.