I recently started to dissect my performance lap to lap and started to think that the acceleration data looked funny. This suspicion was confirmed when I overlaid my data with video, showing the GG plot in real time.
A little background: My RCP unit is mounted right side up with the connectors facing forward. It is almost perfectly flat in the car. On my go kart it is mounted in the same configuration, except it won't be affected by body roll (though my Z doesn't have suspension travel). My understanding is that in this configuration the Y axis is longitudinal acceleration, with + being braking and - being acceleration.
I noticed that something was up while going along the straight (supposedly full throttle) and seeing braking forces. Odd.
I then compared a calculated value for acceleration based off of speed differentials to the acceleration shown by the RCP. I took (speed1-speed2)/(time2-time1) * scaling factor of (5280/60/60/32.2) to turn it in to Gs. It isn't speed2-speed1 because I wanted acceleration to be negative. I then subtracted the hardware acceleration from the speed based acceleration, expecting that they should be close. Not at all. In absolute terms, over 9751 data points the delta is 0.5Gs. Weird. Sometimes the accel is negative when it is positive, sometimes the other way around.
Post continued next due to an annoying error in my browser that makes it so I can't see what I'm typing.
Acceleration Synchronization
-
dimondjack
- Posts: 101
- Joined: Tue Jan 15, 2013 1:37 pm
The averaged absolute value of the differential is 0.46Gs. Assuming what I'm doing is right (my acceleration plotted on speed now matches with acceleration/braking points), it appears that something is up with the hardware accel data.
To look further, I looked in Race Analyzer to check out when I was getting acceleration and braking, specifically along the main straight of NHMS, where I should be getting a constant -.3G of forward acceleration (I'm full throttle except for one shift).
I got the attached picture. I'm stumped as to what is going on. I'm most certainly not braking down the main straight, and even if I got my +/- mixed up the data still doesn't look right. Anyone have any ideas?
To look further, I looked in Race Analyzer to check out when I was getting acceleration and braking, specifically along the main straight of NHMS, where I should be getting a constant -.3G of forward acceleration (I'm full throttle except for one shift).
I got the attached picture. I'm stumped as to what is going on. I'm most certainly not braking down the main straight, and even if I got my +/- mixed up the data still doesn't look right. Anyone have any ideas?
- Attachments
-
- Acceleration Example.jpg (191.01 KiB) Viewed 5094 times
Hi,
Thanks for the write-up. What was the logging rate you had configured for the accel channels in that datalog?
I'm wondering if there's something going on with the averaging / smoothing of the accelerometer data.
Could you email me / post a link to your data file so I can take a look at it as well?
Also, try bench testing your unit to observe the accelerometer data as you change the orientation of the unit by hand. What do you observe?
Thanks for the write-up. What was the logging rate you had configured for the accel channels in that datalog?
I'm wondering if there's something going on with the averaging / smoothing of the accelerometer data.
Could you email me / post a link to your data file so I can take a look at it as well?
Also, try bench testing your unit to observe the accelerometer data as you change the orientation of the unit by hand. What do you observe?
-
dimondjack
- Posts: 101
- Joined: Tue Jan 15, 2013 1:37 pm
The logging rate is 5Hz for the accelerometers.
You can check out my log file here: https://docs.google.com/file/d/0B9Dlhiz ... sp=sharing
It is big, but not big by modern standards (10MB). However, it is the exact data I was looking at.
The accelerometer smoothing is baffling me a bit. In my mind, averaging over 2 seconds (10 data points) shouldn't matter much when you have longer, sustained corners (many at loudon). Karting or a FSAE track may have big problems with the smoothing, but the worst it can do is dampen small corners.
I did a little analysis trying to back out the delta between the 1st and 11th data point for accelerometers. I noticed that my accelerations were changing at a reasonably high rate when you consider that you are only replacing one data point in ten. In my mind, the theory is:
(A1+A2+A3....+A10)/10 = Data Point 1
(A2+A3+.......+A11)/10 = Data Point 2
Therefore, A1-A11 = 10*(Data Point 1 - Data Point 2)
Now, what does this tell us? In my mind, if I have a maximum forward and rearward acceleration of 1G, then the delta between data points shouldn't ever be more than 0.2 Gs. There will be exceptions, but it should be noise.
You can check out my log file here: https://docs.google.com/file/d/0B9Dlhiz ... sp=sharing
It is big, but not big by modern standards (10MB). However, it is the exact data I was looking at.
The accelerometer smoothing is baffling me a bit. In my mind, averaging over 2 seconds (10 data points) shouldn't matter much when you have longer, sustained corners (many at loudon). Karting or a FSAE track may have big problems with the smoothing, but the worst it can do is dampen small corners.
I did a little analysis trying to back out the delta between the 1st and 11th data point for accelerometers. I noticed that my accelerations were changing at a reasonably high rate when you consider that you are only replacing one data point in ten. In my mind, the theory is:
(A1+A2+A3....+A10)/10 = Data Point 1
(A2+A3+.......+A11)/10 = Data Point 2
Therefore, A1-A11 = 10*(Data Point 1 - Data Point 2)
Now, what does this tell us? In my mind, if I have a maximum forward and rearward acceleration of 1G, then the delta between data points shouldn't ever be more than 0.2 Gs. There will be exceptions, but it should be noise.
-
dimondjack
- Posts: 101
- Joined: Tue Jan 15, 2013 1:37 pm
My stupid browser won't scroll down when I am making a large post, so I keep having to break them up.
Looking at my data from Karting two weekends ago, 2,000 data points of 13,000 data points have a 10x delta greater than 2Gs, and 1000 of them have a delta greater than 3Gs. In my mind, this just means that the data is noisy, but it does mean that the noise is having a fairly large affect on the data. Does it matter overall? I don't know, but it does mean that heavy braking "noise" is running directly in to heavy acceleration "noise". It would have to seeing as there was a 3G swing over 1 second (I forgot, my karting data I sampled at 10Hz).
Doing the same analysis on some of the Lemons data (with a car that I don't believe can ever get over 1G of braking and 0.5G under throttle). There were 2800 of 20,000 data points with greater than a 3G swing, and 6,000 data points with greater than a 2G swing.
This could be "the luck of the draw", getting noise in one direction and then getting noise in the other direction, but it seems to happen a lot for that.
No answers, only questions!
Also, what would I be testing while bench testing? Just to make sure the axes are right and that the averaging doesn't make things too crazy?
Looking at my data from Karting two weekends ago, 2,000 data points of 13,000 data points have a 10x delta greater than 2Gs, and 1000 of them have a delta greater than 3Gs. In my mind, this just means that the data is noisy, but it does mean that the noise is having a fairly large affect on the data. Does it matter overall? I don't know, but it does mean that heavy braking "noise" is running directly in to heavy acceleration "noise". It would have to seeing as there was a 3G swing over 1 second (I forgot, my karting data I sampled at 10Hz).
Doing the same analysis on some of the Lemons data (with a car that I don't believe can ever get over 1G of braking and 0.5G under throttle). There were 2800 of 20,000 data points with greater than a 3G swing, and 6,000 data points with greater than a 2G swing.
This could be "the luck of the draw", getting noise in one direction and then getting noise in the other direction, but it seems to happen a lot for that.
No answers, only questions!
Also, what would I be testing while bench testing? Just to make sure the axes are right and that the averaging doesn't make things too crazy?
I was only suggesting to bench test to satisfy any curiosity on your part on what the system logs under varying conditions.
So far I've observed that the averaging seems to be causing more potential issues than it's resolving; I'm thinking of pushing a build that disables it for now until we come up with a better smoothing algorithm.
So far I've observed that the averaging seems to be causing more potential issues than it's resolving; I'm thinking of pushing a build that disables it for now until we come up with a better smoothing algorithm.
-
dimondjack
- Posts: 101
- Joined: Tue Jan 15, 2013 1:37 pm
Ok, sounds good on bench testing, I'll do that Friday night. The removal of averaging is probably a good thing, just so we know exactly what we are getting.
I did do some bench testing when I first got the unit, and everything seemed fine. Rightly or wrongly, I'm searching for something that will tell me if the GPS data is aligned correctly in time with the acceleration. Does the new software display speed as well as acceleration? I could floor it and see how speed and the accelerometers respond.
The GTIvideo seems to do this very well, which is why I'm surprised that I'm having so much trouble getting it to look the same. The video online looks very slightly delayed (which could be simply due to synchronization), but overall very smooth and always moving in the right direction.
I did do some bench testing when I first got the unit, and everything seemed fine. Rightly or wrongly, I'm searching for something that will tell me if the GPS data is aligned correctly in time with the acceleration. Does the new software display speed as well as acceleration? I could floor it and see how speed and the accelerometers respond.
The GTIvideo seems to do this very well, which is why I'm surprised that I'm having so much trouble getting it to look the same. The video online looks very slightly delayed (which could be simply due to synchronization), but overall very smooth and always moving in the right direction.
The new RaceAnalyzer software with the channel monitoring feature polls RaceCapture periodically for data at about twice per second; it doesn't feed data at the full logging rate. It's primarily for diagnostics; useful for configuring sensors and verification of channel data. You'll want to log data to the SD card at the full rate.
Tonight I should have a build that disables accelerometer smoothing for now; I also have an issue to fix with the live channel monitoring in RaceAnalyzer. Busy!
Tonight I should have a build that disables accelerometer smoothing for now; I also have an issue to fix with the live channel monitoring in RaceAnalyzer. Busy!
Hi, We released a new firmware version that fixes a couple of important bugs and also disables accelerometer averaging.
http://www.autosportlabs.org/viewtopic. ... 9238#19238
Let us know how it works!
http://www.autosportlabs.org/viewtopic. ... 9238#19238
Let us know how it works!