Inertial navigation peripheral/Sensors

This section will cover the main hardware needed for the peripheral to function, the sensors, micro controller and XO connection.

Hardware choice

Sensors

Our choice of sensors was primarily dictated by cost. We needed at least two sensors, a gyroscope to measure angular velocity, and an accelerometer for tangential acceleration. Initially we were planning to have pitch and roll compensation for the device, but this was shoved towards the end.

For the accelerometer, we got a Triple Axis Accelerometer Breakout - ADXL330 from Sparkfun for $34.95 and for the gyroscope, we got a Gyro Breakout Board - Dual Axis IDG300 for $74.95, also from Sparkfun. Hypothetically, we could get cheaper sensors in the future, as we only ended up using one axis of the gyroscope and accelerometer.

Microcontroller

We used a PIC 18F4550 as the heart of our peripheral. This was a slightly excessive choice, as we could have used the PIC 18F2455 as well, which would shave off some cost. Both uCs have built in USB modules, which minimizes the number of components needed in the peripheral.

Like most PIC uCs, they have built-in analog to digital converters which are used to convert the analog signals from the sensors into integers.

Firmware

Microcontroller

The firmware uses a template developed by Prof. Bradley Minch from Olin College. The template implements a basic USB peripheral with a few samples of how to perform requests.

In our case, we will be modifying the vendor requests of the device, using the GET_RA2 request as a template. Instead of just sending a single byte with every request, we send five, one for each of the five channels of the sensors. You will need to change the endpoint number in the code, as that is what determines the number of bytes sent.

The five bytes being sent are all signed integers. During the main program loop, the PIC MCU will read all five sensors inputs and convert them into a 10 bit number. I only choose to read the upper 8 bits, as there is a significant amount of jitter in the signal. The stored values can then be requested by the vendor request as needed.

A future effort would entail having a timestamp with the data conversion. This would minimize the problem of the vendor request taking a significant amount of time. However, this becomes very minor once other issues are considered.

We installed some 1uF capacitors from each of the input pin used by the sensors to ground as a low pass filter. This helped reduce the jitter in our signal tremendously.

Calibration

Once we had the device functioning(sending sensor values to the PC), we needed to try and translate abstract values into actual physical meaning.

The problem was that humans do not walk in a very rigid fashion. We sway, oscillate and do not more dead true. Recognizing this, we scrapped the idea of trying to be very precise, and instead tried to create a simple logic system for navigation.

We would use one gyroscope axis for yaw, and to determine if we were rotating clockwise or counterclockwise, or not rotating. Then one accelerometer axis was used to determine if we were moving forward, backward or not moving. The way we implemented this was by experimentally determining bands for which the sensor data corresponded to actual movement. This was all done empirically, by performing simple movements like walking in a line, and plotting the resulting data.

With this simple set of commands, we are able to perform simple numerical integration and determine our position in space. The main way this system works is that the graphical representation provides feedback to the user, allowing this simple, near-Boolean logic to function effectively. Without the visual feedback, it would be difficult to control the device, as it would be nearly impossible to account for drift.

Future work

We would like to add a bit more sensitivity to the system. This would be by choosing narrower bands and setting values for each band. It was uncertain to us how to do this accurately, as we had very wide bands for the simplest of motions.

Also, pitch and roll compensation needs to occur. From a usability standpoint, not having those means that the peripheral has to be held very rigidly, which is an unrealistic usability contraint.