Diorium. You're amazing. Last talk of today in this room. And that's full. Great.
I have been three guys, but check out an old VW Perlo.
That's great. Mark, Loiq, Tibu, and converted that one to an EV.
As I'm myself, EV driver, I'm much impressed what you did.
Well, they haven't seen the slides yet, so maybe it's not that impressive. I don't know.
Have fun. Thanks.
All right. Thanks. Hello, everyone.
So indeed, as mentioned, this is the team. We founded the company a while ago.
We were lucky enough to found a startup that also got acquired a few years back.
And when we left the company that acquired us, we wanted to try something completely different.
We've been working in finance, building open banking aggregators.
And so we really wanted to learn something completely new.
And we took all of 2024 as a sabbatical to just play with cars, like what can three boys actually do, but play with cars.
Why did we actually decide to tackle on that challenge?
Because we saw that the transport industry, automotive, but also when you look at all the types of transportation,
can be not a cool transportation, whatever.
It's kind of siloed and also a bit closed.
It's not like that much open source, big open source projects in the transport industry.
And we also were seeing more and more scary stories about cars being hacked or EV charging stations being hacked.
And all that stuff, and we were like, okay, but what is the actual lifespan of software in cars or any kind of other transportation?
And what does it actually mean?
Because we feel that maybe that just a feeling again, that the security and also the safety of all that software is a bit opaque,
very specific to each manufacturer.
It's not like what we have in the open source where everything is kind of transparent and open.
And there's no real off-the-market software for cars, right?
It's not like you can just buy a used EV and install the Linux of EVs on them.
So what does it actually mean to replace the brains of a car?
What does it actually mean to create that new brains software brains of a car?
That's a little bit how we got into this hacking project, which is going to look a lot more like a hobby project than a real product, but anyway, come back to this.
We also noticed that it's very difficult to make parts from different manufacturers to work together.
It's not like you can take a breaking system from Mercedes, for instance, and put it in a VW.
They don't talk the same language, so how do you tackle that?
Because in the end, you have plenty of components that basically do the same primary function.
It's just breaking, right?
So how hard can it be to make them work together in the same way?
So why do we have to have a completely different languages that these components speak?
How can you make them work together?
So we started thinking about, okay, we're basically talking about a grading vehicles.
Like, it doesn't have to be just converting it or whatever to an EV, but it's also, how do you make sure that your car is upgradable or that you have an aftermarket solution for your car or any other vehicle?
It's much like you have opportunities to install Linux on your old computers or post-market OS on your phone or what not.
So this all sorts of open-source solutions for these types of hardware, but there's no option for the new smart phones and wheels, basically, because the cars are becoming more and more smart phones.
So what we mean by upgrading is changing the engine to something that's more environmental-friendly, could be engine swap.
It doesn't have to be electric, but it can just be something that's polluting less, I would say, or complete EV retrofit like what we did.
But also adding some basic things to existing cars like an infotainment system.
Why do you have to rely on some, again, proprietary infotainment system, why don't you build your own with open-source tools?
Assisted driving, autonomous driving, also something that would be nice to add on cars.
This open-source project is to do this, by the way, especially the autonomous part.
We might have heard of, come out of AI, for instance, or even remote control.
We dig into the topic just a real small disclaimer.
None of this is road certified.
We know it.
It's not our goal today.
So we did this on our own funds.
So it means we use components we could easily find.
Also with the second goal that we wanted everybody to be able to get started as well.
So this is not running on automotive grade hardware and all that crap, because we simply don't have the money for it.
But we could definitely adapt it if the need would be there.
So now that this disclaimer is done, why don't we try to upgrade this to 2007 Polo using only open-source software?
This is the donor car.
It has kind of a history because it was my first car.
So this is the first car that I drove.
And I sold it to Luick.
It was sitting right there. My associate a few years after that.
And at some point you wanted to get rid of it.
And it got really the good timing for us to work on that project.
So we said, why don't we buy it back through the company and actually do something with it?
So we worked on it.
And just this is a pretty heavy slide.
I'm not going to read everything.
You can read so you can read by yourself.
I just want to show you almost everything we've been doing on that car.
Also showcase the mechanical work that unfortunately I won't have time to go to much into details in this presentation.
And also the hardware and software part.
I mean it's only 40 minutes.
I cannot go in the details of everything.
So we're going to fly over a few things.
Explaining how we used opens our software with this.
And in order to avoid you from falling asleep, I'm going to show you already now what it looks like.
And so you can see we just unloaded the car from the trailer.
It was about 10 days ago.
We moved the car from the place we actually worked on.
And we moved it to a storage facility that's closer to the testing track where we actually going to be driving it.
Because again, not to what's certified.
It's like you can just drive around with it in the streets.
So the car is actually as you can see, driveable.
Now the reason there's a very big cable is because there's only part of the battery in it.
And also it was raining a lot that day.
So we didn't want to fry in the car because we removed so much stuff that water leaks in a bit.
But anyway, so the car looks like this.
It's electric, there's a cable, right?
So yeah.
And there's actually a huge ACDC converter that Luis built as well.
That is sitting on the passenger seats that converts basically just standard grid electricity to what we need for the car.
And so we just plugged it on the walk plug and then we started driving it.
So that's how we tested the car to begin with.
So this is what it looks like now.
Pretty cool, right?
And all that thanks to open source projects.
And for some of them probably unusual technologies, things you would not necessarily expect to see in a car.
And that includes a mixer, which is a language working running on the early virtual machine, aka the beam.
It's also using nerves, which also you probably may have heard of or not.
But that is a tool that I'm going to talk a bit more into details afterwards, which allows you to package your firmware for the ECUs that we actually built.
There's going to be some VUGS, some Flutter and some Phoenix, which is a way for us to build APIs and web interfaces for the components we have.
So while you're mixer, it's a dynamic functional language running on the beam, already mentioned that.
The beam was really made to run highly scalable and highly available systems.
It was basically built by Ericsson for telephony purposes.
So it's not like it's just going to fall on you anytime soon.
So it works quite well, it has decent footprint for what we want to do.
And what is really great also about the mixer itself is that it uses pattern matching as a parading, which is really good when you want to parse a series of bytes or bits or whatever.
Or if you want to parse messages, which is exactly what almost 80% of this project is actually for.
So if you see the example on the right, that's the only thing you need to actually parse meaningful information into a series of bytes.
And it really shows you how powerful pattern matching can be in those types of use cases.
Another tool we've been using is called nerfs, so this is also based on Elixir.
And it allows us to create a firmware based on build route.
So it leverages all the power of build route, meaning that if you're not happy with the basic systems that they provide, you can still bid your own customize your own.
And what it does is that it packages your elixir code into something you can directly flash on an SD card and then you can use them on Raspberry Pi or any other boards.
It also supports redundancy of route partition over the air update.
So it really has all this flexibility that we can definitely use in a project like ours.
All right, so now that I've settled the idea of what we've been doing, let's look into more details about what we did.
First thing is understanding the cars language.
Like I said, they speak something together all the components in a car.
And I don't know how knowledgeable you are about, or somebody even all of that, so I'm just going to explain it to everyone, but they're all wires in your car.
And some of them are used for components to communicate together through what we call a canvas.
So it's basically a twisted pair of copper that is running through your car on which all components are connected.
And they will emit messages at a specific frequency, and then we'll also listen to messages that come at a specific frequency and do something with this information.
Right, so that's in a very high level nutshell what's happening.
And it looks like this.
So when you hook up a can sniffer, so it basically something you can plug over USB, and then you connect to the wires physically.
You get that kind of stuff when you run the car.
Or when you do something in the car.
It can be that you pull the handbrake, and then you see something changing.
Or that, you see something changing.
And so you need to start reversing all these messages, because what you see there is you see the idea of the message.
You see the frequency at which they're emitted, and then you see all the bytes that they basically contain.
And you have to figure out which bytes are basically linked to what behavior.
If you light the beam, something will happen.
If you open a door, something will happen.
And you have to figure out, figure this out.
And funny enough, when you start doing that kind of work and that kind of cumbersome, but fun work, you start also realizing that there's very little conventions in the end.
An open door on a VW car would be represented by a byte of, I don't know, FF, for instance.
But it's going to be 43 for another component.
So on and off, we'll have completely different values based on the component you look at.
So standardization is not really what we can see at least from cars of that era.
This is not that great, and the impression we have is that it's still not that great today, but we don't really know.
We will see what we try.
So yeah, doing this, you basically start figuring out what the car is saying, or what a specific component is saying.
And then you have to put these information into some kind of files.
The standard in the industry is DBC files, which you can find some requisitories off, because people have been doing this kind of stuff.
For some time now, I'm just mentioning the open DBC repository from Commodore AI, because it's an interesting repository.
And it gives you an idea of what DBC files look like, kind of a nuggly format to be on us, but that's the industry standard.
And we decided to make our lives easier, and we built our own library to deal with all of that in a lecture in the language that we use for our firmware.
And what we basically did was go for Yamul instead, instead of a cryptic format that DBC is, and what it allows us to do is to specify which frames are being received, which frames are being emitted, which frequency, which IDs and all of that.
And then we can write a mixer code to deal with these messages.
And so that's a complete library that we built specifically for this project, and that you can find on GitHub as of today.
Let's look at what the whole system looks like now.
And on top of it, you see all the components that are from the Nissan Leaf, so we have the actual motor, the inverted charter.
On the left, you have kind of standalone components that we are using connected to a completely different can network.
So you have the battery management system, steering pump and the brake booster.
And on the far right in green, you have all the existing components from the Polo.
So this is the ABS, the dashboard itself, the cluster, the ignition lock, the doors, all of that is actually being connected through specific networks that we created within the car.
And then in the middle, it's everything we built ourselves.
As you can see, so we were in the business of building banking aggregators, now we basically built a canvas aggregator, because you have the vehicle management system on top, which connects all of the different networks together.
And deal with the translation between all of these components and canvases.
And that's really what allows us to have this new brains for the car, and allows us also to use components from different brands inside the same vehicle.
So the vehicle management system is a central piece of the platform that we built, then we have controllers that are running the same code, they didn't use to, but now they are, then the infotainment and all that.
The first step we had to do was to get the leaf motor to spin.
So when you open it up, that looks like that.
So it's not really your usual PC, whatever, it's a bit more difficult to understand.
But we needed to find the correct canvas messages we needed to send in order to make it spin.
So you get the motor, it's pretty heavy, you get it from the delivery man or woman, I don't remember who delivered it.
It's quite heavy, but you don't know if it works.
Until you make it spin, basically.
So fortunately for us, there were a lot of reverse engineering of these motors available online.
And we managed to find the right-hand messages to send in order for it to spin.
And then the next step was to use the gas pedal of the car.
So we could have bought a completely new gas pedal, whatever, but we thought, hey, we already have a gas pedal.
And it's basically just a potential meter, so we can just put an Arduino connected to an Arduino, read the values,
and that will basically be the throttle that we expect.
We expect 100% throttle when, you know, pedal to the metal and 0% throttle when it's completely released.
And so that's basically what we did in first instance, the first iteration of it.
We wired it on a plank and put the wires on an Arduino, we started looking at the values,
and then we created the can messages that were going to be sent to the vehicle measurement system.
And that's how we got started.
You can also see that we have, yeah, I'm not going to try to use the point on this,
but we also have something extra, a debt stage of the project,
which is the gear selector, also on that controller, PR and D.
Because at some point we need to decide in which direction the motor is going to spin.
So we initially added it to that controller.
We also had to build specific controllers for the relays, you know, the contactors,
because for such a motor to actually spin and receive current,
you need to activate relays in a certain order.
So you need to activate some phases in certain orders in order for it to actually spin.
And in order to control that order and to make sure we were not going to fry,
we build those controllers to do this for us.
And in the beginning we used the standard really hat from Arduino,
but somehow they were conflicting.
And then at some point we had the first epiphany, which was the engine spinning
when we were pressing the gas pedal.
And we call it the playing prototype, because everything was literally screwed on a wooden plank.
And yeah, that was the very first time that we got to celebrate because we had something that was actually working.
I should probably mention that none of this would be also possible for us without 3D printing.
So there's been a lot of 3D printing involved in this project.
You'll see it when we move to the more professional prototype.
There's been countless hours also spent on making plans and printing and all of that.
So yeah, kudos to these great printers that we've been using for this project.
So we had to go with something a bit more professional and integrate on the playing prototype.
And that's the version we have right now.
All 3D printed cases, completely new plugs that we had to wire ourselves.
You basically have the VMS on the left, which is Raspberry Pi 4, several canvas hats.
You have also the January controller in the middle.
And somehow that we built because we needed at some point to have multiple ways to connect devices.
And we wanted it to be possible for us to connect new devices really easily to the whole platform.
So we built those small can have.
So the VMS is structured like this, we have build group running on top of that.
We have nerves running year like VM.
Then we have our back end core and API in a mixer in Phoenix.
And on top of that, we also have a dynamic web front end in VUGS.
Why am I mentioning that this is dynamic?
Because the way we created our open vehicle control system is through what we call composers.
And you can basically compose a vehicle from any available component you have in your repository.
So in this case, for instance, we can see that on the left.
This is the composition of the vehicle we have today.
And you can see you have the Polo dashboard.
It has a contact source because they need to know when we flip the key.
The contact source is actually going to be the ignition lock of the Polo.
And then the rotation per minute source, which is a parameter of that specific component,
is provided by something that has nothing to do with the Polo.
It's a leaf inverter that we get the messages from.
So you can really mix and match all types of components in the same vehicle by doing this.
And you just, of course, is still so more to do.
But just have to work the code to write the code that fits to that specific component somewhere in the repository.
And we will go and fetch it.
For instance, in the inverter, the inverter also needs something specific.
It needs the ignition lock, the front controller is a Noviceous component.
So this is from the Noviceous one, of course.
So it allows you really to compose a vehicle anywhere you want.
And we wanted to push it further because we also wanted the dashboard itself,
what we show the interface that we show to also be composable.
So you can have blocks on the page.
And you can show graphs, you can show tables of data.
And you can go get it from any components that is running on your car.
And that basically looks like this.
So.
Hang on, let me go back one.
Okay.
So this this composer dashboard composer interface that I showed you actually
allows you to see all of that data without writing a single line of code.
And you can just hook up to that Raspberry Pi with your laptop or whatever.
The car is actually connected on the internet where we worked.
And then we could just diagnose the car like this.
It was kind of easy to do.
Generic controller.
So in the beginning, as I mentioned, we had specific code running on each of the controllers.
So those controllers are used to gather data from the gas pedal,
for instance, irractivate relays.
But each time we wanted to change something on those controllers,
we had to find the way to update the firmware on them.
So we decided to opt for a different strategy where it's actually the VMS that's going to adopt controllers
and give them the configuration that they are expected to have.
And so all of that happens in a specific adoption process that we created,
allows us to have exactly the same code on every controller to adopt them once.
And then they have the exact purpose that we want them to have.
Now, since this is a pretty old car,
it's not like you have a pretty cool infotainment system on it.
So we thought it would be nice to actually build our own from scratch using nerves as well.
And also we needed a way to select the actual gear, so PR and D in our case,
because we didn't really want to have extra buttons in the car to do that.
And yeah, that was really the idea for the infotainment system at first.
And for this one, we actually went for Flutter to build the interface.
And this is also where we will show later on information about different system statuses in the car.
In the beginning, we had a complete VUGS front end running in a browser.
So it was basically starting in Kiosk mode with cog and webkit,
and it was showing a web page.
And we had poor performance on real time graphs, so we decided to try something else.
And so we went for a specific fork of Flutter by that worked some build route,
which happened to work pretty well.
And we haven't looked back since.
Now Flutter might not be the perfect technology for this,
but at least for what we've been doing on this case is pretty neat.
What does it look like in the car?
It looks like this a bit messy, but on the bottom left you have the VMS,
you have relay boxes, you have the back controller in the middle,
and you can already see the RC car that we've put there in the trunk.
Because when we were testing the RC driving,
the only component we had available was on the car,
so we hooked up directly on the small car.
So the small car was controlling the bigger car, which was kind of fun,
but anyway.
I'll show you a video of this afterwards.
All right, small adaptations we had to do to the car,
really quickly on this one.
I don't know how much you want to know about mechanical stuff,
but in a car of that age, the braking assistance is actually provided by the thermal engine.
In the sense that there's depression that's being caused,
and that depression provides you braking assistance.
But guess what, we don't have a thermal engine anymore,
so you have to find another way to provide braking assistance.
And so it happens that Tesla is a pretty cool component,
which they call the I booster,
just provided 12 volts and it provides you braking assistance.
So just write that and that's it.
Hydroling pump.
Remember that small box on the left in the small architecture diagram I showed you?
This is the Hydroling pump for the steering wheel of the polo.
And it so happens that this kind of device only starts when the engine is running.
Meaning when the diesel engine is at idle RPM level.
But right now we have a motor, an electric motor that has zero RPM when it's powered on.
So we need to find a way to force it to actually start.
And so we have to control it completely independently from what it used to be.
So we had to reverse engineer the canmessages and send the canmessages at the right moment.
Anyway, another thing is building the batteries.
Yes, we didn't buy existing batteries.
We took a use cells and wired it all together.
A pretty dangerous work.
Don't necessarily do this at work, but it took us a lot of time to make this right.
A lot of 3D printed pieces like I said, this plenty of stuff there.
So we have an electric car.
Why don't we transform it into an RC?
We already know we can accelerate, right?
We can send canmessages to make the motor spin.
That we know.
How do we break?
How do we steer?
That's still a question for us.
Breaking actually turned out to be easier than we thought.
Because the Tesla I booster is basically what you have when you have auto pilot.
So it also has canmessages that can control the rate of the fluid that goes through the pump.
And so you can actually control that with canmessages.
And we managed to reverse that as well and figure out what to send in order to do that.
And at some point the breaking pedal started moving based on canmessages.
So that was a second win for us and we were quite happy to see it move.
So breaking that's done.
The next step was to figure out how to steer.
At first we tried to reverse engineer an existing steering column from a more recent polo.
But we kind of failed doing that.
So we decided to just trip away.
It's ICU and serve a motor and just, you know, just put one of ours on it.
So it means that the steering column is now controlled by an Arduino with a controller like a generic controller, like I explained before.
And this allowed us full flexibility over how to actually control it.
So we don't depend on the manufacturer's ICU anymore for this component.
So it's kind of different from the approach we took for the break booster or from the motor.
But at some point we needed to find a way to move forward with the project.
And clearly at that point, reverse engineering the steering column was not working in order advantage.
But the card that you saw driving before in the beginning of the talk has this.
So if you have the remote control, flip a switch and then you can control it.
Unfortunately we didn't have a Dolorion at hand for those that remember back to the future.
I would have been way cooler to do this with a Dolorion.
But yeah.
Because it's pretty much the same experience that Doc is actually having when he drives it in the 2.0 mic.
What now?
Okay.
So we're at this stage.
The car is there.
It's stored.
We're going to test it somewhere in the next few months of the facility.
We need to reserve the place and all that.
Because we can't drive it in an open road.
So we will drive it in a parking lot that's dedicated to testing vehicles.
And also there's a track next to it that we can use as well at some point.
What are we doing now?
What are we still working on?
The OVCS mini turns out that doing remote control stuff and autonomous driving on a wanted car is not necessarily super safe.
So you probably have to test things on a smaller vehicle that will not kill you.
And so everything you saw all of the stack, the hardware and software stack has been put into an RC car that's much, much smaller.
But it's actually the same stack.
And it's just that the composer for the vehicle is slightly different because there are some components that don't exist.
There's no inverter and all that.
But the platform allows you that flexibility.
It also uses can bus to work.
We are also working on a Ross 2 bridge for the car so that you can tell it or you can hook it up to any.
Any stack that exists for for Ross 2.
The cool thing about this bridge is that it's not going to run Ubuntu.
There's an actual a lixir client for Ross 2, which runs on build route.
So it's much simpler.
We have something that's super efficient.
And also working on a on a perception stack at the moment.
We have a few things running right now.
But again, all of these things at some point need to be put together and make sense.
So right now we have.
We detect objects.
We send the objects to the bounding boxes in the classes to Ross 2 topic somewhere.
So all of this is in progress and will at some point be put together into the same bridge.
There's already rudimentary lane detection as well.
That's it's not shown here.
Another component because why not is an OVCS remote because instead of using a
RF or a transmitter or a muffling remote.
We would be nice to have a multi protocol.
Something we can put data back into onto a screen.
And it's also just cool to figure out how these things works as well.
So again, all of this built with open source software.
I didn't show much code.
Sorry about that for those who wanted to see it.
But everything is all the code is open source.
For those asking, yeah, but what about the hardware?
There will be as well.
But you know that's documenting hardware is more.
Takes more time than documenting software.
Even if software is not well-documented at that moment.
But we will definitely release all of this very soon in the next few months.
So that everybody can see what we did, how we did it.
And have an idea of how fun it is and what fun they can have.
And again, small reminder, none of this is road certified.
It might be one day, but you need to look at this as a massive hobby project that we've been working on.
So if you want to find out more about this project than follow the progress.
You can look it up on GitHub right now or just drop us an email.
So thanks for attending this talk even though this part has been recorded afterwards.
And thanks for your attention.
And so on the RC car, somehow the picks started going crazy and it was basically spinning the motor out.
So the RC car just went completely to the wall.
If that would have happened on the big car, we would have been in trouble.
So that's exactly why we won that small scale car.
There's a question over there.
I think you really want to ask it.
Oh yeah, there's questions everywhere.
Sorry.
Okay.
Two microphones.
I only want speaker.
I struggle to find time to play with an ESP32.
Can you tell something about the human resource part?
How much time of your life you put into this thing and how much budget you actually put into this project?
So we didn't work full time last year.
Again, we were supposed to also take a rest and all that.
But we did work about three to four days a week for the whole year, three people.
So I wouldn't say it were long days, by the way.
It was not like a 9 to 19 or something like that.
But you know, much order and sometimes with a beer.
So yeah, I would say maybe one, one and a half full time over a year would be pretty.
Well, one and a half full time over a year would be a pretty fair statement.
In terms of money invested, there's about 20, 25k that we put in the car.
Nobody would be crazy enough to put that kind of money on a 07 car.
But that's pretty much where we are right now.
Everything self-funded and that's why we also are going to take some contracting work this year.
Because at some point we need to eat and pay rent.
But yeah, all right.
I have a question regarding something like this that was showed.
Let's say that there is an out-to-performed.
So how do you make sure that this kind of out-to-doesn't trigger something that would be reverse engineering
for even something different, right?
I mean, I think it opens a dialogue here because some stuff like those parts and everything
needs to be connected out-to-check for whatever reason.
And how to make sure that the process that's involved in there,
I mean, we don't deserve existing things.
That's the one to bring or trigger some kind of weird,
another issue or maybe, you know, reverse engineering even,
and fucking sell out to Diedon China.
Yeah, you don't.
It can happen.
Fortunately, it's not like we have the only issue we have stripped from a component
is on the steering column we used.
The system was bound to both the vehicle management system and the Nissan leaf can,
is that the problem with the diagram is on its own can.
It's on its own can network.
Yeah, sorry, the arrow is a bit weird, but it is completely separate.
It's not linked to any other.
And the reason we have all these can networks is because manufacturers may have chosen the same
ID for messages, but to do different things.
So you don't want them to clash together on the same network.
So you have to keep them separate.
All right.
Yeah, okay, cool.
I was wondering, you mentioned, like, safety is the first priority.
And you're going to do, you know, testing.
What fill save do you have in place, like, for when you do this test,
that if something goes wrong, you have a means of stopping the car or, you know.
So you don't see it that much on the last picture, but anyway, it, it crashed.
Anyway, there is a big red switch inside the car.
If you trigger it, so if you just trigger it, it shuts down all of our platform.
And you're left with two things, two mechanical things that are still existing.
You're left with the steering wheel, that still works.
And the brakes, that still works.
You don't have any throttle anymore, and you don't have any component of hours that still runs.
It just shuts down everything.
And cuts, of course, the high voltage.
So it really cuts everything that can go wrong.
And you just have to find the way to steer the car and break.
That's just safe as we can be while testing.
And also, you don't notice it, but there's a small thing you can pull at the side of the car.
Sorry?
Meaning that when we, when we will test it for autonomous driving at very low speed,
we will be next to it, and if anything goes wrong, we just pull it off.
But it's likely we're going to have somebody in the car in the first steps for these ones.
I know that's a pie because it's a shape, and you can easily do that.
But what if it's really hot or cold, and you know, by will not act and run in the same way,
when it's X now, when you go up and down and for the car, you need something that can stand like a plus for 40 or in, you know,
or minus something.
So did you think about to use some other board that's also free there to, and that can stand that?
Well, yeah.
We looked into other alternatives, but it felt like the easiest to find was Raspberry Pi's an Arduino.
So we went for this, the cheapest as well for what we were doing.
But yeah, there are other boards that are probably better.
We just haven't done a complete analysis of it.
So yeah, it might break if it's too hot or too cold.
Yeah.
We won't drive it at minus 40.
Hello.
Thanks for the presentation.
I got a question about it.
Again, it's something that's literally a lab on wheels, a more than something that's meant to be driveable,
but a different platform, different car, would have made a different, of course.
But with the car that we had, which is a city size car, this is how we built it.
We could also have put the batteries somewhere else, whatever.
But anyway, there's always, you know, something you could have done differently.
But yeah, a lot of this, Louis also welded all the welding job.
We had to weld for the batteries to be slid into something that is closed, I would say.
We have aluminum boxes that were welded so that we can put the battery back.
It's there are other people who can't cause it a similar.
Well, yeah, first we need to test it, see how fast it drives.
And then, well, first we need to make sure it's safe and then see how fast it drives.
So yeah, that's definitely one way this could go.
We will see, honestly, it depends on what the testing says.
Okay.
Hey, working with Alex here, you often hear letters crash for a handling.
Does it work with Sierra?
No, we don't want the car to crash, so it doesn't give a different meaning to the saying.
No, of course.
Hi, so one more harder aside.
Yes, a harder aside.
Have you, like, you said that maybe someday when road legal have you given it any, like, research,
how much would it take to actually make just a software, you know, road legal.
So we haven't.
Hey, thanks for your presentation.
And I have a bit of a matter of question, which is, you mentioned that,
we could have tried this, we could have tried that.
And that really interests me because this is a very open end and project.
And since you're doing it, like, kind of on your own, on your own schedules, you could have gone in any direction.
Yeah.
So how, but yet you still got a lot done in a very short amount of time.
So how did you kind of keep your eyes on the ball and not get focused on, like,
let's do something else completely different and abandon this project?
I think we were always focused on the goal of making the wheel spin.
So there's a few milestones that we wanted to reach.
First was make the wheel spin.
And so the first step to make the wheel spin was make the motor spin with the pedal.
So something like that.
So at some, we got lost also in many directions all the time.
But we always came back to, okay, what's the next goal?
So when we felt we were going a stray, each in or on direction,
we would sit back and say, okay, but what's the next goal?
And said, okay, we want to, we want to show this at this conference.
We want to show that at this cup.
So also, again, conferences like this or talks are a good way to, you know,
kick you in the right direction, because you want to show something at that specific moment.
Sometimes you make it, sometimes you don't, but at least it gives you a goal.
So you can go astray, but then if you come back to something tangible,
and you have a reason to then it's easier and easier.
Okay, thanks for the presentation.
I was wondering how long it takes until the system reacts to import,
as you're booting Linux and then the virtual machine.
So.
Well, we haven't noticed any significant latency, honestly.
So, but we haven't driven it at 120 kilometers on the highway.
So we don't know yet.
But what we can see is that the frames are being emitted or received at a pretty decent frequency.
So it's not like the footprint is making it completely insane.
So it's not like messages we're expecting every 100 milliseconds or suddenly coming every 200 or 300.
So.
At the boot time, okay.
The boot time that we have with this, so the the infotainment you saw,
we're about six or seven seconds to boot the screen.
The VMS is like is running on the right.
So it's running on the Raspberry Pi 5, the infotainment system.
So it's a bit faster.
And then the VMS is pretty much the same.
I would say 10 seconds to boot everything up.
But the idea is that it would be always on just like on a on a on a on a
V, you know, most of the system they stay always on.
And when you get into the car, then it lights up.
But there's a lot of things that stay up in the car.
And that would be the idea.
Since we have this huge massive battery, we can just, you know,
take a bit of juice out of it to keep our platform always on.
And what turns it off is actually the big red switch itself.
And if you keep it always on, then you don't need to care about boot time.
It's only when you switch it on again.
That's that you have that problem.
But we want to stay below the 10 second boot time for everything.
That's what we aim for.
And for now we've managed to do it.
Hi.
Okay.
What did you do with the entire instrument cluster stack?
As I noticed, it wasn't, it didn't seem to be there anyway.
Oh, yes.
It's still there.
And you can watch the both talk from yesterday.
Because we also wanted to make it as seamless as possible.
The changes that we made to the car.
So that it's actually the RPM needle.
Shows the RPMs of the leaf engine.
So we basically went there.
And the next step when we have everything right with the battery is also to use the fuel gauge
to show the percentage of battery left on the existing fuel tank gauge.
We've already figured out how to use a digital potential meter to do that.
A lot of curiosity.
That's the RPM range bits.
Because it's a little a lot about the electric engine now.
But in most retrofit work, you will see people changing it.
Basically, which we find a bit stupid because it's already there.
And it's kind of interesting.
If you go to that level of integration.
So it's really digging.
You don't have a separate button to start the electric motor.
It's really the polo ignition log.
So you do it like you would do on a diesel engine.
And it starts the motor, which is pretty sweet.
Because then it means you don't have an external system to start everything.
If you have the can messages for all of that,
we can trigger whatever you want on your own platform like this.
And it makes the integration as seamless as possible.
And it's almost like the car was electric to begin with.
Which is really nice when you're inside the car.
Is it?
Yeah.
Thank you very inspiring talk.
Is there any practicality like of your project?
What is the goal?
Because it's open-ended.
You said it's never going to be road safe.
Software is pretty customized.
Never.
Just never say never.
For now it's not.
But what's the goal?
That's quite interesting.
Question.
I wouldn't say we have a definitive answer to this one yet.
We don't know yet.
We know what milestones we want to reach.
What we want eventually is to see a drive alone around the track.
That's what we want.
And we will put the work into making it happen.
What's interesting, however, is everything we've learned along the way.
And give us ideas of things we could be doing either with the platform or completely different things we could be doing in products we could be building.
So the goal there was really learning new stuff, figuring out what we want to do in the next years.
We haven't answered all the questions yet.
But we have accumulated quite a lot of knowledge and interest in different topics that we didn't have before.
So it was really the opportunity.
It's something you never have an opportunity to work for on a production environment.
Even research projects that universities don't necessarily go that far in these in that direction.
We're using existing forests and all of that.
So it's completely, yeah, a bit crazy I would say.
But what's, yeah.
Hey, yeah, amazing talk.
Thanks.
I wanted why you used sales for the battery.
Was all the did you buy them with the motor?
Was the motor used as well?
Or did you buy like a new motor and for some reason have used battery sales?
So one of the things we did and that we would have done differently is that we kind of went to an EV shop online.
We said we want to buy a kit to convert a car.
And it turned out that we didn't really receive a working kit.
So the BMS or the battery management system was not the right dimension.
They gave us also an ECU that was not compatible with.
So it was a mess.
And we fortunately we got some money back there.
And for the battery, we were supposed to get an existing Nissan EV battery.
And it was not coming in and somebody said, okay, you need to find an alternative.
And they sent us a battery sales from a Nissan NV200.
So that's what you see there.
And we're much the same battery sales but configured differently.
And so what we noticed is that we just got the sales.
There's no bus bar, no wires, nothing.
So you have to, you just see this when you start working on it, right?
Say yeah, where are the bus bars?
And so you have to figure out all of this by yourself.
It would have been much easier to have a battery pack already done to cable.
Let's go.
But we didn't get that.
So I wouldn't say we were scam because we got something for a fair price.
But that was definitely not a ready-made kit that you can just put in a car.
And I think that's also something when you start converting cars or if you want to do converting cars,
EV cars is a hobby.
Be very careful with what you can find online and all that.
You will receive stuff but maybe not everything will work together as it's meant to.
And so we had to figure this out.
We still have to figure out quite a few things also with the BMS and all that.
So yeah, it's, it happens.
Hello.
Very, very lovely.
Thank you.
I was also reverse engineering campus on Volvo V50.
And I wonder, like you did much more.
So like I published the IDs on GitHub.
So do you know maybe if the same model of the same year, like do they reuse the IDs?
Does it make sense to publish the IDs you found?
VW has had different platforms, platform meaning electrical and communication platform.
The one from that poll, I think is PQ24.
I don't think it anyway.
So I think they had 2425, 26.
And the PQ platforms were just evolution on the same one.
And then they went for MQB or something like that, which changed completely because they went for a platform that was a five in number correctly.
Maybe I'm saying stupid things but which was supposed to be the same for all of their brands like Scoda and a VW and all that.
That was the MQB platform.
So there is already some documentation available for this platform, but not everything is there by the way.
But what you will find is people that recorded a canvas trace along the way.
So they just drove the car, got a canvas trace, all the messages for, I don't know, five minutes ten minutes and then they dumped it online.
So a lot of that you can find.
By the way, if you if you plan on reversing can on a car you're working on, don't remove the diesel engine first because when we started the project we're like, yeah, let's just remove the engine.
And then okay, now we need to reverse engineer the can but we don't have probably what is the central piece of the car.
So yeah, anyway, so you can find some documentation online, but it's not perfectly structured in a way that you can easily find it.
Sometimes you find information in forum tracks, sometimes you find information on get up, sometimes you find information by just talking to people on a random channel somewhere.
So it's it's a bit of a rabbit hole.
Just like I mean, if if you reverse engineer for example one component of this car, maybe you know like from your like community feedback that the same component.
And in the other car does it use the same IDs or it might be a completely different, do you need to read their engineer like in every car the same component.
I we don't know all components of all brands it might be that sometimes they use a standard configuration for the component we don't know what we have seen however is that the I booster from Tesla so the server break system.
It's also using other cars so it's a Bosch component basically it's a Bosch component that is used in several cars but it seems like the ideas of the messages are different so they probably program them.
Somewhere at the manufacturer or even maybe.
But they program them at Bosch we don't know maybe they send what needs to be on there without the IDs and all that to Bosch and then Bosch can figure it so not always but in some cases it might be the same messages we don't know there's so many components there that we.
Last question.
So are there any elements that you're looking for contributors for and are you looking for contributors to the project at all and if yes.
Or what what could people do to help.
Okay, I was not expecting that question.
Why if you want to get started send an email we would happily help you get started and figure out what's missing or how to.
Right now what we've done is mostly limited to the components we had access to.
If someone could just build you know components from other cars just by connected to the canvas and creating all the things that would be quite amazing.
To add new components to the platform because it would make it much more open.
There's also ongoing work we said the Ross to bridge and all that is still stuff to figure out.
So there's plenty of things to do but it's not like we have a list of things that contributors could jump into.
We would love to keep working on that project as well even do paid work based on that project but for now it's just again we're just showcasing it to see if anybody would be interested in working with us.
Or a company that maybe willing to pay us to keep some of that work going and use it in their own products or use it on their own use cases but so far it's not the case.
So we're taking on some other contracting work this year.
But yeah anything that can help us keep you know keeping this alive and keep working on it would be great.
And if you want to help just send us an email and we will happily see what can be done.
I'm over time so thanks everyone. I'm still around so if you have any more questions.
Many, many, thanks.