Brembo Hackathon, lessons learned

One month ago now I had the honour of participating in the BREMBO HACKATHON.

Those weeks passed allowed the time for some reflections.

Participation came as a surprise to myself: at 55 years old I was not really in the usual age range for this kind of challenge.

A hackathon consists basically in one secluding himself with other participants and working at a project round the clock for three days. Not really much time for sleep.

Now, of course, we kids from the 60s are still perfectly able to enjoy savage weekends and party with the best of them.

Problem is one recovers next Tuesday.

So I had to ask myself what I could actually contribute.

One of the challenges was centered on the advanced Sensify braking system  by Brembo.

My background in Automotive matters came handy here and I could see a way to use some Data Science techniques in this sector. Being used to lead research teams I hoped I could coordinate a good effort.

I was lucky enough to cooperate from even before the start with Gauri Shankar Prasad, Automotive Engineer, and Asmâa El Ouerkhaou and Alexander De Pauw, Data Scientists who helped check the computational feasibility.

We thus went to enjoy Brembo hospitality at Kilometro Rosso.

At the end of a spectacular stairway lied the work room, where our Team was soon enriched by  Antoine Lamps, Automotive Engineer who has a working knowledge of ABS systems, and Aya Mokni,  Marketing specialist.

Brembo allowed us  talks with their tech people, which was necessary in order to avoid reinventing the wheel, quite literally. To our relief they seemed to like our idea, and we had further encouragement from the experienced people at Teoresi Group, there as a sponsor .

The most important contribution we derived from specialists was what NOT to do. An apparently interesting side application of our idea they explained could be a safety hazard. So we stuck to the main path.

We needed a tyre model in order to test our theory. While several of these exist, Pacejka's being a personal favourite, they need experimental data to be calibrated. In the absence of these their behaviour becomes quite unpredictable.

So I set up creating an ad hoc tyre model that allowed  for stability and whose parameters represented physical quantities, useful to validate the concept.

At very late night we just crashed on the (design) couches near our working station. Wish I had more time to use the fantastic driving simulator Brembo provided. Sigh.

Early morning, work on the code model. Out of respect to Brembo I do not feel at liberty to go into details, but it was the application of some techniques to improve the use of datasets. We would have liked to use GAN, but time constraints in terms of computational time advised a more down to earth approach.

Alex wrote the code, while  Gauri and Antoine devised the hardware that will be necessary to bring the idea into real world and Aya expertly tackled the marketing side.

Sunday morning, last calculations, prepare the show.

I had just the time to run a fast significance test on the several runs Alex provided. Just to check that the good results we were seeing were not likely to come from sheer good luck with the randomization engine. In a less fast paced setting I would probably have checked normality, maybe gone non parametric and such, but at the speed we were going I was just glad to check it was a Gaussian with old trusty Eye Mk1 tool and put in a T test.  

Working at the presentation proved though: choosing the arguments to cite in the minutes allotted, the general tone … and then before we realized there was Gauri giving an excellent show.

While participation in such an excellent evinronment would have been prize enough, we scored second place.

It was beautiful, thanks again Brembo.

Lessons learned:

1)     It is perfectly possible to participate in an Hackathon as a senior Engineer, provided one is able to nurse stamina. Have an hotel at least one night, your bones will thank you.

2)     People working in the sector full time might already have had one’s “innovative” idea. Be humble and check.

3)     Years spent in different positions allow to see different angles and easily link fields. Holistic view is probably the best asset a senior can contribute to a team.

4)     Possibly separate team direction and direct participation in  details. Code  only when specialist knowledge is required. Managing remote participants takes 3 times the effort compared to managing members on site

5)     Try not to have too broad a scope: better a detailed solution that skips on say, cost evaluation than trying to tackle everything, even if this is what is apparently requested from the tender.

6)     It is a a competition, in other words it is fun. It can and probably in the case of a senior it SHOULD be made for fun. So, just relax and enjoy. As you would a skydive 😊