Electronic Impact Vest Using Atmega32

Our one sentence “sound byte”… *POP*
Finally, a fair and balanced way to score Tae Kwon Do matches without the moaning and groaning of everyone. The Electronic Hogu system uses piezoelectric force sensors to determine how much force is delivered by the impact of a strike. Using waveform analysis and analog-digital conversion, it is possible to create constraints to determine what truly should and should not score in a match. By driving a CRT monitor with the STK500’s PWM, we can also have a score display to tell how many points a player has. Most importantly, wireless communication via OOK (On-Off Keying) between the hogu and the base station is integral to the effectiveness of this system as it provides a fast and easy way to transfer information quickly without a tethered system. Ultimately, our system makes much needed improvements to an age-old game by taking traditional martial arts into the future.

The inspiration for this project came from Kevin’s own interest in TKD and our collective interest in the way that it implemented a collection of previous labs to reach a common goal. The fact that it was possible to implement this project could be considered either a well-timed coincidence or destiny. Either way, it was interesting to see that a commercially produced product sold at astronomical prices, nearly $3000 for a system[1], could be manufactured with individual parts for a much smaller fee.

2. High Level Design

Before the advent of electronic hogus, two Tae Kwon Do opponents would spar and three corner judges would observe the match and award a point to the fighter who landed a hit on the other; however in instances where the opponents attack nearly simultaneously it is difficult for the judge to correctly reward the deserving opponent. If two electronic hogus are hit milliseconds apart, the difference can be discerned electronically and the fighter who struck first will be given a point. We viewed a YouTube video[2] demonstrating the wireless electronic hogus and we decided to design and implement our own hogu using knowledge obtained in ECE476 throughout the semester.
The logical structure of our design is two have two main components: the transmitter side and the receiver side. The transmitter side consists of the hogu implanted with piezoelectric sensors, an MCU implementing a hit detection scheme, and wireless transmission circuitry that sends a specific byte of data when a hit is detected. The receiver side consists of wireless receiver circuitry, an MCU that waits until the specific byte is received, and a TV to keep track of score and penalties. Detailed descriptions of the two sides can be found in section 3.2.
Throughout the project it was clear when to use hardware and when to use software. The only time in which we considered both hardware and software to achieve the same goal was to discern between hardware filtering versus digital filtering. We first tried to implement the filter in software to save soldering time but were met with problems with signal attenuation; therefore we resorted to making a hardware filter which we found was ultimately easier to test and debug.
Our design does not relate to any known standards; however the wireless protocol that we use was developed by Meghan Desai so the FCC legal restrictions must be taken into account. Further discussion of the FCC legal restrictions can be found in section 5.4. Our overall design is a reasonable reconstruction of a potential system as hinted at by one of our supporters, Jin Song.
Electronic hogus are developed commercially so exist various patents, copyrights and trademarks with varying companies. When sampling the piezoelectric sensors we were required to sign a non-disclosure agreement with CNOwire pledging not to market critical design elements to the public. The test hogu that was implanted with the sensors was manufactured by Adidas.

2.1. Transmitter Side

Each component will ultimately be discussed in detail, but the general description of each component is as follows. The output voltage from the hogu is roughly 10V to 15V for a solid hit, but can go up to 20V or more for a very strong hit. Therefore a voltage divider is used to scale this voltage to a reasonable level. The lowpass filter is used to attenuate noise. The voltage clamp is a safety measure so that the pins of the MCU are not overloaded by a large voltage that might destroy the chip. A prototype board houses an MCU that analyzes whether the hogu has been hit hard enough to register as a hit. The MCU controls the wireless transmitter that will send data to the receiver at the lab station if a hit is detected.

2.2. Receiver Side

Each component will ultimately be discussed in detail, but the general description of each component is as follows. The wireless receiver will receive the data that the transmitter sends if it a hit is detected. If a hit is detected the MCU will write to the TV. The MCU has the ability to keep track of scores and penalties. The TV will be connected to the MCU in the same way as in Lab 4.

3. Program/Hardware Design

This section contains explanations of software codes and hardware components. For the actual source codes refer to sections 6.1 and 6.2.

3.1. Program Details

This section describes what the code on each of the two MCUs does. The methodologies behind the development of the codes are given when applicable.
3.1.1. Transmitter Side
Prototype Board MCU
Using a combination of ISR-Driven ADC and the tranmission code as documented by Meghan Desai, we were able to develop an asynchronous OOK transmission device with the help of our force sensors. After the input from the force sensor is filtered below, an 8-bit analog-to-digital converter running from 0 to 5V is fed an input signal ranging from 0~4V. When the force sensors are struck, the input will be greater than 0 in which case we can trigger our integration statement which will sample at approximately 1/8 * 16MHz * 1/20 = 100kHz, much greater than necessary to get a clear reconstruction of the waveform. We can use a high sampling rate such as this due to less instructions for the MCU. If our sampled waveform has an Area greater than a certain threshold value that we decide, we can then generate a packet and then send it using the RCT-433 AS transmitter. One caveat however is that the output voltage has no solid meaning given the nature of the product. Since our sampled prototype was never documented, it has no datasheet or any specs. Our understanding of it is limited only to the fact that it seems to output voltage as a function of acceleration in both positive and negative directions. As an additional note, we were at first hesitant to use the transmit function asynchronously but found that it was indeed quite reliable. Taking a look back at the project as a whole, what we have is essentially a glorified button.

The program can be broken down into a series of functions:
interrupt [TIM0_OVF] void ADC(void)
-Takes ADC conversion data at a set sample rate as determined by countNum
void generate_data(char pktcount)
-Creates a packet of data to be sent through the transmitter where pktcount is the number of the packet. For testing purposes, we will send a packet payload of 100 that will serve as an ID tag so we know which packets are ours. Since most people are using IDs under the actual ID data location, we figure that we could mix it up by placing a second tag in the payload. This seemed to work functionally during the late hours but is highly recommended that a better encoding scheme be developed.
void main(void)
-Takes ADC output and checks to see if >0. If so, begin integration. If Area surpasses threshold, send packet, light test LED, and reset Area to 0. Otherwise, set Area to 0 and turn off LED.
3.1.2. Receiver Side
Lab Station MCU
This code uses a combination of the Lab 4 Lunar Lander video code and the receiver code by Meghan Desai to create a receiver/analog CRT driver. The overall operation is quite simple in that it receives a packet, checks to see if it has our ID tag, and if so modify the score on the screen. One of the major problems faced here was signal noise and other transmissions going around in the lab. It was noted that developing a much more complex method to encode our data would improve operation of the receiver. Unfortunately, time constraints forced us to settle for a working protocol.

Ultimately, we have a program that uses a very truncated version of the Bruce Land video code:
interrupt [TIM1_COMPA] void t1_cmpA(void)
-An interrupt dedicated to writing to the CRT screen. It is entered from the CPU sleep mode in order to get accurate timing of the sync pulses.
void video_pt(char x, char y, char c)
-Plots a point at coordinates x and y with 0 or 1 with 0 being black and 1 being white. Used by function video_puts.
void video_putchar(char x, char y, char c)
-Places a character at coordinate x,y where c is the character index. Used by function video_puts.
void video_puts(char x, char y, char *str)
-Places a string of characters at coordinate x,y where *str is the string. This is used to place our text for “Score, Penalty, Win, and Lose.”
void video_line(char x1, char y1, char x2, char y2, char c)
-Draws a line on the screen from x1,y1 to x2,y2 where c is 0 or 1 for b/w. This is used to draw the frames of our program as well as the numbers for score and penalty.
void debounce(void)
-A modified version of the debounce code from Lab 2 and what seems to have been used for every lab since then. Is used to debounce the penalty push buttons.
void main(void)
-Our main function which like a student going to 9:00am class goes immediately to sleep until it is interrupted during which time the screen was written. In between writings to the frame, the function checks to see if a signal was received. If so, then it also decodes the signal and checks to see if the signal was generated by the Hogu. If so, increment the score otherwise carry on. In order to write to the screen without artifacts, we used a special hack that involved turning off the Timer 1 interrupt and restarting it after writing to the screen. This essentially gives us infinite time to write things to the screen.

3.2. Hardware Details

This section describes the hardware related components of our projects. Based on the descriptions and circuit schematics, our hardware can be replicated by anyone who has access to this document.
3.2.1. Transmitter Side

Hogu
Initially we attempted to implant accelerometers into our hogu. After a couple of days of experimentation the accelerometer idea was dropped. The main reason for not pursuing the use of accelerometers was that they are unreliable. The unreliability stems from the accelerometers inability to differentiate motion from impact. If the hogu is stationary and a force is applied to it, the accelerometers will output a voltage as desired. However if the hogu is in motion the accelerometers will also output a voltage, which is undesirable. We searched for an alternative and came across piezoelectric sensors. These sensors output a voltage upon impact but output only a very small voltage when in motion. We were able to sample nine sensors and implanted them into the hogu. The sensors do not need to be connected to a power supply for operation. Each sensor has a negative lead and a positive lead. All nine negative leads are soldered together and all nine positive leads are soldered together. The negative leads are not a hard ground so they are connected to the MCU ground on the prototype board. The output voltage is taken between the positive leads and the MCU ground. The output voltage waveform is related to the force of impact, which is proportional to the acceleration of impact. A solid strike can result in peak output voltages around 15V. The output voltage is cut by a voltage divider to produce lower voltages which are more meaningful. This is explained in the section below.

 Parts List:

For more detail: Electronic Impact Vest Using Atmega32