Motion Capture and Recognition Using an IMU

7/22/2019 Motion Capture and Recognition Using an IMU

1/12

- 1 -

Motion Capture and Recognition using an

Inertial Measurement Unit (IMU)

Project Report, Fall 2013

Project Team

Joseph Weber

Pablo Quevedo

Jacob Travis

Course Instructor

Dr. Samir Rawashdeh


2/12

- 2 -

1.ABSTRACTMotion tracking devices are becoming widely adopted by smartphone and tablet

manufacturers due to the added user experience and enhanced capabilities. Applications usingmotion-tracking technology range from health to aerospace and location-based monitoring

services. InvenSenses MPU-9150 is the worlds first 9-axis motion tracking device that satisfies

the key requirements of a motion-interface enabled device: small size, low power consumption,

high accuracy and consistency, high shock tolerance, and application specific performance

programmability. The MPU-9150 is comprised of a three-axis gyroscope, three-axis

accelerometer, and three-axis magnetometer. It also features a Digital Motion Processor engine,

I2C communication interface, interrupts, and sensor data registers.

The objectives for this project are to record data from the MPU-9150 onto a Kingston

Micro-SD card, enable triggered recording based on predefined conditions, and to implement an

additional feature chosen by the project team. !C/OS-II is the chosen operating system for this

project, due to its low footprint (5-24 Kb), portability with the STM32F4-Discovery board, real-

time multitasking kernel, and its numerous software certifications (FDA Medical Pre-Market,

Avionics DO-178B, SIL3/SIL4 IEC, and MISRA-C). This report provides an overview of the

project objectives, implementation of the I2C protocol, details of register communication, and a

summary of the obtained results

2. GENERALREQUIREMENTSPECIFICATIONS

Requirement #1 entails the base functionality of recording motion data on the Kingston

Micro-SD. To accomplish this, !C/OS-II must first be ported to the STM32F4-Discovery board.

Micrium has provided its customers with an example kernel port to the STM32F4. In addition to

experience gained from Dr. RawashdehsExperiment 7: Dining Philosphers and Semaphores

Laboratory, the team successfully initialized and tested code with !C/OS-II. The first task was to

establish confirmation of communication between the MPU-9150 and the STM32F4 using the

I2C protocol. The I2C protocol classifies the STM32F4 as a master device and the MPU-9150 as

the slave device. The SCL and SDA signals synchronize data transfer between the two devices,


3/12

- 3 -

and are necessary while using I2C, in addition to VCC (3.3V) and GND. The team successfully

established communication between the two devices, as shown in Figure 1(a). This image shows

transmission in master transmitter mode, following by transmission in master receiver mode in

Figure 2(b). Channel 1 corresponds to the serial data line (SDA), and Channel 2 corresponds to

the serial clock line (SCL). During the 9thclock pulse of SCL, the MPU-9150 sends an

acknowledgement indicating that it has correctly received the data transfer (illustrated by the low

clock pulse).

Figure 1: DPO Oscilloscope Confirmation of I2C Master Transmitter Mode

Scoping the transmission data, as shown in Figure 1, was a nontrivial process. The team

encountered a clock-stretching issue, a situation when the slave device pulls down the serial

clock line while waiting for a stop bit. A temporary solution to this issue was to add an

I2C_stop call between the transmitter and receiver code blocks. This reactivated the SCL line

and the receiver signal functioned as expected. This solution is provided in the following code

snippet, indicated by the 5thfunction call:

Code Segment 1: I2C Solution


4/12

- 4 -

The problem with calling I2C_Stop before the final data transaction occurs is that future

register reads may potential output garbage data because the I2C transaction is being reset after

the temporary I2C_stop function is called. This issue was closely monitored and documented,

although later overlooked when we received the correct gyroscope data from the MPU-9150

registers. The oscilloscope output of the I2C master receiver mode is illustrated in Figure 2.

This output shows the data bits transmitted during the two clock cycles before the origin. The

master receives the NACK from the MPU-9150 indicated by the short pulse at the origin, on the

falling edge of SCL.

Figure 2: DPO Oscilloscope Confirmation of I2C Master Receiver Mode

The basic hardware requirements for the project include the MPU-9150, STM32F4 Discovery,

STM32F4 Baseboard, and the Kingston Micro SD. The hardware overview for Requirement #1

is shown in the following figure, along with the key features of the MPU-9150. The Discovery

board was programmed with !C/OS-II using the Keil MDK toolkit. In Requirement #2, the

Kingston Micro-SD card was formatted, inserted into the Discovery Baseboard, and the

Baseboard was attached the STM32F4-Discovery. Figure 2depicts

a basic hardware overview for Requirement 1.


5/12

- 5 -

Figure 2: Wiring Diagram and MPU-9150 Specifications

After the I2C setup, the team conducted a technological survey to identify the most

appropriate file system more storing raw data from the IMU to the Kingston Micro-SD. The file

systems that were surveyed include RL-FlashFS, !C/FS, and FatFS. Software architectures forthese file systems are illustrated in Figure 3(a-c). Keils real-time operating system RTX is

designed for RL-FlashFS. The team chose the open source file system FatFS for its compatibility

with real-time operating systems, including !C/OS, and its wide use in embedded devices.

Before SD initialization took place, the Micro-SD card was formatted to FAT32 on a desktop

computer. Next, the STM32F4 Discovery board was connected to its Baseboard, containing the

Micro-SD slot. The SD initialization code was analyzed within the file STM32F4DIS-BB

Software Examples 20130307.zip. From here, the team included the relevant SD initializations to

the !C/OS-II user paths. Files accessed within the BB Software Example folder include diskio.c,

ff.c, and stm32f4_discovery_sdio_sd.c, all of which are located within the

STM32F4xx_SDIO_Example folder.


6/12

- 6 -

Figure 3(a): RL-FlashFS

Figure 3(b): !C/FS Architecture Figure 3(c): FatFS Architecture


7/12

- 7 -

The SD card initialization takes place within a task called SD_task(). The low level disk

I/O skeleton for FatFS was added to the projects path, in addition to the generic FAT file system

module, ff.c. During initialization, the file system is mounted and a text file called HELLO.txt is

created on the Micro-SD card. Confirmation of this procedure is shown in Figure 4.

Figure 4: Micro-SD Test File Creation

Figure 4shows LED 3 active, indicating that the procedure has completed and the

program has entered the infinite loop and is toggling the LED with the call

STM_EVAL_LEDToggle(LED3). The next step was to transport this code to !C/OS from the

working FatFS project. We created an additional task called File_System(), added the contents of

main() from the working FatFS project to the task. At first when the FatFS code compiled, we

did not receive a blinking LED confirming successful .txt file creation on the Micro-SD. !C/OS

has an alternative design for predefining interrupts, so addressing this issue became necessary

before execution could reach our File_System() task. We discovered that interrupts from

multiple peripheral files were the cause of the issue. Next, we identified the corresponding,

predefined interrupts within !C/OS and manually altered their corresponding interrupt handler

functions by adding an SDIO process. This manual configuration of the interrupt handlers within!C/OS yielded instant results of a fully-functional file system, once the program was

downloaded to the Discovery board. LED 3 flashed, indicating the test file had been created. We

changed the file name to HELLOWORLD1.txt within the File_System() task, and confirmed the


8/12

- 8 -

presence of this new file on the Micro-SD. Finally, we routed the MPU-9150s data from the I2C

bus to the SD card through a message queue.

Figure 5: !C/OS Mailbox Communication

After the SD card procedure, the MPU-9150 register map was analyzed, particularly the

gyroscope, magnetometer, accelerometer, and temperature registers. In order to test the I2C

functionality with the temperature register, an MPU manager task, named MPU_DataRead(),

was created in the OSTaskCreate() function. Since each task requires its own stack, the static 16-

bit data structure MPU_DataRead_Stk was appended to OS_STK. A function named

mpu9150_regread was created for handling the general I2C calls. Within the MPU_DataRead

task, data from the temperature sensor of the MPU-9150 (Reg 41 & 42) was accessed and stored

in an array. Initially, we encountered an issue of the register-read defaulting to 0x68. It was

evident that the temperature sensor was functioning when we pressed firmly on the chip and

watched register values increase on the oscilloscope, confirming that the chip is responding. We

decided to experiment with reading data from the gyroscope register instead of the temperature

registers. This proved successful, as the register data no longer defaulted to the value 0x68, and

data gathered from the gyroscope fluctuated based on the act of moving/tapping the MPU-9150.

The last step in providing full file system functionality was to configure the SPI

peripheral and configure the necessary pins on STM32F4. SPI is a four-wire serial bus,

comprised of the SCLK, MOSI (master out, slave in), MISO (master in, slave out), and SS


9/12

- 9 -

signals. The SPI bus operates in full duplex mode and during each SPI clock cycle, and the

following data transmission occurs: 1) The master sends a bit on the MOSI line; the slave reads it

from that same line, and 2) The slave sends a bit on the MISO line; the master reads it from that

same line. The use of either SPI or I2C is application dependent. Since Kingston Micro-SDs

provide an optional SPI bus, we saw it as an opportunity to learn more about this peripheral and

contrast it with I2C. A visual overview of these two protocols is provided in Figure 6.

Figure 6: I2C & SPI Example Configurations for a Single Master Device

Requirement #2 entails the ability of triggered recording. This could be accomplished in a

number of ways. For example, we could set a motion detection threshold (Reg. 31, MOT_THR)

in parallel with a zero-motion detection duration (Reg. 34, ZRMOT_DUR) to allow recording

only when the motion detection level has surpassed a certain value. Both of these registers are

accessible through Invensenses Embedded Motion Driver v5.1.1. Triggered recording can be

achieved without the use of the portable drivers; however, the ability to utilize these functions

will greatly increase the functionality of the device. We initially experimented with a bottom-up

approach by explicitly creating our own register read functions. After data was successfully

retrieved from the gyroscopes register, we decided to revise our initial method of porting eMD

to the STM32F4, which would provide a more advanced communication line between the

Discovery board and MPU-9150. The Embedded Motion Driver (eMD) contains the code for

configuring the MPU-9150 using the Digital Motion Processing (DMP) hardware features. All of

the source code of eMD is written in ANSI C and can be compile in C/C++ environments. The

sensor driver layer in eMD is contained within the files inv_mpu.c and


10/12

- 10 -

inv_mpu_dmp_motion_driver.c. The file inv_mpu.c is an I2C-based driver for Invensense

gyroscope, and inv_mpu_dmp_motion_driver.c contains the DMP image and interface functions.

The API commands of greatest relevance to Requirement #2 are shown in Figure 7.

Figure 7: eMD API Commands to Enable Triggered Recording

Before these API commands were tested, the team worked endlessly to port the driver to

the STM32F4-Discovery Board. Using the eMD drivers, we retrieved raw values from the MPU-

9150, although some of those values did not change and others were too insensitive to be usable.We decided to continue with our low level implementation, which allows us to explicitly grab

the low level values from the registers on the gyroscope and temperature sensors. We can see the

SDA line toggling on the oscilloscope, in real-time, demonstrating that the data in the registers is

changing. Although triggered recording was not implemented using the Embedded Motion

Driver through the use of eMD API calls, we completed Requirement #2 manually setting the

zero-motion threshold and zero-motion duration registers. A GPIO interrupt was set up on the

board to capture an interrupt sent by the MPU over the INT line. This interrupt switched a flag

called IN_MOTION in our code. The flag determined whether we record or not. The

following code snippets shows our implementation of the interrupt handler.


11/12

- 11 -

Code Segment 2: Flag Conditions

Code Segment 3: OSFlagPend() within IM_Data_Read()

The team was able to successfully write IMU data to the sd card. The data is currently

stored as literal hex, so the transfer to ascii characters is unreadable. Output from a HEX editor

reading the file is shown below in Figure 8. The data shown, starting from the right, is

temperature HI and LOW bits, accelerometer X HI LOW, Y HI LOW, Z HI LOW, gyroscope X

HI LOW, Y HI LOW, Z HI, and then a newline. Our current version cuts off the last bit, but this

is a minor change. Also, it overwrites the file upon storing the bytes, so only 1 line will be

present per read. This will be fixed over time.


12/12

- 12 -

q.&,."|.

Translated to Hex

FF 71 00 26 F1 C0 FB 2C F7 0C BE 7C FF 0A

Figure 8

CONCLUSION

This project was an opportunity for each team member to gain experience working with

an advanced IMU, to learn more about the I2C and SPI peripherals, and how to enable the FatFS

file system with the Discovery Board. The team successfully implemented the low-level motion

driver, a working SD card driver in !C/OS, as well as time-triggered motion detection. Further

experience was gained with !C/OS, the MPU-9150, the STM32F4-Discovery board and many ofits peripherals. We now have a much stronger background for undertaking similar projects in the

future, as we have become aware of numerous beneficial applications of IMUs and Real-Time

Operating Systems.

REFER EN C ES

MPU-9150 Product Specification Revision 4.0, InvenSense Inc., Document #: PS-MPU91500A-00

MPU-9150 Register Map and Descriptions 4.0, InvenSense Inc., Document #: RM-MPU-9150A-00

SPI Block Guide V03.06, Motorola Inc., Document #: S12SPIV3/D

STM32F4Dis-BB Quick Start Manual, Embest Technology Co., LTD

Styger, E.FatFS: An Open Source File System , Embedded Computing Conference. 2011

Documents

Motion Capture and Recognition Using an IMU