Autosport Labs

Hello,
I manage to do my first laps with RaceCapture Pro, and get some good results with TPS and Speed.
However, accelerometer and gyro seems to be too noisy to be used.

Here are some samples :
* http://up2sha.re/file?f=ZkzK6decOo5e
* http://up2sha.re/file?f=JmGqqo6gTLrK

How could I improve it?
Also, is it possible to retrieve lean angle from roll rate?
Is it possible to retrieve lateral / longitudinal acceleration from GPS signal?





I also noticed that the GPS map is not realistic compared to the actual track layout (http://binged.it/10bEaNg). If I import the data in GEMS, the layout is much more accurate :
Race Analyzer: http://up2sha.re/file?l=GwArqC9xTz2M.png

GEMS:
http://up2sha.re/file?l=HMWOo9Xq7fNZ.png


(Also img tags doesn't seems to work on the forum >>

Up !!!
Any news on this issue?

Neoraptor,

How are you mounting the unit? Using good vibration isolation is absolutely critical for getting clean accelerometer data.

My post near the bottom has a link to images of my mounting: http://www.autosportlabs.org/viewtopic.php?t=3843

In addition, once I do that, I then use a low pass filter I wrote in Excel to remove additional noise. Check out my posts here: http://www.autosportlabs.org/viewtopic. ... pass#19507

I don't think that has the actual excel file. I'll look to post that later.

Thank you for the hint.
I indeed have mounted my unit directly on the tail (metal against metal). Hence a lot of vibration may be transmitted and my data completely unusable.
I will try to add some isolation between the unit and the tail.

Is there no plan to implement filtering function on those values (gyro + acc) ?

Brent told me via email that they were looking to implement a 50hz low pass filter in the software at some point. He said it's 1khz in the hardware.

I'm personally trying some rubber mounts but have yet to get out on track with any steady g forces so I have no idea how it's going to work, but if it does work ok I'll certainly share information here.

I've mounted mine to the lid of a Tupperware box, which is then bolted to the spaceframe. The Tupperware box provides isolation from vibration, water and dust. No problems with vibration at all.

Nice idea Andy !!
Do you have some pic of the mount?

I won't be able to get any photos for some time as the car isn't nearby. However, it's a box like this:

I drilled holes in the lid to mount the RCP on the two standard mounting holes, obviously bolting it to the inside of the lid. I drilled holes to match up with holes in the floor and bolted it on. I drilled a large diameter hole (22mm, I think) in the lid for the cables to go through and wired it up. The cables come from below through the lid so that rain doesn't come in the top as the car has no roof and so that any water could drain out the bottom on the offchance it got in there. I've not sealed it. The reason I mounted the RCP to the lid was that when you take the bottom off the Tupperware (it's mounted upside down, of course), you can easily press the button on the front and pull the SD card out. The cabling is also easier if you can reach from the sides.

neoraptor wrote: However, accelerometer and gyro seems to be too noisy to be used.

I totally agree with you. See these related topics:
http://www.autosportlabs.org/viewtopic.php?t=3843
"At the request of other users we've disabled the software averaging until we come up with a more refined solution, such as performing oversampling and averaging those samples."

Dunno why people would request this to be disabled since without filtering/averaging the signal is so noisy that it's practically useless without post-processing.

http://www.autosportlabs.org/viewtopic.php?t=3836

IMHO, post-processing externally is not an option. This needs to be done in RaceAnalyzer with a configuration setting to filter/average the data as it's recorded, or there needs to be an option in the analysis to smooth the signals.

Guys, I was one of the ones that asked for the averaging to be disabled.

My reason was that the averaging was a trailing moving average, which means that your data will always lag "real life" by the number of averaged samples times your sample time. For example, if you sample at 1 Hz (for long runs), your accelerometer data will trail your GPS data by about 5 seconds, and you will dampen all of the peaks off.

The best way is to over sample (at like 1kHz) and do a centered average. You then do low pass filtration in software so you can control where your cutoff points are. This should be added to race analyzer, but until then, I post process in Excel.

In addition to adding the smoothing to RaceAnalyzer as a post-process (and now, mobile app), we're also going to experiment with what we can do on the fly in RCP firmware - possibly by re-adding a setting to configure an averaging buffer that might be useful for higher Hz sampling rates.

Thanks for the feedback / ideas everyone!

dimondjack wrote:Guys, I was one of the ones that asked for the averaging to be disabled.

My reason was that the averaging was a trailing moving average, which means that your data will always lag "real life" by the number of averaged samples times your sample time.

I figured as much, because phase shifts can occur with moving averages. How about filling the buffer before recording starts? Or actually, RCP could just automatically keep a rolling buffer whenever it is on, so there is no perceptible lag to the user when they press start recording.

brentp wrote:we're also going to experiment with what we can do on the fly in RCP firmware - possibly by re-adding a setting to configure an averaging buffer that might be useful for higher Hz sampling rates.

Thanks for the feedback / ideas everyone!

My suggestion.
http://www.autosportlabs.org/viewtopic.php?t=3976

I'm all for having user configurable options. However, having a rolling buffer is the same as having a rolling average. The startup reading isn't the problem, it is the fact that you are averaging 10 data points in the past. When using a simple moving average you want to make sure to center your average, meaning you take an equal number of points before and after your time point. RCP could do this, but it would need to not record a value for a given point until it has "recorded" the future data points.

I think this may come down to how much post processing people would like to do. I'm much more inclined to have limited processing in firmware and then do all of it in software. This gives you the option of preserving your raw data and playing around with different filters. If you only record an "altered" data stream, you'll never be able to truly get your "raw" data back and try a different filter.

I agree with the above. I wouldn't want modified data in a log, I'd want actual raw data that I can then circle back and manipulate and try different values to give me the output I'm looking for.

With the filtering enhancements we'll be adding, you will have the option for raw or filtered values.