We're pleased to share our recent developments involving the integration process of our project. This integration of the prototype has been a lengthy process which included many tasks being achieved across all our team's divisions. There were even some last-minute changes that had to be made in order to get the desired functionality from our prototype. This integration happened in 3 stages: mechanical, hardware, and software integration.
Mechanical Integration
The first stage of integration involved printing the mechanical mounts, assembling the mounts with the heat inserts, and creating the wearables along with managing the cables.
Battery Mount
This battery mount was able to hold the battery without sliding initially. However, it was noted that the friction would reduce once it is strapped to someone's arm as it is pushing down on a smooth surface, causing it to slide during use. This is undesirable as the components should be secure while users are wearing our device. A quick solution was realized for this issue, which simply involved adding 3 layers of scotch tape to each side of the mount to increase the thickness of the mount. Small M2 heat inserts and spacers for the perfboards were added to this mount along with 2 straps of velcro.
Peltier Mounts
A new mount for the Peltier module was printed to have space for 4 heat sinks as seen in the image below. It is also worth noting that the Peltier modules themselves are slightly different from one another in terms of the thickness of the electrical insulation. However, they still slide into the mounts and are flush and secured. The mounts also easily wrap around a user's wrist with the velcro strap.
Cable Management
The glove had to be fitted with all the actuators and sensors and it was decided that the device would be right-handed. As a result, the flex sensors were glued down to the top of the glove while the haptic motors were glued down to the bottom of the glove, near the fingertips. The wires coming from each finger were initially held down using zip-ties but after cutting the excess from the zip-ties, they introduced sharp edges that could scratch a user. To improve this, most of the zip-ties were removed and the wires were bunched together onto the glove using the tape then they were all encased in a carbon fiber braided cable sleeve. This helped to keep the wires organized so that the sensors and actuators could easily be connected to the perfboards.
Hardware Integration
The next stage of integration involved connecting all the electrical components to the esp32 microcontroller via connections being soldered onto the perfboards. A lot of crimping was done as well to connect the wires to the socket headers properly.
Flex Sensors
One of the longest tasks for hardware integration was getting all 4 of the flex sensor sockets and connections soldered on properly. Each socket required one connection to ground while the other connection split into 2 branches; one branch had a resistor connected to 3.3 V and another branch had a wire connected to an analog pin on the esp32. As a result, 2 rails were made for ground and 3.3 V coming from the esp32. The wires coming from the flex sensors also had to be crimped to fit the headers that go into the sockets. After this was completed, a code for debugging the sensors was deployed once but then failed to upload onto the esp32. Initially, the IDE had to be configured to connect to the right type of microcontroller, but the issue appeared once again. It was later discovered that one of the analog pins P12 on the esp32 microcontroller had a faulty connection and was skewing all the results, so after terminating that connection, the 3 flex sensors we needed were working.
Haptic Motors
On the other perfboard, the haptic motor sockets were soldered on and 2 rails were made; one to connect to the positive pin on the haptic driver and the other rail to connect to the negative pin on the haptic driver. The rails were connected to these pins via wires and the haptic driver was initially only able to drive 2 motors. The connections from the motor wires to the headers were a bit loose so after crimping a new header onto some of the haptic motors, all 3 motors were driven using one haptic driver.
Peltier Control
This was the longest task for hardware integration as this took several iterations. Initially, an nMOS driver was going to be used so that the Peltier module could be turned on and only do heating. This is because the Peltier module has polarity like a motor and can be controlled for heating or cooling depending on the direction of the current. However, a lot of the nMOS drivers were defective and not consistent, so a new solution was needed.
The transistor circuits for NOT gates and AND gates were combined to create a transistor circuit that can provide 3 outputs: OFF, ON, and REVERSE POLARITY. These outputs would be generated by digital control signals A and B. The parts for this circuit were also readily available as the lab had nMOS transistors and varying sizes of resistors. After the circuit was built, the outputs for various control signal combinations were tested and it was possible to reverse polarity.
However, when connecting the Peltier module to the circuit, it would get voltage limited. We decided to use a boost converter to step up the Vcc of the components to 8 V despite the Peltier module having a suggested input voltage of 5 to 7 V. This did give more voltage to the Peltier module, but then it would get current-limited to about 0.4 A, whereas the operating current is typically 0.7 - 1 A. This led to us having to play with the resistors involved in the circuit to see if they could be lowered. This challenge then became a balancing act of finding a resistor that did not limit the current but also allowed the Peltier module to draw as much voltage as needed. Unfortunately, this resistor was not experimentally determined.
Despite the failed attempts, one colleague suggested an h-bridge, and after some research into single motor h-bridges, I found the L9110H h-bridge by Adafruit. According to the datasheet, it can be powered with a 5 V input and supply the load with 0.7 A. This met the specs of our Peltier module so it was bought and tested with and without a boost converter. In both cases, the Peltier module could draw up to 4.5 V and switch between heating and cooling via digital inputs. It was decided that we would solder this component down for the time being and try to find a more efficient h-bridge.
A mount for this chip was soldered onto the perfboard near the flex sensors. The output pins OA and OB were connected to a 90-degree socket that connected to the header on the Peltier module; the wires coming from the Peltier module had to be crimped and fitted into the header. The Vcc pins were connected to the 5 V pin on the esp32 while the ground pins were connected to a ground pin on the esp32. The input pins IA and IB were initially connected to digital pins SP and SVN but these pins only read values. So, IA and IB were resoldered and connected to digital pins 32 and 33. After a quick debug, the Peltier module was capable of both heating and cooling.
Software Integration
The final stage of integration involved getting the esp32 module to connect to Wifi so we could send and receive data from our server in MongoDB and synchronize the game actions to the actuators.
Wifi Connection and Data Flow
With one esp32 being able to connect to Wifi, it was crucial to set up the connection so that our device could communicate wirelessly. The code would sometimes fail to upload to the esp32 but it only needed to be reset and booted using the tiny buttons on the esp32. After getting it to connect to Wifi, it was possible to the perform HTTP POST method to send data to the server via a queue. This would then work with receiving data from the server as the first piece of information that goes into the server would be the first one out of the server. Though it took a while, it soon became possible to perform the GET method to request data from our server.
Game time Data
With Wifi working, it was possible to send data from our game to our server and also receive that data in our microcontroller to act on the user's virtual reality glove. Before doing this, the components had to be tested holistically, which meant that rather than testing each component individually, we had to see if they could all work together, so we developed integration code that tested each component sequentially and it worked successfully. Afterward, we tested if the game events could be read by the microcontroller and output a sensation to the glove, so we added some Wifi logic to our integration code. This setup allows the haptics to go off when an enemy is killed in-game on the headset.
Next Steps
With the components working and software currently being reworked, we aim to improve our prototype by incorporating data from 5 fingers. We also are going to work on a new, larger perfboard to make better connections for our components.
Kommentare