of 12
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
7/22/2019 Motion Capture and Recognition Using an IMU
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,
7/22/2019 Motion Capture and Recognition Using an IMU
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
7/22/2019 Motion Capture and Recognition Using an IMU
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.
7/22/2019 Motion Capture and Recognition Using an IMU
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.
7/22/2019 Motion Capture and Recognition Using an IMU
6/12
- 6 -
Figure 3(a): RL-FlashFS
Figure 3(b): !C/FS Architecture Figure 3(c): FatFS Architecture
7/22/2019 Motion Capture and Recognition Using an IMU
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
7/22/2019 Motion Capture and Recognition Using an IMU
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
7/22/2019 Motion Capture and Recognition Using an IMU
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
7/22/2019 Motion Capture and Recognition Using an IMU
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.
7/22/2019 Motion Capture and Recognition Using an IMU
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.
7/22/2019 Motion Capture and Recognition Using an IMU
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