Glove Controller

This project began before the website was, so everything that I have done so far will be in this one post.

The goal of my project is to design a human-machine interface allowing simple movements from a person’s body to correlate directly with a 3D model created by the computer. The current idea is to use a glove which tracks the movements of the user’s hand and fingers to control a model of a hand in Unity. The target audience for this product could be those who would prefer a more tactile approach to controlling computers, instead of the traditional way of using a mouse or a touch screen. This idea would also be useful in 3D software, such as CAD or animation programs, where being able to intuitively maneuver around the 3D world would improve speed productivity. The initial design for the product consist of a structure to mount the sensors to determine the position of the hand.

These are the pieces that will be used to hold the sensors in place. The white plastic base piece has holes in it for the features on the bottom of the sensor, and clips on the top which hold the sensor in. The red arm on top slides into the center of the sensor. The arm will most likely not be able to support the weight of the rest of the mechanism, but it will be attached to the hand at each joint so there will won’t be weight on them.

The electronics have not been tested yet because the PCB has not arrived yet, in the meantime I have been working on the software side. I have modeled a simple representation of a hand in Unity, where each finger has the 3 external bones, and the thumb has 2. At this point, there is a way to control the entire hand with the keyboard, using WASDQE to move it around. Additionally, there is a text file called “adc.txt”. This file is what will handle communications between the python program, which reads all of the data from the sensors, and the C# program, which runs the 3D aspect. Currently, the file just has 1 line in it, which is the x-rotation value. As you can see in the following pictures, changing the value in this file moves the 1st finger up as the value decreases to 0.

In order for the data to be transmitted properly, the python program needs to make sure that the Unity program has finished reading the data before it updates. Most likely, the Python program will write 16 lines of data (one for each channel) which the Unity program can read. Once the Unity program is done reading all of the data, it can then write a character to the end of the file which will then be read by the Python program which tells it to clear the file and write the new data. This method is not the best, as there is a lot of wasted time opening and closing files, so in the future using a direct pipeline or socket such as TCP might be better.

The method of using a text file worked somewhat, it had to be closed and then opened again every time I wanted to write something to it. I have decided to use named pipes instead. Named pipes are also called FIFOs meaning “First In, First Out”. They work as the name implies, the first thing you write to them is the first thing to be read. They are similar to text files except they can be opened by multiple programs at once. Here is an example of the new python program working with the new unity program.

I have also made a test of what the structure that holds the sensors. It is slightly different than the last one but uses the same idea of the wedges that bend and then snap shut.

The last image shows the sketches that the model is based off of. I tried to follow better practices when making this model which is to define everything in a sketch, and not to make models on top of other models. With this new sketch, you can also change just the length of the piece and it will shrink accordingly, and everything else will still be the right size. This way I can measure the length of my fingers and change the measurement and everything will still fit. The end of it which sticks into the sensors is still weak though, and the ends need to be filed down so that they get the full range of motion. There is still work to be done, but this is much closer to the finished version.

On Thursday the circuit boards arrived. I got 10 of them because it was the same price as 5, and spares can’t hurt.

Here is a picture of the assembled board and the bare board. As you can see, the board is not that complicated with just two chips, and one of them is just a reference voltage for the ADC. The bigger chip is the ADC, which is an AD7490. That chip is a 12 bit, 16 channel analog to digital converter. It can take up to 16 different analog voltages and turn them into serial data, which it sends over the SPI protocol. On the back of the board is an Adafruit FT232H board, which can take the SPI signal and turn it into USB which the computer can read.

Here is a picture from my logic analyzer, it shows the 4 pins that carry the SPI signal, and also shows that the chip is working since it it responding over the Data in Pin (The signal is from the perspective of the FT232H, so out is coming out of that, not out of the ADC). I still need to fix the driver for the ADC though, since there is some things that you have to do when it first powers up that mine does not do. There are a few available that are written in C which I could use, but I do not know C that well so I will first try and make the python one work.

After I found that the chip did work, I wanted to see why the values were not what I expected. There were two things that could be changing the values: The range of the ADC or the reference voltage. The range of the ADC is either 0v to the Vref, or 0v to 2*Vref. This is changed by changing a bit in the control word, which is what I send to the ADC when I want a reading. Vref is made by the smaller chip. It has 2 modes, 2.5V and 3V. There is one pin that controls the voltage, if it is not connected to anything then it outputs 2.5V, and if it is attached to ground then it outputs 3V. I had accidentally connected it to ground, meaning the reference voltage was 3V, which is not what I wanted. Luckily, the way the circuit board is designed meant that it attached to ground on the bottom of the board, which meant I did not have to remove the chip to fix this, nor did I have to damage the chip at all. The trace goes through the board and comes out on the other side. To break the trace and have the pin not connected, I took a knife and scraped away the copper around the trace until it was no longer connected. Vref went back down to 2.5V and once that was doubled by the ADC, the range was 0V to 5V, which is what I needed. While it is possible to make the same modifications to all of the boards to use them, I also realized that the FT232H breakout is on the wrong side of the board, and that the pin I was planning to use for the Chip Select wouldn’t so I had to put a wire across the board. It would be nice to make a new board which solves these problems. I would also use different connectors that would be easier to use, since the ones that I am using are very small.

Here is the bill of materials: bom