Testing the PmodACL and LabVIEW on the Race Track

Recently I released a collection of projects going over how to use LAbVIEW,  the chipKIT Max32, and the PmodACL to do some neat stuff with accelerometer data. These include filtering, multidimensional vector plots, and tilt measurement.

 

Filtering

 

Multidimensional Vector Plots

 

Tilt Measurement

 

The inspiration for these projects came from an earlier prototype I designed to measure g-force vectors and tilt angles experienced in a car. My goal was to collect some data about how my car performed while turning. This was particularly important to me because I like to autocross in my spare time.

 

At autocross events, I had been told by other racers my car had a lot of body roll, which can make the car difficult to drive. I figured I could build something that would measure how much body roll my car had as well the g-force levels that caused my car to slide on the race track. Unfortunately, I didn’t have as much time as I would have liked between the autocross event and the inception of my prototype. I had to rush the project a bit to get it finished in time, so my first real test was on the track.

 

Location of the tilt/g-sensor in my car.
Me and a friend testing out my project prototype on the track.

 

Here is a video of the prototype in action:

 

If you watched closely, you could probably tell most of the readings are not correct. The video shows I was getting roll values over 45 degrees, meaning my car would have been up on two wheels and probably flipped over. Since correct angle readings are needed to filter out the effect of gravity, my g-force values were also off.  I had overlooked the fact that additional acceleration vectors during the race would throw off my calculations. At my desk everything worked great because only gravity was acting on the device, meaning there were only 3 degrees of freedom to measure.  While moving on the race track, there were 6 degrees of freedom to consider. So if I had wanted to get the correct measurements while driving, I would have needed to record 6 data values, 3 values from the accelerometer and 3 from an additional gyroscope. Unfortunately, I didn’t realize this until after I saw my bad data. Still, I had a ton of fun testing the prototype and know how to remedy the issue for the future.

 

While I was at the track I got to see some pretty interesting cars and figured I’d share the photos.

 

 

Close-up of the Viper at an autocross event in Boise.
Close-up of the Viper at an autocross event in Boise.

 

This last car deserves an honorable mention. It is a 3rd gen Dodge Viper SRT-10 that has a 8.3 Liter V-10 (making 510 Hp and 535 lb·ft of torque). The owner modified the car with a custom suspension and race tires specifically for autocross. I was lucky enough to get a ride in it at an autocross event down in Boise, and it was mindbogglingly fast! The owner consistently put up some of the fastest track times of any car at either event.

 

I hope you enjoyed the pictures and my LabVIEW projects. If Autocross looks interesting I HIGHLY recommend finding your local group and going to an event. The people are VERY friendly and racing is TONS of fun!

Author

Be the 1st to vote.

2 Comments on “Testing the PmodACL and LabVIEW on the Race Track”

  1. I am trying to set up the same accelerometer with arduino mega 2560. Whenever i run labview 2013 i get a 5003 error. “One of the possible reasons is that specified I2C Chanel (13) is not available on the Arduino Mega 2560l”.

  2. That error can happen for a number of reasons. I ran into the same error but it was because I was stopping LabVIEW with the abort button in the top tool bar. I found out I should have been using a stop button placed on the front panel instead.The reason for this is when you call the ADXL345 “Initalize.vi” one of the things it does is ask for permission to use the I2C channel. Once you are given permission LabVIEW will assume you are using the channel until you say otherwise. One of the things the ADXL345 “close.vi” does is notify LabVIEW you are done using the I2C channel. So when I was hitting the abort button, it immediately interrupted LabVIEW and didn’t let it do anything else. As a result the ADXL345 “close.vi” was never called meaning next time I ran my project LabVIEW thought the I2C channel was still in use. My advice is to use highlight execution, or place a probe and see if the “Close.vi” is ever being executed.If that doesn’t get you any closer to solving your problem try posting your question here https://www.labviewmakerhub.com/forums/

Leave a Reply to Davis Cancel reply

Your email address will not be published. Required fields are marked *