RaceRender 2
-
- Posts: 13
- Joined: Sat Apr 13, 2013 9:14 pm
RaceRender 2
Anyone here using Racerender 2 ( www.racerender.com ) with RCP? I saw the Youtube footage Brent posted. Pretty cool stuff.
Looking for screen shots of the "input File" configuration.
Any mod to the CSV file need to be done?
Looking for screen shots of the "input File" configuration.
Any mod to the CSV file need to be done?
Kyle Murphy
Bonney Lake, Wa
Track Car: Porsche 911sc
Bonney Lake, Wa
Track Car: Porsche 911sc
-
- Posts: 101
- Joined: Tue Jan 15, 2013 1:37 pm
I'm currently attempting to work with it. I've been happy with how easy the import was (infinitely better than DashWare) but have been stymied trying to get the output file to not have glitches. It simply won't play back smoothly. There are jumps, backwards jumps, freeze frames, and black screens. No idea why.
I added a "time" column where I put a running time in seconds. The program seemed to like this a lot.
I added a "time" column where I put a running time in seconds. The program seemed to like this a lot.
-
- Posts: 101
- Joined: Tue Jan 15, 2013 1:37 pm
If anyone finds an answer, the problem I'm having with RaceRender can be seen here: https://docs.google.com/file/d/0B9Dlhiz ... sp=sharing
It must be possible as the COTA video was great.
It must be possible as the COTA video was great.
-
- Posts: 101
- Joined: Tue Jan 15, 2013 1:37 pm
This 99% fixed the problem (sound still has "knocking" in it):http://forum.racerender.com/viewtopic.php?f=6&t=111
You can check out my input file here: https://docs.google.com/file/d/0B9Dlhiz ... sp=sharing
I've added a few columns, but the "alt time" is what it uses to sync the video, which is basically the only difference.
You can check out my input file here: https://docs.google.com/file/d/0B9Dlhiz ... sp=sharing
I've added a few columns, but the "alt time" is what it uses to sync the video, which is basically the only difference.
RCP saves the data as a log file. When I convert it to a csv file and add it to the video in RR2 the data only has a length of 1 second.
What am I doing wrong? I assume something in the log to csv conversion. I am using open office.
*edit*
I got it to save and have what appears to be the correct length for the run (autox) but the overlay of speedo and g-force don't move during playback.
https://docs.google.com/spreadsheet/ccc ... sp=sharing
Also, should there be data in every cell for every value?
What am I doing wrong? I assume something in the log to csv conversion. I am using open office.
*edit*
I got it to save and have what appears to be the correct length for the run (autox) but the overlay of speedo and g-force don't move during playback.
https://docs.google.com/spreadsheet/ccc ... sp=sharing
Also, should there be data in every cell for every value?
-
- Posts: 101
- Joined: Tue Jan 15, 2013 1:37 pm
I have mostly figured RR2 out and will post a video later (processing now!).
You need to have a time channel. There does not need to be data in each cell, but having a "time" value for each data point is required. The time channel needs to start at 0 and index upwards in seconds (the RCP time stamp is in hhmmss.ss).
You'll need to enter a formula to calculate the time which will look like this:
A4=M4-M3+IF(M4-M3>40,IF(M4-M3>4040,-4040,-40),0)+A3
Where the time channel is column M and A is the new time channel.
When you create your GG plot you may need to "flip" the X and Y inputs. The recommended installation of RCP results in data being recorded in reverse polarity (braking is -, acceleration is +). Traditional GG plots are the opposite of this, with braking going up (positive) and acceleration showing negative.
You need to have a time channel. There does not need to be data in each cell, but having a "time" value for each data point is required. The time channel needs to start at 0 and index upwards in seconds (the RCP time stamp is in hhmmss.ss).
You'll need to enter a formula to calculate the time which will look like this:
A4=M4-M3+IF(M4-M3>40,IF(M4-M3>4040,-4040,-40),0)+A3
Where the time channel is column M and A is the new time channel.
When you create your GG plot you may need to "flip" the X and Y inputs. The recommended installation of RCP results in data being recorded in reverse polarity (braking is -, acceleration is +). Traditional GG plots are the opposite of this, with braking going up (positive) and acceleration showing negative.
Last edited by dimondjack on Wed Jul 17, 2013 5:22 pm, edited 1 time in total.
-
- Posts: 101
- Joined: Tue Jan 15, 2013 1:37 pm
I've just posted my video. Overall I think it looks pretty good! http://www.youtube.com/watch?v=ucKBxjI1 ... e=youtu.be Make sure you load it in at least 480P (or 720) as it looks crappy at the 360 it loads at.
I used a buttworth filter (see the filtering post in "http://www.autosportlabs.org/viewtopic.php?t=3836") on the accelerometers as well as using rubber vibration isolators (still need to update my post with a picture of the setup).
When I have a bit more time (I've got vacation next week) I'll do a writeup on how to use racerender. It is pretty straightforward but you have to modify the data file slightly to make it happy.
I used a buttworth filter (see the filtering post in "http://www.autosportlabs.org/viewtopic.php?t=3836") on the accelerometers as well as using rubber vibration isolators (still need to update my post with a picture of the setup).
When I have a bit more time (I've got vacation next week) I'll do a writeup on how to use racerender. It is pretty straightforward but you have to modify the data file slightly to make it happy.
Nice! Vibration much?
Is that a GoPro? We have it on our list to have a backback PC board that can trigger start/stop via a digital output on RaceCapture/Pro.
Also shared here: https://www.facebook.com/permalink.php? ... 4953614230
Is that a GoPro? We have it on our list to have a backback PC board that can trigger start/stop via a digital output on RaceCapture/Pro.
Also shared here: https://www.facebook.com/permalink.php? ... 4953614230
-
- Posts: 101
- Joined: Tue Jan 15, 2013 1:37 pm
Yeah, there aren't many good locations to mount the camera so I have to say that it isn't the best mounting location. I'm looking in to getting a sturdier mount for it that could eliminate some of the large magnitude vibration.
It is GoPro. I think a backpack to trigger start/stop would be awesome. It would be even better to have it somehow add a "squawk" ever few seconds (which you could remove later) based on the data so that the position always lined up. I might try and work with RaceRender to get it so that the program could easily and quickly deal with the RCP data output.
It is GoPro. I think a backpack to trigger start/stop would be awesome. It would be even better to have it somehow add a "squawk" ever few seconds (which you could remove later) based on the data so that the position always lined up. I might try and work with RaceRender to get it so that the program could easily and quickly deal with the RCP data output.
-
- Posts: 13
- Joined: Sat Apr 13, 2013 9:14 pm
Brent- I think it would be a great idea to match at least one current common convention out there. As the software begins to mature you could possibly have a feature that allows you to export in other common formats. For now, picking a current popular format that would easily export into something already out there would be a huge jump in the right direction... e.g. export to RaceRender2 format.brentp wrote:Thanks for documenting this.
We based the accelerometer polarities based on the device's datasheet. We certainly have an opportunity to change the defaults to match common conventions- would cause a bit of churn - short term pain
Thoughts?
Being proprietary is usually the least popular, unless you're Apple. I love Apple though...
-Kyle
Kyle Murphy
Bonney Lake, Wa
Track Car: Porsche 911sc
Bonney Lake, Wa
Track Car: Porsche 911sc
Sure, no problem with that.
So I propose:
Y Axis (Braking / Accelerating) : +G is braking and -G is acceleration
X Axis (Left / right) : -G is left and +G is right
Z Axis (up down): -G is up / lift , +G is down / compression
Yaw: Right rotation: +degrees/sec , Left rotation: - degrees / sec
Comments ?
So I propose:
Y Axis (Braking / Accelerating) : +G is braking and -G is acceleration
X Axis (Left / right) : -G is left and +G is right
Z Axis (up down): -G is up / lift , +G is down / compression
Yaw: Right rotation: +degrees/sec , Left rotation: - degrees / sec
Comments ?
While we're on topic of RR2, I'm trying to get my data lined up with the video. I can get it in sync for one point but then it starts to skew on subsequent laps which means that either the data isn't timestamped right or my math to convert the timestamp is wrong.
Regardless, I think it'd be really helpful if RC logged the relative elapsed time of a logging session in seconds since this is what RR expects (and probably other things out there). The timestamp from GPS helps for a number of other things and I think it should still be in there (though epoch time makes wayyyyyyy more sense than that HHMMSS.ss format that's going on now).
Regardless, I think it'd be really helpful if RC logged the relative elapsed time of a logging session in seconds since this is what RR expects (and probably other things out there). The timestamp from GPS helps for a number of other things and I think it should still be in there (though epoch time makes wayyyyyyy more sense than that HHMMSS.ss format that's going on now).
While we're on topic of RR2, I'm trying to get my data lined up with the video. I can get it in sync for one point but then it starts to skew on subsequent laps which means that either the data isn't timestamped right or my math to convert the timestamp is wrong.
Regardless, I think it'd be really helpful if RC logged the relative elapsed time of a logging session in seconds since this is what RR expects (and probably other things out there). The timestamp from GPS helps for a number of other things and I think it should still be in there (though epoch time makes wayyyyyyy more sense than that HHMMSS.ss format that's going on now).
Regardless, I think it'd be really helpful if RC logged the relative elapsed time of a logging session in seconds since this is what RR expects (and probably other things out there). The timestamp from GPS helps for a number of other things and I think it should still be in there (though epoch time makes wayyyyyyy more sense than that HHMMSS.ss format that's going on now).