High-Level Design

Fight Coach hardware is organized into 4 main subsystems:

• Power management - responsible for providing the Fight Coach with lightweight, recheargeable power.

• MCU - The ATMEGA32U4 microcontroller

• Bluetooth Module - The RN-41 Bluetooth wirelress transceiver

• Accelerometer and Gyroscope  - The MPU-6050 IC by Invensense

• Motion data, generated by the MPU-6050, is obtained by the MCU via i2c, and the MCU then transmits that data to a

Bluetooth module via UART, which in turn gets displayed and processed on a matlab terminal.

Figure 1 as shown below shows our user interface

Our User Interface had to accomplish the following functional requirements

• The user interface shall display athletic performance statistics in real-time

• The user interface shall gauge the athlete's defensive abilities by sending audio commands that would simulate strikes

from an opponent.

• The user interface shall display the athlete's defensive performance in real-time.

• The user interface shall gauge and display the athlete's damage output.

• The user interface shall play the Street Fighter Theme once the intensity of their practice session has surpassed a level  of

the user's choosing.

• The user interface should display the date and time of each practice session

• The user interface shall allow the athlete to switch between the different practice modes, and audibly indicate which mode

the user has selected.

• The user interface should store the data generated by the session so that the athlete can log and track his performance

over time

We decided that the most efficient way to implement the aformenetioned requirements is to use Matlab. The alternative was

to test our questionnable objective-C abilities and write an iPhone app that would accomplish the user inferface requirements,

but we decided that it wouldn't be worth the risk.

Matlab provided us with a variety of key benefits. The serial object allowed us to easily create a program that would interface

with the computer serial port (which was receiving data from the bluetooth module on the Fight Coach) with the 'fopen()' and 

'fscanf()' commands. Also the 'audioplayer' object made it easy to implement the audio requirements of our system.

Implementation details of the user interface can be found in the Software section.

We chose the MPU-6050 because it integrates an accelerometer and gyroscope into small, power efficient package. When

considering the wide range of available accelerometers, we initially considered the MPU-6000 for its SPI capabilities. However

logistics (quantities available on digi-key, and shipping times) prevented us from using the MPU-6000 and so we opted for the

MPU-6050  We also chose the MPU-60XX family because of its Digital-Motion-Processor, which allows us to offload some of

the MCU computation onto the MPU-6050 so that more complex motion processing algorithms could be implemented. In

particular, the Digital-Motion-Processor would allow us to implement a Mahony filter, that would allow us to more accurately

obtain the attitude of the sensor (more details on our implementation attempt and failure is disccussed in the Sofrware

section).

Our bluetooth transmitter is the largest component on our board. Also, it is the most expensive. We looked at other smaller

and cheaper class II bluetooth modules (in particular, the RN-42 by Roving Networks, and the PAN1325 by Panasonic), but we

realized that their range was around 10m (which is slightly smaller than the size of an MMA Octagon). Furthermore, we

wanted the OSF to work in a large room with a fixed MatLab terminal, and so we favored the long-range RN-41.

What was also helpful was that the documentation for both the RN-41 and RN-42 was thorough and comprehensive (the

development kits were also on the more affordable side).  Furthermore, setting parameters such as the baud rate and error

control could be done without reprogramming the module's firmare.

We chose the LiPo 3.7V 110mAh because we believed that it was the optimal size and weight for a 2-3 hour training session

with the atmega32u4 drawing approximately 10mA (p 379 in manual) and the RN-41 drawing 30mA (p 2 of RN-41 Manual) .

At 2.65g, the battery still carries a weight less than a percent of  the weight of even the lighter-style sparring gloves (12oz

sparring gloves). The dimensions of the battery (5.7x12x28mm) also make it well suited, and small enough to fit inside most

adult sized boxing gloves or muay-thai shin guards. (https://www.sparkfun.com/products/731).

 

One of the main reasons that we chose the ATMEGA32U4 was because it could be programmed via USB (all atmega32u4's

are preprogrammed with a USB bootloader according to the first page of the datasheet ). This means that, if the device were

to be enclosed or embeded within a boxing glove or other encasing, that developpers and athletes could still reprogram the

hardware as needed via USB, without the need to access ISP pins (PB1 PB2 PB3 and PB13) i.e the spi pins MISO, MOSI,

SCLK,RST and GND. In other words, it is possible to design a board around the ATMEGA32U4 with no ISP headers and just a

USB, which is really helpful for minimizing size and weight of the device. However, due to reported difficulties with working with

the DFU bootloader (the bootloader that allows programming via usb). As a result, although we originally designed our board

to only include a micro-usb connector, we also included ISP-headers, to account for the possibility that we would never be

able to properly configure the DFU bootloader.

Including the ISP-headers turned out to be crucial: we were set back a week trying to get the DFU bootloader to work to no

avail (we still don't know why). Thus, as the project demo deadlines approache, we fell-back on our backup plan and

bootloaded our MCU's via ISP (with avrdude and the avrispmkII).

Link describing the difficulties in handling the DFU bootloader: http://blog.komar.be/using-atmels-dfu-bootloader-abi-on-

I2C is a simple two wire interface that allows microcontrollers to interact with multiple peripherals. The accelerometer (MPU-

6050) communicates with the microcontroller using this interface.

UART is hardware that translates data between serial and parallel forms, and was used to enable communication between the

microcontroller and the bluetooth module (RN-41).

Bluetooth is a wireless technology standard for exchanging data over short distances from mobile devices. We used bluetooth

to send motion data from the microcontroller to a MatLab equipped device that can receive and display fighter statistics in real

time. Note: since we are using a class 1 Bluetooth transmitter, the effective range of OSF is 100 meters (approx. 330 feet).

Wireless capabilities of the Fight Coach are provided by RN-41 modules, which meet FCC standards (FCC CFR47 Part 15 C,

para 15.247, FCC ID: T9J-R41-1), and are class 1 output transceivers with a range of 100m at 2.4GHz ISM band. Since the

bluetooth stack responsible for power output and range cannot be accessed by the user, Fight Coach cannot violate FCC

interference, maximum power and frequency hopping specifications that ensure that electronic devies nearby aren't disrupted,

and that human radiation absorption isn't an issue. All of the parts that we have selected (shown in the Bill of Materials) are

RoHS compliant to ensure that only safe materials are used in the production of Fight Coach.

 

Hardware Design

Figure 2a/b below shows our hardware schematics (Click for higher resolution)

 

As discussed in the tradeoffs section, one of the main reasons that we chose the ATMEGA32U4 was because it could be

programmed via USB, making it easy for developers to reconfigure the Fight Coach sensors to their desires. The

ATMEGA32U4 has a plethora of other features, and the following list describes only but a few of the most pertinent functions

that we found useful for the Fight Coach (in no particular order)

• 32K Bytes of In -System Programmable (ISP) Flash

• 2 16 bit Timers with separate Prescaler,compare and capture mode

• programmable USART with hardware flow control

• USB 2.0 Device Module

• 26 Programmable I/O lines

• small, 1cmx1cm TQFP package

• 8MHz at the 3.3V range

Custom board design and production

Figure 12 below shows the layout of the PCB boards for Fight Coach.

 

When we began this project, we knew that the Fight Coach would be subject to the conditions found in typical fight scenarios

(sweat, spit and possible even blood), which is not exactly ideal conditions for electronics. After considering the high-

impact/humidity environment that the Fight Coach would be subject to, we realized that we needed to design it small, light

and durable. To meet this goal, we needed to create a custom board that would include all of the necessary components in

the smallest package, and then encapsulate it in epoxy to create a water-resistant, protected package. We then designed our

PCBs and ordered them from quickTurnPCB (http://quickturnpcb.co.kr/quality.php)  approximately 1 month before final

project season began (the lead time for ordering PCBs varies anywhere between 3 to 5 weeks, though there are some

manufacturers that can do it faster (http://tinyurl.com/72nmt6p).

Our first PCB design minimized the number of QFN packages used, and used 0603 packages for the resistors and capacitors

(they are easier to use for hot-plate reflowing since they are bigger). This is because 0402 and QFN packages are extremely

difficult to sodder by hand, though soldering tutorials using hot-plates can be found here

(https://www.sparkfun.com/tutorials/59#Hot-air).

Fortunately for us, we were able to work out an agreement with my old employer, Mara Technologies

(http://www.maratech.ca/) so that they could could use their soldering machines to populate our boards for us. This meant

that our latest PCB design (as shown above) could use the smallest available packages for resistors and capacitors (0402) as

well as QFN packages for our final board design. Thanks Frank!

We learned early on that using a rechargeable battery, such as the LiPo on Fight Coach, meant that we needed to incorporate

circuits that would provide undervoltage protection and charge management for the LiPo and reverse discharge protection.

The first major power management component is the MCP73831: a linear charge management controller that employs a

programmable constant-current/constant-voltage algorithm. This was needed to make sure that charging the LiPo battery via

the USB would not damage or break the battery. By setting the programming resistor (at pin 5 of the MCP73831), we were

able to set the charging current to 100mA (the datasheet for the LiPo batteries show that with a charge current of 100mA,

charge times are approximately 3 Hours). Another nice aspect of the MCP73831 is the fact that it has an indicator pin that is

pulled HIGH when it is done charging. This was used in conjunction with a yellow LED light to indicate when Fight Coach was

charging, and when it was finished charging.

Since our LiPo batteries produced variable voltages between 2.7V and 3.7V, we needed a component to convert that voltage

into a constant 3.3V (all of the most important components operated at around this voltage) . Since we wanted this voltage

conversion to occur as efficiently as possible, this drove our decision to employ the TPS63031, a buck-boost converter by

Texas Instruments.  The buck-booster takes the variable battery voltage(3.1-4.2V) and converts it to the 3.3V (with up to

96% efficiency according to the datasheet) with needed by the MCU, accelerometer+gyroscope and the bluetooth module.

We weren't sure about the behavior of the power save mode for the TPS63031, and so kept it HIGH, but in future revisions,

this pin should be set LOW so that the device can oeprate more efficiently

The TC54 served two purposes: to protect against corrupted memory, and to protect the LiPo battery from reaching its

undervoltage.

The LiPo battery is one that cannot be used if its output voltage is below its undervoltage (which causes it to break). This

means that devices using a LiPo battery must have a component which disables the battery before it goes below its

undervoltage, so that the battery doesn't break. The TC54 acts as a voltage detector, and goes LOW once it detects the

battery voltage going below 2.7V. This disables the buck-boost converter, effectively preventing any current from coming

from the battery, thus, protecting the battery from operating in its undervoltage. 

Another consequence  of using the LiPo battery (and batteries in general), is that all of the components were subject to a

powersource that could be enabled or disabled with time. Furthermore, sometimes the powersource will turn on and turn off

within a very short period of time which can potentially corrupt the memory of the MCU. The TC54 protects the MCU by

introducing a delay time between when the battery voltage has surpassed the undervoltage threshold (2.7V) and when the

buck-boost converter is enabled again. In other words, the TC54 ensures that the MCU (and all devices connected to VCC)

only receives power once the battery voltage is reliably above 2.7V for at least 0.2msecs, and minimizing the chance that

MCU memory is corrupted by an unstable power source.

The MPU-6050 is main sensor for the Fight Coach. It includes an accelerometer and a gyroscope in a small package, and

interfaces with the MCU via I2C. A lot of the MPU-6050 is programmable via I2C, and so hardware configuration with this

component was minimal (we just followed the deafault typical operating circuits that were described in the datasheet p22 of

version 3.4).

The RN-41 is the bluetooth transmitter for the Fight Coach. The module is a relatively low power transmitter (30mA during

connection, <10mA while sniffing) with a range of up to 100 meters. The RN-41 comes with TX, RX, CTS, and RTS pins that

allows it to communicate with the MCU via USART. Although we connected the RN-41 so that USART communication is

possible, we did not implement it in our code (since we were not familiar with USART flow control protocols).

Using Command Mode to set the Baud Rate

One of the most time consuming bugs that we encountered while developping Fight Coach was debugging the I2C

communication. We noticed that we were not able to communicate with the MPU-6050 and obtain its accelerometer and

gyroscope data, even though we thought that we had correctly configured the circuit and used the right code (I2C routines

courtsey of Peter Fleury).

Our first debugging step was to verify that we were using the right address, so we used an oscilloscope to take a look at the

signal on the SDA and SCL lines as shown in the figure below.

We had originally suspected that the MPU-6050 was burnt out because we had connected it wrong. What also led us to

believe that the MPU-6050 was that we had also used the MPU-9150 development kit, which is supposed to have the same

setup as the MPU-6050 (we got the MPU-9150 working just fine, and so we wondered why the MPU-6050 wasn't working

and concluded that it was broken).

Probing the I2C lines turned out to be crucial: the scope showed us that the MPU-6050 wasn't broken (as we had originally

suspected). In fact, it was giving us an ACK. This was also verified by writing an I2C sniffer (a script that just sends out

i2c_start(address) and sees which addresses return an ACK).

At this point we were able to verify that the reason we weren't able to get data from the MPU-6050 wasn't a hardware

failure, but a software failure. Still, it was important to verify that all of the hardware was in place before moving on to fix I2C

in software (as discussed in the software section)

This debugging process could have been shortened if we had extra MPU-6050's on hand so that we didn't prematurely

conclude that we had broken our only sensor(which would have led to a more thorough search through our software instead

of spending time debugging hardware). So word of advice: always order extra parts (3 or even 4 more in addition to the ones

that you need for development ) if you are on a tight time budget and don't mind spending extra coin so that you don't lose

your precious time during final project season.

As you attempt to connect your LiPo batteries to our projects, you will most likely short them at some point. During Fight

Coach, we shorted our batteries at least 2 times (because I was wearing my class ring) and we needed to reset them to that

they could work again. Instructions on how to reset a LiPo battery were found here

(http://www.tictoctrac.com/soldering.php#lipo) , but the steps taken were as follows

1. Remove the short and disconnect the battery from the load.

2. Remove the yellow protective tape from the LiPo battery, unfold the protection circuitry.

3. Desolder the positive lead on the protective circuitry. This should reset the cirtuit.

4. Resolder the positive lead of the protection circuit and test

Thanks TicTocTrac for the tip!

Lesson: Don't wear any metallic rings/watches/necklaeces while working with electronics!

• ls /dev/tty.*
• this, combined with the screen utility, is useful for observing serial data using Terminal.
• Download and install macports
• this, combined with the screen utility, is useful for observing serial data using Terminal.
• CrossPack
• Installing it gives you GNU Compiler suite, AVR-GCC, avrdude. This allowed us to bootload the MCU from Terminal
with the following command (with the AVRISPMKII programmer)
• avrdude -p atmega32u4 -c avrisp2 -F -U flash:w:main.hex
• http://www.obdev.at/products/crosspack/index.html

The video below shows the inconsistent performance of the Mahony implementation

 

 

the stateAccumulator.