As I related in a past post, I recently designed and built a device which could be built into a joint-sensor glove; it is able to measure the resistance of 25 sensors and store that data to a microSD card or stream it over a serial link.
I started this project because I've long wanted to play around with using an instrumented glove which would allow free-form hand gestures to be used as a human interface. Additionally, I work with people who do research into physical rehab, who sometimes need access to hand movement data. Currently, they have to use a bulky device which is wirelessly tethered to a PC; this restricts the circumstances under which data can be taken. This device, being able to be contained in a glove and being able to store data internally, may allow for experiments which are not currently viable (e.g., a full-day recording to examine the structure of normal hand use).
Hardware
A front image of the board is below. The front only has two buttons, two status LEDs, and the low-frequency, high-accuracy clock oscillator.
The back of the board is below. The resistive sensors would be connected to the header at the top; the top row of holes all connect to +3.3V and the bottom row lead to the FET switch array. Currently, I've got a potentiometer connected for first-round debugging.
The actual resistance-sensing circuitry uses a FET and an opamp to sink a set amount of current through the selected sensor channel. The sensor channel is selected by turning ON the appropriate FETs in the line of ICs just below the sensor header at the top; it is a 5-by-5 array, allowing one of 25 sensors to be selected by the appropriate use of 10 outputs. The voltage at the bottom of this switch array is sampled to measure the resistance; since the current sink is controlled, the voltage difference between 3.3V and the measured voltage determines the resistance.
The board also includes the microSD slot (bottom left) and the power circuitry (charger and 3.3V buck converter, bottom right). All of the circuitry has been tested except the microSD slot.
Software + Testing
To start testing the hardware, I developed a simple firmware which will sample the 25 sensors and transmit the resulting voltages over the serial channel that I have broken out for debugging. The firmware source is here; it is very simple, and applies a constant sink current across all of the sensors and over time. In the future, it may make sense to adjust the sink current to match the sensitivity and range of the device to the magnitude and range of resistances exhibited by each channel.
The firmware sets the switch array and samples each 'sensor' in turn; the data is then partitioned and inserted into a transmit buffer. Once all of the channels have been sampled, I use the DMA controller to 'automatically' transmit the buffer contents over the serial link.
To watch the data as it comes in, I use an upgraded version of my general-purpose MATLAB serial data 'scope function (here). First, I verified that all of the channels were working by shorting each channel in turn (shown below); as you can see, all of the channels were working.
I then wiggled the potentiometer at either end of its range, to cause wiggles in the scope for the appropriate channels (below).
This means that, with the exception of the SD card slot, all of the hardware has been tested and verified.
Moving Forward
Since I know that the resistance sensor circuit works (in a broad sense), there are a number of things to do:
-Implement the SD-card logging. This will involve testing out the hardware and its ability to interface with SD cards, looking up the specs for SD card partitioning and FAT32, and using that information to implement some simple code that finds a long stretch of unused space on the card to fill up with logged sensor data. It would be possible to code something that does not require a contiguous segment of the drive; however, this would require a much more complicated algorithm. Since this is a very purpose-built device, that seems like overkill; one merely needs to make sure that the SD cards used are relatively empty and absolutely defragmented.
-Implement a limited USB serial port. At present, the hardware is able to communicate over USB (verified by flashing the device with a USB-based bootloader). However, I do not use this facility; further, to get debug or other data out of my prototypes, I use a separate USB-to-serial cable connected to a debug USART. This extra cable is somewhat cumbersome; it would be nice to only need to plug in one cable to power the device and allow for debugging and reprogramming.
-Make an example resistive joint sensor; develop the algorithms to read it. At present, I just set the sensor current sink to a constant level. However, for certain ranges of resistances to-be-measured, it will saturate, while others will barely register. Additionally, an increase in resolution may be possible by sampling the sensor output single-ended, then also sampling it differentially with a bias input set equal-ish to the single-ended value.
-Make a glove; fill it with joint sensors. Obviously, I eventually need to actually make a glove to sew sensors into, and then connect to the device.
I started this project because I've long wanted to play around with using an instrumented glove which would allow free-form hand gestures to be used as a human interface. Additionally, I work with people who do research into physical rehab, who sometimes need access to hand movement data. Currently, they have to use a bulky device which is wirelessly tethered to a PC; this restricts the circumstances under which data can be taken. This device, being able to be contained in a glove and being able to store data internally, may allow for experiments which are not currently viable (e.g., a full-day recording to examine the structure of normal hand use).
Hardware
A front image of the board is below. The front only has two buttons, two status LEDs, and the low-frequency, high-accuracy clock oscillator.
The back of the board is below. The resistive sensors would be connected to the header at the top; the top row of holes all connect to +3.3V and the bottom row lead to the FET switch array. Currently, I've got a potentiometer connected for first-round debugging.
The actual resistance-sensing circuitry uses a FET and an opamp to sink a set amount of current through the selected sensor channel. The sensor channel is selected by turning ON the appropriate FETs in the line of ICs just below the sensor header at the top; it is a 5-by-5 array, allowing one of 25 sensors to be selected by the appropriate use of 10 outputs. The voltage at the bottom of this switch array is sampled to measure the resistance; since the current sink is controlled, the voltage difference between 3.3V and the measured voltage determines the resistance.
The board also includes the microSD slot (bottom left) and the power circuitry (charger and 3.3V buck converter, bottom right). All of the circuitry has been tested except the microSD slot.
Software + Testing
To start testing the hardware, I developed a simple firmware which will sample the 25 sensors and transmit the resulting voltages over the serial channel that I have broken out for debugging. The firmware source is here; it is very simple, and applies a constant sink current across all of the sensors and over time. In the future, it may make sense to adjust the sink current to match the sensitivity and range of the device to the magnitude and range of resistances exhibited by each channel.
The firmware sets the switch array and samples each 'sensor' in turn; the data is then partitioned and inserted into a transmit buffer. Once all of the channels have been sampled, I use the DMA controller to 'automatically' transmit the buffer contents over the serial link.
To watch the data as it comes in, I use an upgraded version of my general-purpose MATLAB serial data 'scope function (here). First, I verified that all of the channels were working by shorting each channel in turn (shown below); as you can see, all of the channels were working.
I then wiggled the potentiometer at either end of its range, to cause wiggles in the scope for the appropriate channels (below).
This means that, with the exception of the SD card slot, all of the hardware has been tested and verified.
Moving Forward
Since I know that the resistance sensor circuit works (in a broad sense), there are a number of things to do:
-Implement the SD-card logging. This will involve testing out the hardware and its ability to interface with SD cards, looking up the specs for SD card partitioning and FAT32, and using that information to implement some simple code that finds a long stretch of unused space on the card to fill up with logged sensor data. It would be possible to code something that does not require a contiguous segment of the drive; however, this would require a much more complicated algorithm. Since this is a very purpose-built device, that seems like overkill; one merely needs to make sure that the SD cards used are relatively empty and absolutely defragmented.
-Implement a limited USB serial port. At present, the hardware is able to communicate over USB (verified by flashing the device with a USB-based bootloader). However, I do not use this facility; further, to get debug or other data out of my prototypes, I use a separate USB-to-serial cable connected to a debug USART. This extra cable is somewhat cumbersome; it would be nice to only need to plug in one cable to power the device and allow for debugging and reprogramming.
-Make an example resistive joint sensor; develop the algorithms to read it. At present, I just set the sensor current sink to a constant level. However, for certain ranges of resistances to-be-measured, it will saturate, while others will barely register. Additionally, an increase in resolution may be possible by sampling the sensor output single-ended, then also sampling it differentially with a bias input set equal-ish to the single-ended value.
-Make a glove; fill it with joint sensors. Obviously, I eventually need to actually make a glove to sew sensors into, and then connect to the device.
