Data Logging in (gravel) Rally Stages

Hi Guys,

Great content once again! High-end distilled info, structured properly. Looking forward to the more advanced stuff, like damper pots ect.

In my 15 years or rallying, i am using cameras since day 1 and a logger for the last 10 years, after a crash, when it became obvious that even the most open minded and honest drivers, are no reliable source of data under pressure.

I have been working with Race Technology products, which back then were within budget and offered a nice integration of my GoPro cameras, but the strategies, techniques and approach is clearly applicable, regardless of the equipment.

Logging mostly on rally stages, offer some unique challenges, compared to what you describe in the course, which i would like to discuss with whoever is interested.

References: The reliability and relevance of reference data is somehow questionable, due to reasons like the ones below.

1) No 2 runs are the same: Stages, especially the gravel ones, tend to change over time, conditions, or even car passes through the same day.

2) No real reference lap is possible: Driving the stage in anger, especially with a rally car is not allowed, so you can only rely on historical data, if available. A car will usually change over the years, the crew is on a different mission/strategy each time, the conditions may vary alot each time you visit the stage, ect.

3) No laps, or start/finish line: Clearly the start line is different than the finish line and on top, those might move, even on the same event slightly, due to external conditions.

The above leaves us with a somehow "averaged" reference, which occasionally is useless for the differences involved. In rallying, you are usually looking at differences measured in tenths of a second/km, but it's very common to have 2 cars timed within 0,1, or even 0,0s, over a stage of several KMs.

Hardware/Usage: Telemetry is practically 100% banned and depending on the regulations, it can be that it's not allowed to install any additional sensors for logging purposes.

On top, it's sometimes not really practical at the club level, to complicate the car with additional advanced sensors, like suspension pots, or even steering angle sensors. You will rarely have the change of reviewing any data, besides basic reliability data, through the course of the day, so there will be no feedback to the driver possible, to improve on the second pass, and it not so common for 2 guys driving "same" cars, willing to share data. The video is your best chance, for basic points, like lines and braking points.

An additional interesting parameter is that banking or road elevations, changing grip levels, variable conditions, ect are on the daily menu, making conclusions very tricky, without the driver's input.

To make things even more tricky, changing the logger over to different cars is also on the table, asking for simplicity and "universal" settings.

To sum it up, i would love to exchange thoughts with anybody with more experience with A-to-B stage logging, like rallying, hillclimbs, or sprint events!

P.S: to whom it may concern, you can have a look on our endeavors here: https://www.youtube.com/user/ArmaRallyTeam

Hi Armaki, thank you for the feedback on the course. We put a lot of effort into these, so I'm glad you're finding it useful!

I took a look at some of your videos, I really like the multiple view setup of pedals, driver and driver's view you put together. I can see that these would be very helpful when used in this application.

I agree that for rally stages, the philosophy and approach is a bit different from what is used in circuit racing for all the reasons you list. From my experience with rally cars I know that having "creep" in the distance travelled can be quite a big problem. However, I would think that you might be able to make use of GPS data to give you "distance" into a stage these days in many cases? I think for example the VBOX system allows you to view the data against position on the X-axis in a time/distance plot, which I think is coming from GPS data although I would have to confirm this. Maybe you're already doing this!

I still believe there is a lot of room for data analysis in rally, but as you've said, unless you are comparing data from 2 identical (or at least very similar) cars then all of these external factors will make it difficult to make direct comparisons.

Even if you only have data from your car, and with the limitations you mention, I believe that tuning things like differential setups and settings, damper and spring settings are all possible. Particularly when they can be compared and validated against the driver feedback.

I'm also interested to hear from other rally and hillclimbers to hear their thoughts on this style of data analysis.

Hi Tim, thanks for the reply. Keep up the good work!

To be honest, especially on gravel, most of the work is done based on the videos. Looking on squiggly lines will only get you that far without the visual input to understand the situation. Synchronizing the videos, even though the cameras are hardwired with the logger is the most tricky and time consuming part. If you leave it in auto, you will not get the necessary resolution for analysis.

Speed and -mostly distance- is tricky, as you mention. Wheel spin and locking is daily business and you have to live with them and GPS is sometimes inaccurate, due to scenery and location, but is a good way to go.

I start the logger on the stage start, so you can tell the actual start from either the speed, or the rpm, or the videos, and i guess you can trigger an automatic start, based on location. In hi-end event, the organizer will share the start and finish coordinates, but it really comes down to the available hardware to do something useful with that info. Keep in mind that there is no guarantee that the lines will not be moved during the event, so you are only sure when you get there.

A point that i am quite interested in and haven't managed to make it work yet, is split timing. The theory behind is similar to a sector time, but at least my system doesn't really work on A-B tracks. if you have all maps loaded on the logger, it;s quite common for the device to mix them up, due to proximity.

There is definitely a lot of benefit in logging also in rallying, it just needs a bit of salt. Especially during development, or post processing and definitely for engine data. In Greece, were i am mostly competing, we see a lot of overheating on anything that can be overheated....

Regards,

Nondas

I can see how the video would be extremely useful, particularly as you can compare the real reference for your position in the stage based on what you see out the windscreen! I'm interested to hear you have problems synchronising the video and data, in all modern systems I've used this is very well managed and I haven't had any significant problems, although I am talking about systems where the camber and logger are from the same company and they are designed to work together. I'm not sure on your exact setup?

Once you have good syncronisation of the video and data, I guess you should be able to do some decent overlays but of course the accuracy will always be worse than for circuit style racing.

That's a fair point on the GPS signal quality, there must be many places where this is not perfect!

Certainly, the reliability aspect is where there is no doubt about the usefulness of the logger.

Following up on your question from your initial post: We will be releasing an Advanced Data Analysis course at end of March that will include a section on damping data analysis that you will find interesting I would think!

The tricky part in synchronizing the videos is that my 3 (in full setup) GoPros Hero2s with same Firmware and same SD cards, have a random time difference in their reaction time to the wired "rec" command from the Race Technology DL1 Club logger. I had the same issue when using the original GoPro remote connected to all 3 cameras and starting the logger separately. It's really random which camera will react first and how long will the others lag. The software offers some tricks to impove the situation, but this is limited to one camera and the "automatic" options are time (clock) stamp based, so not really down to the 0,0x seconds range, necessary for a smooth overlay.

I use Race Render from HP tuners (!) to overlay the 3 videos and the data together.

Race Technology solution is pretty decent and versatile, considering that you can integrate "standard" GoPros with the logger. They even offer a data analysis software solution for all GPS enabled GoPros, enabling basic Video/G-sensor/GPS logging using just the Gopro, obviously handicapped by the camera sensors accuracy. Back when i started with logging, nothing really could beat that. Nowadays the logger remains relevant, especially if you are looking for an analog based unit, but the software could use an upgrade in terms of simplicity and user friendliness.

Looking forward to the new courses!!

Interesting issue that you face there with the synchronisation. However, when you're joining together components from different manufacturers, sometimes we face these issues!

Most of the video analysis I've worked with has been from VBOX and MoTeC products and for these systems anyway the handling of the syncronisation has always been perfect and completely automatic. There are plenty of other manufacturers out there offering similar integrated solutions like AiM for example.

In saying that, it all costs money. And sometimes you just need to make use of the equipment you already own, so I understand!

I did not know about the Race Technology analysis for native GoPro data, even though there are limitations it's a very nice idea to make use of the capability of the camera.

The VBOX was the other option i had back then, but it felt more versatile with the external Camera and it paid off it terms of video settings variety, modularity and a camera to play with. Synchronization is much less of an issue in track sessions, where you get more laps per logging file, so the same effort takes you further in analysis. In addition, there is a high possibility to have a fixed offset with one camera, as opposed to 3. MoTeC was and remains out of reach.

The 59GBP Race technology is asking for the GoPro software is a really interesting option for basic, entry level, video orientated work, given that you already have a GPS enabled GoPro. Plus it offers a decent track orientated software.

If i was buying today, i would re-evaluate a lot of details, but since the car is a 90s Nissan, with no fancy electronics, there is not much point in going fully Hi-tech.

For the synchronization, a simple trick that might help you is clapping your hands shortly after starting all cameras - if the software you use shows noise level, you'd be able to easily identify this and sync accordingly.

In my case, the car will be equipped with a AiM PDM32 kit with their 10inch dash, but I decided against using their smartycam solution for now because of the cost - will instead use one or multiple gopros, just like you're doing.

Data logging for rallying is a topic of interest for myself as well, but I'm still in the last phase of significant upgrades to the car. To me, it seems like these might be the most beneficial things for gravel events (in addition to video, of course):

1. Damper position sensor - to see whether we're using the full range of the dampers (without bottoming out anywhere, especially after jumps, on the second pass or if you're placed way down in the start list). If not allowed in the event, this would be very useful during testing to see what would work for the specific surfaces you're expecting to face

2. Throttle position (we have very fast roads here, so any problem with DBW throttle resulting in the throttle not fully opening would cost a lot of time)

3. Wheel speed sensors to check how often the wheels lock up under braking

In my case it is an RWD car, so I'll try and fit sensors on the front axis (as handbrake use and 400+hp on gravel will make the rear wheel speed data pretty useless for this), which should let me know if the enough braking pressure is applied. My logic here is simple - if the wheels never lock up under braking, it is almost guaranteed brakes are not being used to their full potential. When on the limit, occasional small lockups are expected

Really enjoyed the fundamentals course and already cannot wait for the advanced course in March!

I have played with such synchronization tricks in the past and in theory it should work, especially with hi-end Video software like Adobe premiere ect offering auto-synchro over sound, but there are some issues.

a) the HP tuners software that i am using, offers no sound wave option, but it allows for overlaying all views + the .csv data file in one go

b) even if the videos are synchronized by sound, you still need to synchronize the data, which obviously tell a lot, but without sound ;)

c) clapping your hands in a rally car on a stage start line, with all systems running, will not really give such a clear wave. Revving the engine though would, with the benefit of the showing also in the data.

In the same principle, I though about adding LEDs in the views of all cameras, triggered simultaneously, but i never went on with this, due to the extra (useless) parts.

What i usually do, is roughly synchronize the main view with the starting point of the data (first frame that the car moves with the first speed signal), then fine tune the engine revving sound on the video, with the rpm sweeps on the starting line. From then on, I use a similar technique to synchronize the rest of the views. If you check the link with my videos above, the result is acceptable. The effort consuming thing here is that there is no pattern in which camera lags and for how long, so every stage needs to be done manually.

An additional issue is that the data drift slightly to the video, so in big stages, you end up with an annoying offset towards the end. Luckily this is linear, so a play speed factor of 0.999xx fixes it within reason.

I would really consider the AIM 32 PDM, if I was building a car from scratch, especially because of AIM's logging history and the many PDM outputs, put i haven't looked into it in much detail. Their camera is definitely expensive though and a problem i have come across in the past with similar cameras, was that you could not change the exposure, which is absolutely vital in a rally car, especially with shaded windows on a sunny day, if you want to show anything more than the windshield.

Regarding the sensors you mentioned, i wouldn't run a damper pot during the actual event, especially on gravel, due to the complexity and reliability issues that might occur. It's an expensive think to brake. Instead, you can simply put a tie-wrap around your suspension's rod, so that the suspension can slide it as it travels. The tie-wrap will end up being on the point of maximum compression.

TPS is definitely a must. No reason not too. Especially if drivers are complaining for the car being down no power, but not pushing it all the way, or claiming that they went flat through a place, or saying that they were not pushing, ect.

Wheel speed sensor is also very useful for distance and speed measurement obviously, excessive or constant wheel locking and i guess also LSD health checks. After a while, you can build a knowledge database of how much wheel spin a healthy LSD allows.

I manually sync video data using gear shifts -- usually as the car leaves the pit lane. Easy to see in the video (maybe even an overlay), and visible in the data.

That's actually a good idea. I am also doing this from time to time, at least to roughly bring it in the ball park.

Especially on tarmac, with proper speed inputs, or ideally gear position input, it works quite well and then you can fine tune it with the G-sensor readings or the gas pedal view and signal.

On gravel it still remains tricky in my case, since I only have GPS speed reading and the Gear channel is calculated with RPM and this GPS speed input, but it still usable.

Changing from 2nd to 3rd works better, to avoid wheel spin as much as possible, especially when the gear input is calculated.

Race Render offers an automatic feature to do exactly that.