# Gloves for Virtual Reality — Dev Diary #2

TL;DR This post explains the early problems we faced and how we solved them. First, we redesigned the gloves and decided to focus only on making the index finger. Secondly, we could not find motors small with enough power, so we redesigned the gloves again and placed the motor in a vertical position. Finally, we moved away from expensive absolute rotate encode to cheap relative rotary encoder, which simplified out gloves design.

In my last post, I’ve introduced our summer research project and gave a brief overview of what we are going to build. This blog post will go into the details of the first few obstacles we’ve come across, and how we solved them.

### Not two fingers. One finger.

In our initial plan, the gloves would encompass index and thumb finger and those two fingers would be connected with each other at the fingers joint. But soon it became that it makes more sense for the fingers to be connected at the wrist. So we changed the scope of our project from two finger to one finger. The following figure[1] shows the new design of our gloves.

### Motors are too big. We need alternate design.

Next, we couldn’t find motors that small and powerful enough to fit in the red cylinder shown in Figure 1. So we redesigned our motor housing. With this new design the motor doesn’t sit inside the red cylinder — instead it’s placed almost in a vertical position.

Here is a cross section of the new motor housing,

### Moving away from absolute rotary encoder.

Rotary encoder is a sensor that converts angular motion of the shaft to electrical signals. Rotary encoder can be two types: Absolute and Incremental. In an absolute encode(Figure 4) we always know the angular position of the shaft at any given time[3]. But in incremental encode we can only measure the number of additional rotations that shaft has taken.

Initially we wanted to use absolute rotary encoder to measure the angle of a joint. But since small absolute encoder are expensive, we opted to use incremental rotary encoder. I’ll explain how it solves our problem.

We picked up our brushed DC motor from Pololu. Figure 5 shows the motor with magnetic incremental encoder[2] attached at the end. We will setup the motor as such — rotation in the joint will cause rotation on the extended motor shaft end, and because of the gearbox, a small rotation on extended shaft will cause multiple full rotation on the rare motor shaft end. A magnet is attached on that rare end of the motor shaft, and with every rotation it goes over two Hall effect sensor attached on the circuit board — and we use reading from the Hall effect sensor to count the number of rotation. In this method we loose some accuracy, but our initial calculation showed that this methods has enough resolution for our need.

At the beginning of every game play session we will have a calibration stage. When fingers are straight it will be our 0° reading of our joints. From that point, when our fingers are moving we will count the number of new rotation and the its direction on the rare end of the motor shaft, and we will use those information to find out the new joint angel.

Any constructive feedback would be most appreciated.

This research is funded by Bennett Undergraduate Electrical Engineering Summer 2017 Research Fellowship at South Dakota State University, and supervised by Dr. Zhen Ni, Assistant Professor in Department of Electrical Engineering and Computer Science at South Dakota State University.

[1] The Hand model is created by Dennis Haupt.

[2] Image of the motor is taken from Pololu.

[3] Image of absolute rotary encoder is taken from DirectIndustry.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.