We made two significant changes to the database. First, we modified the schema to better represent the data we wanted to track by adjusting the field values. Second, we revamped the way database calls were handled. Initially, we used synchronous methods, which could block execution. Now, we’ve switched to using asynchronous methods to prevent blocking and improve overall efficiency.
Another significant aspect of the project underwent a transformation—the serial communication between the ESP32 and the Unity game. Initially, we employed serial communication for testing purposes. In the linked video, you’ll observe an LED on the ESP32 being toggled through interactions within the Unity game. This step was taken to verify that the required functionality for the gloves would operate seamlessly when serial communication was utilized.
Our initial task involved designing an alternative communication method. Although Bluetooth was the initial choice, unforeseen challenges arose when attempting to establish consistent connections between the ESP32 and the headset. Consequently, we explored an alternative approach.
In this revised design, we introduced a middle server. Both the Quest and the ESP32 would communicate with this server over Wi-Fi, utilizing standard REST API calls. This approach facilitates bidirectional data sharing while eliminating the need for physical cables. However, it’s essential to acknowledge a few drawbacks. First, there may be increased latency, depending on the time it takes for requests to be processed. Second, the server must be hosted on a dedicated system.
Comments