The 'MotoLogger' is an Inertial Measurement Unit (IMU) designed for use with a motorcycle. Every avid motorcycle rider wants to know how fast they were going into a turn, how far they leaned over, and how good they were with throttle control (acceleration). The MotoLogger is (will be?) a cost effective way for a motorcycle enthusiast to access this information.
NOTE: MotoLogger gathers data for a curious and passionate rider, and often the rider will be going very fast and leaning over very far. This product is not intended to encourage or facilitate rekless street riding, but should be used in a controlled environment, such as a racetrack, where no expensive tickets will be issued, or large trucks will be hit.
The 'MotoLogger' will be place under the seat cowling, or mounted to the rear seat of a motorcycle. Once powered on, it defaults to the wait and test state. There are three buttons on the MotoLogger, one for selecting the mode (wait and test, record, display), one for toggling forward through the display, and one for toggling backward through the display. Once a session on the track is completed, a rider can toggle the display to see the max lean angle, max acceleration, and max velocity. The microSD card can be used to to load the data into a computer and view through a GUI.
The 'MotoLogger' uses an LPC1769 Xpresso Microprosser Unit (MCU), MinIMU-9 nine degree of freedom (DOF) IMU
, GP-2106 SiRF IV GPS unit, a microSD card, and generic LCD display.
The LPC has plenty of computing power, and uses very little power of its own, making it a good choice for a battery powered device.
The MinIMU-9 has 9 DOF's which provides the capability of calculating lean angle, velocity, turn radius, absolute position, acceleration, and more. It can be configured for different frequencies and sampling rates, which provides the option to tune the unit to riding conditions (old bumpy highway vs. smooth race track).
The GPS unit is used to gather location data, so that laps can be plotted on a map. It also provides information to be used for error correction in the velocity algorithm.
The LCD is used to display max values of a variety of measurements.
The microSD card is used to store the data for later viewing on a computer.
Currently, the 'MotoLogger' does not perform all of the design objectives. The data can be correctly written to the microSD card for future use, and the LCD is properly controlled to display the desired values. However, the data coming from the IMU is junk. It is unclear at this time if the cause is a damaged IMU, or I2C bus issues.
We encountered numerous roadblocks, as one will in any development project. They are outlined below.
We started out using the MPU-6050 by Invensense. We selected the unit because it had parameters that matched our anticipated environment, and it was cost effective. What we did not know when we selected it was that using the IMU would be virtually impossible without a custom PCB. So we had to make an impromptu switch to the pololu MinIMU-9. It took some time to learn the register structure of the MinIMU when we made the switch.
We ran into a bit of a snaffoo when we tried to use the original LCD from Digi-Key. The particular LCD is multiplexed, and intended for use with a multiplexed-LCD driver. The documentation online, as well as that which shipped with the unit, were extremely thin and did not clearly indicate that it is a multiplexed unit. It took a significant amount of time to identify that issue. In the end, we went to a local electronics store and fount a static LCD that allowed us to control every segment of the LCD individually.
We experienced issues with the I2C driver on the LPCXpresso. It is difficult to determine what the cause of failure is, but we had to reduce the I2C clock frequency down to 1kHz before we could get any data over the bus. Since we are somewhat unfamiliar with the I2C drivers, we were heavily dependent on the code provided from pololu.com, and thought it was a code bug. After using a logic analyzer on the bus and seeing that the I2C traffic looked correct, we decided to slow down the clock. In the end it worked, though we are still not clear about the details as to why.
The prototype unit is built entirely with eval boards and development kits. These items are large and also more expensive than the components themselves. Before being distributed as a commercial product, a new board will be designed that utilizes components rather than dev boards in order to reduce cost and size.
For a description of the code we used from Pololu.com, as well as the modifications we made and the functions we added, see the attached documentation.