How Delft University's Engineering Students Make Their EV Formula-Style Race Car Faster with Marple and InfluxDB

Session date: Feb 14, 2023 08:00am (Pacific Time)

Delft University is the oldest and largest technical university in the Netherlands with 25,000+ students. Since 1999, they have had a team of students (undergraduate and graduate) designing, building, and racing cars, as part of the Formula Student worldwide competition. The competition has grown to include teams from 1K+ universities in 20+ countries. Students are responsible for all aspects of car manufacturing (research, construction, testing, developing, marketing, management, and fundraising). Delft University’s team includes 90 students across disciplines.

Discover how Delft University’s team uses Marple and InfluxDB to collect telemetry and sensor metrics while they develop, test, and race their electric cars. They collect sensor data about their EV’s control systems using a time series platform. During races, they are collecting IoT data about their batteries, accelerometer, gyroscope, tires, etc. The engineers are able to share important car stats during races which help the drivers tweak their driving decisions — all with the goal of winning. After races, the entire team are able to analyze data in Marple to understand what to do better next time. By using Marple + InfluxDB, their team are able to collect, share and analyze high frequency car data used to make their car faster at competitions.

Join this webinar as Robbin Baauw and Nero Vanbiervliet dive into:

• Marple’s approach to empowering engineers to organize, analyze, and visualize their data
• Delft University’s collaborative methodology to building and racing their Formula-style race car
• How InfluxDB is crucial to their collaborative engineering and racing process

Click here for presentation

Watch the Webinar

Watch the webinar “How Delft University’s Engineering Students Make Their EV Formula-Style Race Car Faster with Marple and InfluxDB” by filling out the form and clicking on the Watch Webinar button on the right. This will open the recording.

[et_pb_toggle _builder_version=”3.17.6” title=”Transcript” title_font_size=”26” border_width_all=”0px” border_width_bottom=”1px” module_class=”transcript-toggle” closed_toggle_background_color=”rgba(255,255,255,0)”]

Here is an unedited transcript of the webinar “How Delft University’s Engineering Students Make Their EV Formula-Style Race Car Faster with Marple and InfluxDB”. This is provided for those who prefer to read than watch the webinar. Please note that the transcript is raw. We apologize for any transcribing errors.

Speakers:

• Caitlin Croft: Sr. Manager, Customer and Community Marketing, InfluxData
• Nero Vanbiervliet: Co-Founder and CTO, Marple
• Robbin Baauw: Software Engineer at Formula Student Team Delft & MSc Computer Science

Caitlin Croft: 00:00:00.110 Hello everyone. And welcome to today’s webinar. My name is Caitlin, and I’m very excited to be joined by Nero and Robin, who are here to talk about how Delft University’s engineering students have made an electric vehicle formula-style racing car, even faster with Marple and InfluxDB. This session is being recorded and will be made available by tomorrow morning. Please post any questions you may have in the Q&A, which you can find at the bottom of your Zoom screen. And without further ado, I’m going to hand things off to Nero.

Nero Vanbiervliet: 00:00:39.980 Thank you very much, Caitlin. So welcome everyone to the webinar. We’ll take things off with a small direction about what Marple is and also to give you a little bit of a background about what we’re going to talk about today because of going to talk about InfluxDB, obviously. We’re going to talk about Marple. We’re going to talk about time series data. But I also want to stress that we’re going to talk about a specific use case for time series data. And this is in the field of engineering. So I’ll first try to separate that a bit. And then we can dive deeper into what Marple is. I think Robin will end the webinar by giving you a more in-depth example of using Marple and also using InfluxDB for building an electric race car and debugging, making it performing as best as possible on the racetrack.

Nero Vanbiervliet: 00:01:28.359 So let’s get started. First of all, who am I? My name is Nero. I’m from Belgium. I’m an engineer originally, mainly an electrical engineer. But I moved away from that and moved to software development. And currently, I’m cofounder but also CTO of Marple. And Marple is a data startup based in Belgium in Antwerp. And we do all kinds of stuff related to time series data, but we always focus on engineers and engineering. That’s our main focus. If you have any question regarding these slides or anything about Marple, feel free to reach out to me. My email is right there on the slides. All right. So first, the general problem statement. So what are we talking about today? We’re talking about engineering. And when I use the word engineer today, I don’t mean it as software engineer. I mean it more specifically as an engineer working on physical systems. And you can see some of these on the slides. In the center, you can see an engine. On the left button, you can see a solar-powered car. There’s also a competition about this around the world of students competing in the race competition. And they also have to build the car, solar-powered. There’s batteries on board. And also, the Belgian teams are quite famous and have done quite well in the past years.

Nero Vanbiervliet: 00:02:54.581 Top rights is also a good example. Again, the physical system, something moving. And this is the Lilium Jets. It’s an electric aircraft meant to move people from A to B but more short distances. So you can kind of compare it to a helicopter. But it’s electric, and it also can take off vertically and also fly just hovering like this for the main duration of the flight. At the top right, you have Atlas Copco. They make compressors, for example, air compressors. They have multiple use cases. But in general, these are all examples of very complex systems, and they are physical. They have a lot of moving parts. But in the end, it’s all about time series data when engineering these systems. And so how does this go — currently, what’s the current workflow? So these engineers, they use time series data, but they have a specific needs in their handling of time series data.

Nero Vanbiervliet: 00:03:58.418 And I think three main points are very important to stress. First of all, they need extreme interactivity. They don’t just need a plot once investigated and move on. Usually, they need to do a lot of interactive stuff. For example, if the engine breakdown, you need to investigate, “Okay, what happens?” And to investigate this, they don’t just see one plot or one graph. They need to add different signals. What’s something going on with the fuel inlets or something going on with the temperature being too high? So they need to interactively do those operations on the data. This is also the same for calculations. We need to do calculations to see, “Okay, what’s going on? Could it be this or that, etc.?” The second thing is they need specific plotting and also specific calculations for the engineering use case. And I think one clear example for this is a frequency plot. And possibly some people in the audience have heard about it if they’re also more mechanical engineering backgrounds. A frequency plot is used a lot to, for example, determine the most apparent, most visible frequencies in a vibration, for example, to see if they are not vibrating too much on these specific frequencies. And so frequency plots, usually, it’s done by doing scripting, for example, or using specific tools for this. But it would be really nice to do this also on your InfluxDB data. That would be it.

Nero Vanbiervliet: 00:05:31.000 The last part, what engineers really need is the notion of the datasets. And I’ll talk about this a little bit more later. But in contrast to a lot of time series data, which is just flowing all the time, let’s just take, for example, a cookie factory. They would just make cookies all day, all night, 24/7, and the data will just be measured 24/7, temperatures, number of cookies coming out, all this kind of stuff. And they could put it in InfluxDB, but it would be continuous streaming all the time, day and night. And this, I think, is specific for this kind of use case of making cookies, process data, chemical things. But I want to put this in contrast to the engineers. They rather need the concept of a dataset, which is not continuous measurements but rather a specific test or a measurement done stand-alone. For example, they might do a run with the solar car and just test it. How does it work? And they might do a number of them in the afternoon. And so in between, there’s no data. In between, it’s just empty. The car is off. So they need some kind of notion of a dataset. They want to say, “Okay, this was this test. This was this measurement.” And that’s the bit where Marple start also. Marple really expands on to InfluxDB for these specific needs, for these specific use case. And so in the rest of the slides, I’ll try to show you guys a bit about how Marple achieves this, how Marple makes InfluxDB even better for this kind of use case.

Nero Vanbiervliet: 00:07:01.408 So the first, what is the background? We have these all kind of fancy physical things being developed. And these engineers, they generate a lot of data. And usually, the whole industry just is shaped around files. They will just make the measurements data. They will log it using a physical logger. And the physical logger will put in often in a CSV file. I think that’s the most commonly known mods files there, performance designed by MATLAB. It’s also a very common tool used to engineering. And there’s some other formats too, some proprietary, some more open-source. But in the end, it comes down to the fact that they have a separate file permissions. And we also have Marple support. These engineers, they will automatically upload via API the data to Marple. And you’ll end up with a nice visualization. But we think that this workflow is okay. But we should also look ahead. And we see that, currently, time series databases and also InfluxDB are getting all of the traction. And that’s a good thing because the data is in one central place and one central shape, like in the same shape. And so we thought, “Okay, it would be really, really great to have customers who are already using InfluxDB to support them but also support new people who use InfluxDB.” And so we decided to make integration with InfluxDB version [inaudible]. And this way, people using InfluxDB can just skip the whole data files part. And it can just put a little right into Marple from InfluxDB and use all the nice and shiny things that we offer. So that’s kind of the alternative for pitching right now. And we think, also, the whole industry that would benefit from moving away from data files more closely to leveraging time series databases.

Nero Vanbiervliet: 00:08:53.007 Okay, the question is now, “How do we achieve this in Marple? How do we make the whole workflow even better?” And I think we’ve spent on three main domains to expand your InfluxDB toolkit to make a difference. And there’s a much more to learn, but I would say we offer a free tier of our cloud version. So you can just go ahead and try it out yourself. Or documentation also tells you a lot more about what we offer. But I’ll just today highlight three main areas in which we improve the workflow for engineers. The first one is new plot types. So you use these specific tools for the analysis. And what I mentioned before was the frequency analysis. And for this, for example, we provided separate plot. You can see that the right-hand side, it’s a frequency plot. And actually, we’ll use the fast free transform algorithm in the back to transform the time series data into a frequency domain signal and then plug it onto the plot for you. In the middle, you can see a scatter plot. We’ve also color signals on top of it, using the coloring of the heat map. And on the left-hand side, you can see the map blocks. We’ve also seen coloring for the speed.

Nero Vanbiervliet: 00:10:04.833 And these kind of things are cool and good for engineers. But what is the most powerful part of Marple is that all these things work interactively. And I made a small video to demo this. Let’s see if I can get it to work. There we go. So we can see now. It’s the same blocks at the bottom. But I’m just using it interactively. At the top hand side, I’m zooming and moving in the time region. And all things will update accordingly. For example, now we move to different tab, and we move back. And actually, all the views will update instantly. Also, here we drag in a new signal. We just get the signal right away. And this is what I mean with interactivity. Things just respond to whatever action you do. As an engineer, you really need this to do an investigation to see what’s going on in the data. So these are the first improvement we made. It’s a different problem. Secondly, we add functions to your InfluxDB workflow. I know you can already do calculations in InfluxDB in Flux language. But when we add to it specifically, it’s a more intuitive interface to do using your functions. That’s the first thing. You have the visual interface. But also, we make sure you can save these calculations and resume later just by new parts of InfluxDB time range. You can just have the same calculations and apply them automatically out there. And this way, you can make, for example, models of inner workings of your system or just at the Marple to see how the model behaves next to the real measurement.

Nero Vanbiervliet: 00:11:54.643 So also a small demo video about this. And in this case, the interesting thing is that we are adding a moving average filter. We have a noisy signal. You can see that I just tweak the window in the UI. I will just change the amount of samples we take for averaging the signal. And the nice thing about this is we will get immediate feedback on this. We will see how is the result changing, how is the moving average changing over time if we edit the parameter. In this way, it’s a very fast workflow. You can check, “Is this the right filter that I want to apply?” And if you’re ready, you can just save it. So let’s see a small demo video about that. So we have an acceleration signal. It’s moving up and down. We might want to filter it. And if we just move the window, parameter, we will see that it will smooth and smooth even more signal until we are happy about it. And then we can just save it for further use. There’s also other functions like a clamp filter. It will clamp your signal to a certain maximum, minimum, for example.

Nero Vanbiervliet: 00:13:07.504 Third parts that I want to talk about today is metadata. And it’s really tied to the concept of datasets that I talked to you guys about before. So on top, you have the familiar view of the visualization in the InfluxDB UI. What you can see there is just data from one bucket. In this case, it contains the speeds of a car. And let’s just imagine it’s a solar car. You just see the speed. And as I mentioned before, this is not a continuous measurement. It’s not like they are measuring the speed of the car day and night. They are doing separate runs of the car. So in the first case, the first real bump, it’s a run with the current circuits. Then they run again on the circuit. And then they did the third lap of the circuits after somewhere waiting time again. But I think it’s finished earlier, so I think we did not finish the run in that case. And instead of treating distance like one continuous large tree of data, it would be nicer and it makes sense for an engineering in this case to treat this as separate datasets.

Nero Vanbiervliet: 00:14:16.799 And this is where Marple comes in. Marple gives you the opportunity to take a time slice and save it as what we call a selection. And the selection, you can give it a name, but you can also assign it metadata. For example, you can call, “This is test number three. This is system number 65. This is system number 1,000 and so on.” You can decide that someone, maybe an owner who owns a test and needs to look at data later, you can decide the status. You can also add some reporting, maybe some document he made. Or it might be a picture of the actual setup. That’s just allows you to play around a bit more with your data and add some more things to tell about what’s going on at a particular point about your data. And they end up — this is a bit going back to the concept of files. It was there for a reason. And with datasets and selections in Marple, we kind of bring back the concept of the datasets but also hybrid combined with different InfluxDB. Really, practically, how they work in Marple, you can create a selection. And I think Robin would also show it later on. It’s a familiar interface in which you can select some tags, select the measurements, buckets, etc., and the time slides. And then Marple will show you already preview if there’s some data that are not because, often, people will just select some random things and they will not know exactly if there is a data in there or not. And it’s very useful to get quick feedback about, “Is the data here in this time slide or not?” And then you can give it a name and save it for later use.

Nero Vanbiervliet: 00:15:48.272 So these are the main three things. But there’s a lot more to discover. So please go ahead. To finish up, first of all, I have a few tips and tricks for engineers using InfluxDB. I think, first of all, it’s important if you’re using an API for integrating InfluxDB for other apps such as Marple, you should use scope tokens for security. So you can create the API token that is specifically scoped to specific buckets or specific sets of set of buckets. You can also choose between read and write access. And I think you should really conceptually think about this and limits the amount of data that the consuming app you can see just so you can also have a little bit of grasp on it. But also, at a later point, if you think this app isn’t useful anymore, you can just delete the one token that was specifically made for this app. And you will not be blocking the other apps that you’re also using because they will be using different tokens. So just use scope tokens and also make different ones for each other.

Nero Vanbiervliet: 00:16:56.794 The second tip that I have is add structure to your InfluxDB database. I think the main two large things you should use: buckets and text. And yeah, you should just make a clear structure back to your company. You should write down, “How are we using these? When do we make a new bucket? When do we use tags? Which tags do we want there to be always? Which ones are not needed?” Because this way, makes it a lot easier for tools such as Marple to later on extract the necessary data from InfluxDB. Otherwise, you have to do a lot of manual work to check which data is necessary or which one is not necessary to extract. And last, it might be the obvious one. But InfluxDB is a super good solution for storing your data and also for getting [inaudible]. But for deep engineering analysis, try Marple and use it as much as possible. All right. So my final thing is just, again, emphasizing you can try it yourself. Marple has a free tier. You can just go to app.marpledata.com. It’s on top there in the slides. The only thing you really need to do is create an API token and make it scoped and make a specific one for Marple and then paste the token and your credentials in Marple. And then you’re good to go. We also have some documentation about how to use InfluxDB together with Marple and also some videos explaining a bit more if you want to hear me talk a bit more about how to use Marple. That’s it. Thank you for paying attention. And I think I’ll have things over to Robin who will now talk to you guys a bit more about specific use case of using InfluxDB and Marple.

Robbin Baauw: 00:18:49.319 Yeah. Thank you, Nero. I will also share my screen and get started with, well, my part of the presentation. And I will be discussing how we handle our telemetry at Formula Student Team Delft. So first, who am I? Well, I’ve been part of the Formula Student Team in the past two years. I’m currently an alumnus there. And I’m also a master student in computer science at TU Delft. So what is Formula Student Team Delft? Well, it’s the biggest student team of the Netherlands, and we have been building race cars for more than 20 years. And we are a consist of an average 90 university students from all different backgrounds. And the team serves mostly as an amazing learning opportunity to work together in a project and also to start your engineering career. You can see that a lot of people that were in the team joined Formula 1 teams in the future as well. So our team consists of about 50% part-time and the rest internship, minor, or full-time. So that’s a lot of hours that are spent on the team every week by a lot of different people. And these people come from different studies. You can see that mechanical engineering and aerospace are very popular. These students really like to design the wings on the cars or the structural components, etc. And well, we work towards the competitions. These competitions are at the end of the year in the summer. And in those competitions, you can earn 1,000 points.

Robbin Baauw: 00:20:41.993 These 1,000 points are subdivided between static and dynamic events. In static events, you present your car to a panel of judges. These judges can be technical judges in which you will describe your car, you explain it in depth, and they can ask questions there. Manufacturing is an event as part of this, which is where you explain how you set up your pipeline. How did you build the car? How do you manage your costs? And there’s a business plan presentation where you present business case for your car. The car also drives in the dynamic events, and dynamic events include the acceleration event, where you drive 75 meters as fast as possible. A [inaudible] event, which tests your cornering abilities, the autocross event in which you drive one lap on the track as fast as possible, and the endurance event in which you try to drive 22 kilometers as fast as possible. This test mostly test your reliability. And the competitions that we visit mostly are these three that you can see on screen with the biggest being Formula Student Germany. And this is the largest engineering competition in the world where a lot of teams try to participate. In the end, only 96 actually can. And it’s a huge event. Takes entire week at the Hockenheim Ring. And for a lot of teams, this is their end goal, trying to win FSG. And with the Formula Student Team Delft, we’ve won FSG many times already. So let’s hope they can manage to do it this year again.

Robbin Baauw: 00:22:27.912 In general, a year is subdivided into three phases. First, our design phase, where we start with an empty slate. And we try to design the most optimal race car basically from scratch. Of course, you have the knowledge of previous years. But every year, there are changes to the rules, new ideas. And so every year, you design your entire car from nothing. And in about January, you go into your production phase, where you build the parts. Most of the parts are actually built in-house. So that’s, yeah, the lathe on the mail that we have in the workshop. And there are some parts that we outsource because we are not able to produce them in-house. And then, once everything has been produced, we go to the testing phase in which we go to the test track and try to push the car to the limits, break it, fix it, etc., to, in the end, be able to run the car properly at the competitions. So this results in the car that you’ve been seeing on the slides for quite a while now. This is the DUT 22. This is the car that we built last year. And you can see it’s very light, like 170 kilograms, and it has a lot of power. So that’s, yeah, really nice. And here, you can see the car driving in an endurance event. And you can see how narrow the track actually is. And that’s part of the rules, very narrow tracks. But this also causes the cars to be incredibly agile. You can see here. It goes through the corners, basically faster than any other car would be able to do. And yeah, this, you have to do for 22 kilometers, these narrow tracks. Yeah. It’s always fun to see.

Robbin Baauw: 00:24:20.528 So let’s actually dive into the telemetry stack. Since the DUT 21, which is the car from two years ago, we started developing our new telemetry stack. But I first want to highlight how we used to do it. And I’m going to imagine many other companies or teams also still do it this way. So what we did previously is we had all the data that are generated by the control systems or other means. And we store them on the SD card. We then take the SD card out of the car, insert it into a laptop, and then analyze it using Motech. And this is quite an inefficient process. It’s very hard to analyze data with a group of people, and it takes time to take your SD card out. It would be a lot better if all the data was there instantly. That’s why we developed our new telemetry stack that is present in DUT 21 and the DUT 22 cars. And with this stack, we live-stream our data to the cloud. So we can have instant access to our data. And in total, we are recording more than 55,000 data points per second, and this can be anything from the sensors or control systems, temperature measurements, etc. And with all these data points, this allows you to analyze the car in a way that previously wasn’t possible. Now, how do we get our data from the car into the cloud? Well, that’s where the entire stack comes in. And the first design choice that was made there is to use a Raspberry Pi compute module, which is a very small PCB that we can click into our vehicle control unit, our main computation unit in the car. And then our control systems can directly transmit their data to this compute module over SPI. So this control system is a model of simulating model, generates a lot of intermediate calculations that are very convenient to have access to as a controls engineer. And that’s what is transmitted over SPI.

Robbin Baauw: 00:26:27.224 We can also transmit our CAN bus data that is in the car. And CAN is an automotive communication bus. And the Raspberry Pi compute module can read out all the messages that we have in the car. And this compute module also allows you to connect devices through USB. So if you want to, for instance, get some data from a motor controller, that would also be possible. The Pi then transmits our data to a web server, which in turn, uploads the data to InfluxDB. And we made the choice to use InfluxDB because it was well-supported in the entire community. There were a lot of tools available for it, proper documentation. So yeah, we really wanted to use tools like Telegraph to, yeah, work with our data as well. But then we also needed a data analysis tool. And for that, we chose Marple because it’s a tool that’s basically in between two extremes that you see quite often. On the one hand, you have the Motech that I discussed earlier. But on the other hand, you have online tools that are a bit too simplistic. And Marple’s in between. It’s online. So everyone can analyze the data. But on the other hand, it’s also quite powerful in the functions that it has. That’s why we chose to go with Marple. And we also use Grafana for the visualization platform for live data because it provides good InfluxDB support. You can create your own plugins, and it has a lot of visualization options.

Robbin Baauw: 00:28:07.291 So once the data has been ingested into InfluxDB, this is what it looks like. You see on the left in the bottom left. Right here, you can see the different measurements that we have inserted. And each measurement corresponds to a CAN message. And then each field in the CAN message is also a field in InfluxDB. And what you can see here on the screen is the accumulator voltage data of our endurance event at FSG. So you can first see the photo straps when the driver accelerates. You can see the spikes when they break because we can break regeneratively. And in the middle, you can see the driver change where the voltage stabilizes. It can we see a small Photoshop where we pre-charge the capacitors that are in the car. And yeah, this goes for many other signals. All of them are inserted into InfluxDB, and we can analyze everything here. But we can also analyze it live. And for that, as I said before, we use Grafana. And this would be a panel that you would use during an endurance event. And here, you can see all the voltages that are in the Accu or the low-voltage battery. You can see the temperatures of your motors or your inverters. And you can see some other information about the state of the car. And this is incredibly useful because, based on this, you can make decisions to go faster, to go slower, etc. And you can also see that we have an InfluxDB panel integrated in here as well, where we can track events that happen in the entire system.

Robbin Baauw: 00:29:52.686 Now, the controls people are also analyzing some data during an endurance event. And this would be a panel that they might actually look at. For instance, what you can see here, the purple lines, that is the minimum cell voltage. And this cell voltage, of course, fluctuates. But if it drops faster than expected, it could mean that one of the cells is broken, a weld is broken, etc. And in that case, we have to drive slower because we lose half our capacity. And that’s why they are looking at the InfluxDB auto-refreshing graphs during an endurance event. In the bottom screen, you can, for instance, see the efforts velocity over the past minutes. And this is used to look at the effect that a certain strategy decision has on the speed of the driver. So if we know that letting them lift and coast a bit more cost a lot of time, we might make the decision to let them push a bit more, etc. And we communicate with the driver through walkie-talkies and in-ears. So the driver just fully focuses on the driving because, with these narrow tracks, you have to be really focused. And the people on the side with the laptops will tell them if anything needs to be changed in their driving style or if settings need to be changed, which I can quickly do the dashboard.

Robbin Baauw: 00:31:23.053 Another feature that I can foresee being used in the future is the live data feature of Marple. This is a feature which shows the data from InfluxDB in real-time. And I can see this being very useful on the testing track, where you are performing tests and you make your Marple projects. And you just open it to easily see your data instead of having to upload your entire run to Marble. Speaking of uploading your run to Marple, for us, there’s basically two ways to do it. First of all, we have our old panel here, which is part of our Grafana plugin, where you select the time range and we use the Marple API to upload it. An alternative that exists now is to use the Marple selection window for that. If you can see here, you can also select the time range and then boost your file, which basically imports it into Marple. So we are basically using both. And once you have uploaded your files, this is what it might look like. On the left, you have, well, your tree with all your folders. You can add metadata to each event. So you can see who was the driver, what happened here, etc. On the right, you can search for certain files, which can be really useful if you want to check out what happened a week ago and you have to search through like 50 files. This is a useful feature there.

Robbin Baauw: 00:32:56.388 So now let’s dive a bit more into how we actually analyze our car data. As I said before, we do this in Marple. And all this data is actually shared with alumni as well. They can also log in. So if they are done with work at the end of the day, they quickly log into Marple to see what has happened or secretly during the day, of course. It’s also possible. And here, they have their own projects, or they use projects that we make to look at the data. And some features that we use quite heavily in Marple are the computed signals that Nero showed that previously as well, like a moving average. Or you can actually use custom formulas here. So here you can see that our low-voltage battery management system provides a state of charge in two separate bytes. And we have to combine it to get our actual state of charge measurement. And that is really useful that we can use the computer signals here. Something else that we use a lot is layers, which allows you to overlay two files over each other. And you can add offsets here, etc. So why this is useful for us is that you can compare different laps of different drivers to each other. You can see where the driver may be able to improve. And I have an example here with two very different laps. It’s the same lap but driven in very different ways. And the drivers were on different strategies. So this makes sense. But you can, for instance, see that the green driver here reaches a much higher velocity. It’s much more aggressive in the steering and reaches the maximum power a lot more often. And this is something that’s very useful for the drivers themselves to analyze as well.

Robbin Baauw: 00:34:47.887 And for our controls engineers, they might be able to tune that traction control using this analysis. So on the bottom, you see different settings that were used. And then the top, you can see the accelerations that were the result with these settings. So you simply drive off, you drive back, and you have your data here, and you can quickly see what the effect was on certain settings on your acceleration and your slip. So that’s a really useful feature here as well. Now, in the team, we also have our own motor controllers, which are basically the PCBs that are connected to the motors. And they are the high-power PCBs in the car. And we make them ourselves because it saves a lot of weight and a lot of space in the car. And if something is broken or something doesn’t work properly, you can easily debug it because you know exactly how it works. And this is not the case motor controller works. And these motor controllers are a MATLAB Simulink model as well. So again, generates a lot of data. What we use here is our high-frequency logging. So our motor controller stack is able to log as our controller is running it. And here, you can actually properly see the graph of the AC signals. You might think, “Oh, this doesn’t look great.” But this is actually how it looks like physically using the space-vector modulation. And if you were to log at lower frequencies, they would look like sine waves. And this doesn’t tell you much if you’re debugging certain issues. You can also see, for instance, the voltage, the spikes are slowly increasing, and this shows that the speed is also increasing.

Robbin Baauw: 00:36:45.167 So with this high-frequency data, we cannot log a lot of signals because, at 10 kilohertz, if you log 30 signals, your data buses will be too full. And especially with all the noise that this creates, it’s not a good idea to log all of it. But fortunately, we can use the computed signals here again to reconstruct our motor model in Marple. So we log only like 10 signals. And based on those 10 signals, we can create about 30 other signals that were based on these signals. As you can see here, we are computing the currents on a certain phase based on other fields that we have received. So that’s a really useful feature here. And we can also collect the data of the motor controllers in the car. So we can collect it through the Raspberry Pi, as I said before. You can debug the failures that may occur. But you can see here is that we jump into an overcurrent protection mode because, apparently, the electrical circuit thought there was too much current running through a specific phase. And then we jumped through a safe state. But then the question is, “Why did this happen?” And using both the car data and the Dino data, the Dinos where we spend our motor controllers outside the car, we are able to figure out the root cause of this and hopefully not have the issue again at competitions, which was fortunately the case.

Robbin Baauw: 00:38:20.771 So after all of this, how should you be using InfluxDB? Or what are some tips and tricks that I found over the years? First of all, use the Flux language. It’s a super powerful language that allows you to query a lot more than I initially thought. Something else that’s really useful is to chunk your queries. If you’re requesting a lot of data, then it’s a bit too heavy to let the Influx perform computations on all of it. So just do it in small chunks. Use alerts. Influx is able to figure out when a certain signal is over some pre-configured limit. And for instance, send a message in a Slack channel that warns you, “Hey, something’s going on.” And think about how you get your data to Influx. Initially, we directly uploaded to Influx from our Raspberry Pi. But we then noticed that to log at the full frequency, it takes too much bandwidth that we didn’t have remotely. So then we upped it for a binary protocol from the car to the server, which then uploads the data to Influx. And similarly, for Marple, just use the projects feature. This is incredibly useful because you can easily share a project with someone. You can share a link to your project and your file to quickly notify someone, “Hey, something’s going on here. Do you know what it is?” And that allows people to instantly see what’s going on. And also, as I said before, the calculated signals feature is really useful. And in case that your hardware is not that great, you can adjust the plot resolution. So you can say, “Okay, I’m now showing fewer data points.” And then Marple will take care of that with the interpolation that they are doing. So you’re not missing out on that much.

Robbin Baauw: 00:40:16.348 And with all of that, I would like to give a small demo of how we actually use Marple. So here you go. I hope you can see the screen here. And this is —

Nero Vanbiervliet: 00:40:30.843 Yes, we can see it.

Robbin Baauw: 00:40:32.268 Cool. This is a project that, well, I used quite a lot last year. And this is the data from a test track session at Formula Student Germany. And for instance, the motor controller panels are quite interesting, what you can see here. These sets, that’s a torque set point that we send to the motors. And TWI is a computer torque that we receive. For instance, see that there’s a tiny delay here when you request your torque and when it is actually applied. You can see the philosophies here. And I’ve now selected only one motor. But I can, of course, select a lot more. So this screen allows you to simply figure out what is going on with the response of the motor controllers, what is going on with the current measurements that you can see here, etc. Another panel that’s really useful is the [inaudible] low-voltage battery panel. Here, you can see basically everything about the voltages of the total accumulators. As you can see, at this point, it was about 530. The average voltage of your cells, you can see if there’s a difference between the minimum and the maximum voltage of your cells because that’s also an important factor. If there’s a difference, you need to balance it. You need to balance them. You can look at the current, etc. Temperatures are really interesting to see. So you can see a lot more spikes here on the inverter side. Then on the motor side, it just gradually heat up, and they also don’t cool down that quickly. You can see here, which is not the case for the inverters.

Robbin Baauw: 00:42:12.828 Or for instance, an interesting feature. So you can look at the maximum allowed power versus the power that you are actually using. I can see that we were well under this power. And what you can also see here is that the maximum power that we wanted to use sometimes decreased. And that has to do with the cell voltages that just dropping too far. And we don’t want to let them drop below a certain voltage because that’s bad for the cells, and that would cause the car to actually stop in — that’s a safety feature. So that’s a really quick demo of how we are using Marple, and there’s a lot more to it. Everyone uses it differently. But yeah, I would encourage you to upload some data and check it out as well. So I guess we’ve come to the Q&A. Thank you for watching.

Caitlin Croft: 00:43:07.084 Awesome job, you guys. That was amazing. I heard this all yesterday, but it was even better today. I loved all the graphs. That was awesome. So the first question is for Nero. Is it possible to populate InfluxDB using Marple? Does it require one to have installed both apps separately?

Nero Vanbiervliet: 00:43:32.725 Yes. So I’ll take all the question in two parts. So first of all, the installation of the apps is separate. So you don’t need to handle the InfluxDB installation yourself. And for Marple, you have two choices. You can either install yourself in a self-managed way. You can host it yourself. But you can also use our cloud version. They need to establish the connection between these two. So you don’t do it in both if you want a less InfluxDB, that is. You could also add files to Marple. And that way, you would have a separate track. As if we’re talking about populating InfluxDB from Marple, this is not possible. This is a choice we made also deliberately. We don’t want to touch the original data. We just want to read further InfluxDB, make sure we don’t miss something up. And we just want to read things from it and help you get insights. But we don’t want to go back in the other direction.

Caitlin Croft: 00:44:31.524 All right.

Nero Vanbiervliet: 00:44:32.171 Does that answer your question? I think it was Harman?

Caitlin Croft: 00:44:36.585 It was Yuri.

Nero Vanbiervliet: 00:44:38.067 Oh, okay, sorry.

Caitlin Croft: 00:44:39.056 Yeah. [laughter] Let’s see. Question for Robin. How quickly can you see the data from the car to InfluxDB and Marple? Is it like 1 second or 30 seconds?

Robbin Baauw: 00:44:54.078 It’s basically 1 second or maybe even less. But you can basically instantly upload the data to Marple or InfluxDB. I think there’s maybe like half a second delay there, of course, because it takes time to transfer everything over the internet. And then, in Marple, there’s the real-time feature that I showed in which you can configure the refresh rate. So you can set it, I think, to as low as 1 second as well or 5 seconds, 10 seconds, etc. So depending on how much you’re actually showing, you should configure that because, if you’re showing like 100 signals, you should also give Influx the time to process it, of course. But yeah, it can be 1 second indeed.

Caitlin Croft: 00:45:42.085 In one of the slides, there is a Golang — in one of the slides, Golang is mentioned. For what purpose is it used with InfluxDB? So I will say this. InfluxDB is written in Go. So that’s a big component. Robin, I don’t know if you want to add more to that.

Robbin Baauw: 00:46:02.031 Yeah, we’ve decided to write our web server in Go as well, especially because it has a very good API with Influx as well because Influx is, of course, written in Go. And Go is a very — yeah, well, we like the language for a web server with all the concurrency features, etc. The web server is written in Go.

Caitlin Croft: 00:46:25.961 Well, let’s see. This is a question for Nero. How easy was it to make the connection with InfluxDB?

Nero Vanbiervliet: 00:46:36.863 So I think we can take all the question two ways, first from our perspective but also from the perspective of people establishing connection for their InfluxDB with Marple. So for us, I think it was quite straightforward to make the connection with InfluxDB. I think we mainly have to think conceptually about, “We already have these interactions with Marple. It’s very easy to zoom, then make the things move, and also everything updates instantly.” We have to think about, “Okay, how can we map all these actions to corresponding Flux queries?” So that was a challenge we had to think about. But yeah, we ended up tackling most of the things. So I think InfluxDB integration is already on a high level compared to what we can support with files. For new customers, from their point of view, I think it’s pretty easy. They just mainly have to add the API token and also add the organization and the URL of the server. And then they’re good to go. I think that that’s just the main thing. The only hard part is, sometimes, you do have to expose your InfluxDB so that we can reach it in case you are using a cloud version. So you should also think of it about how to handle it infrastructure-wise.

Caitlin Croft: 00:47:51.847 Awesome. So I have a question for Robin. I know you went into this a little bit. But I’m just curious. With your team, as you have people come through the program and new students, how do you guys approach the knowledge transfer? Because you have such a range of students who join with level of experience, how do you handle that? And how do you get them up to speed on the tech stack that includes Marple and InfluxDB?

Robbin Baauw: 00:48:28.182 That really depends on the department. But I can go into the software department specifically. First of all, it’s documented quite thoroughly all the software features that we use at the team. So we encourage the new engineers to simply read through the code base and try to figure things out themselves that way as well. And then there’s also a huge alumni base that is always available to help them out with questions. So yeah, now this would also include me. If they have questions, they can just hit me up on Slack, and I will respond to them as well. And we also have a technical committee, which is a committee of people that review the designs or the progress of the people on a monthly basis. And based on that, they get feedback on how they might be able to improve, what they can do better, etc. So I think there’s a lot of different things that contribute to the knowledge transfer here.

Caitlin Croft: 00:49:33.462 Yeah, absolutely. And how did you guys — was it over the course of trial and error that you guys figured out the data collection frequency? There’s so much data that can be collected on the car. How do you guys figure out how — at what granularity did you need to collect the data?

Robbin Baauw: 00:49:56.087 That’s actually quite a simple answer to this. We collect everything that is being generated. Our control systems run at 250 hertz currently. It could be possible to increase that in the future, of course. And then the amount of data would also increase. But so far, we haven’t been limited by the telemetry stack in terms of the amount of data. So if a frequency were to increase, it should be possible to also collect all of it as well.

Caitlin Croft: 00:50:26.451 Awesome. And how do you guys approach data retention? How long are you guys keeping the data? And what do you guys do with it?

Robbin Baauw: 00:50:40.872 We keep it as long as the storage officer allows. And if it’s a really busy period, we try to keep all the important information in Influx always. And we upload everything to Marple, so they are basically our storage as well. So yeah, I would argue it’s about three months that the data is on Influx itself. And after that, it’s deleted to make space on the server.

Caitlin Croft: 00:51:09.405 And I know you guys mentioned using Flux. Are you using Flux to downsample it for more longer-term storage?

Robbin Baauw: 00:51:18.810 We’re currently not doing that, especially because all the data is also at Marple. And that’s the platform we use for analyzing the data. Therefore, we don’t really have to — we don’t really have to do it.

Caitlin Croft: 00:51:35.949 Okay. Cool. More of a fun question for Robin. Now that you can see all the data in InfluxDB and Marple, what did you learn from the data or his own driving?

Robbin Baauw: 00:51:51.813 From my driving. Oh, well, I haven’t driven the car yet because the weather has been too poor to actually drive it. But I’m sure I’ll be very slow [laughter] compared to the people that know how to drive, especially in the braking. You can brake very late. And you can if you want to turn quickly in the corner, you have to actually press your pedal counterintuitively because then you can use the control systems to make it turn. And that’s going to be very hard for a non-experienced driver.

Caitlin Croft: 00:52:28.489 You’ll have to post about it on social media and let us know how that goes. And it’d be interesting comparing InfluxDB dashboard the difference between you driving it and someone who’s driven a lot. That might actually be kind of an interesting comparison. [laughter]

Robbin Baauw: 00:52:44.461 Yeah, indeed, indeed, yeah.

Caitlin Croft: 00:52:47.607 Is there any GitHub repo your team is maintaining that we can refer to and contribute to?

Robbin Baauw: 00:52:56.789 I’m afraid that’s a closed source, which, yeah, of course, it’s still a competition. We always want to help other teams, etc. But this is something we’re not just sharing.

Caitlin Croft: 00:53:11.367 Makes sense. You got almost 90 other teams who are trying to win. So you’re like, “No, I want to keep that to ourselves.” [laughter]

Robbin Baauw: 00:53:20.340 Exactly. Yeah.

Nero Vanbiervliet: 00:53:22.528 I think same goes for [inaudible]. Most of it is clusters. We were thinking about having some components if we can open-source them, open it up, and keep another part separate. But definitely, also, we’ll give you a community update if that changes in the future.

Caitlin Croft: 00:53:38.723 Awesome. How do you make use of tags? Or do you use tags, and how do you use them? I think this is a question for Robin.

Robbin Baauw: 00:53:49.543 We don’t really do it currently because it’s basically one stream of data. And I can currently not figure out any useful way to incorporate it into our system. We mostly add metadata on Marple once we determine these are the chunks that we want to look at. But maybe it’s nice to tag it with some data in the future depending on who drives, etc. But currently, I don’t really see a feature that would make it — yeah, that would be useful here.

Caitlin Croft: 00:54:30.247 Well, maybe in the future. You never know. [laughter] So I know you guys use InfluxDB at work and school. Do you guys tinker with it at home at all?

Robbin Baauw: 00:54:45.567 Well, for me, for my students, it’s not really work. It’s like a hobby project. And there, I tinkered with it quite a lot because it’s also interesting to see how it works, just reading through a bit of the source code as well and figuring out how it works internally. And if I have a whole project that I want to do, I can use it for — I will definitely use it as well.

Caitlin Croft: 00:55:12.662 And what about you, Nero? Do you got any home projects that you’re using InfluxDB before?

Nero Vanbiervliet: 00:55:17.980 No, not yet. I’ve got a long, long list of stuff I want to do. When I get to it, I think there is some interesting stuff going on. At my dad’s place, we have solar panels on the roof. It would be nice to get the data measurements out because I feel like we are now very limited in looking at the data because it’s just a proprietary thing. And I think if we could hack something in there and put the data to a database, that would be a really nice project. But I’ll have to get to it in some over some holiday periods.

Caitlin Croft: 00:55:52.557 Yeah, don’t we all have those projects at home that we just never get to? I do know of a few other community members who are using InfluxDB to monitor their solar panels. One guy in the US in Minnesota where they get a lot of snow, he would use it to understand when the snow is covering his solar panels because, obviously, once there’s snow, the solar panels can’t actually do much. So it was kind of an — I never thought of that with solar panels. But then when he said that, I was like, “Oh, that totally makes sense. Snow is covering them. They’re not going to be able to collect the energy.”

Nero Vanbiervliet: 00:56:29.679 Yeah, cool.

Caitlin Croft: 00:56:31.275 Thank you everyone for joining today’s webinar. We’ll just stay on here for a few more seconds just to see if anyone has any last-minute questions. Really appreciate everyone who joined today. Some really great questions. Thank you, Nero and Robin, for a fantastic presentation. I think it was really cool seeing your guys’ take on it and combining two different fantastic technologies for a really fun use case. I mean, you can’t go wrong with electric vehicles, a racing car no less that you guys are building from the ground up. I know I was really impressed when I first met you both and I was learning that Robin, you guys were building it from the ground up completely. So really appreciate it. Thank you, everyone, for joining. And once again, this recording will be made available by tomorrow morning. Thank you.

Nero Vanbiervliet: 00:57:26.286 Okay. Great. Thanks. Bye.

[/et_pb_toggle]