Speeduino Canbus Dash Demonstration
HTML-код
- Опубликовано: 27 авг 2024
- Speeduino digital dash using canbus. This has been added to a car that had purely analog gauges and no canbus support whatsoever since it was designed in 1992 when canbus was a twinkle in some engineers' eye. This system has in total 5 canbus devices:
Raspberry Pi 3 B+ for right hand cluster screen, with custom made canbus hat
Raspberry Pi 2 for left hand touch screen, with same canbus hat
Raspberry Pi Zero with same canbus hat taking data from the Speeduino ECU and converting it to a canbus stream (this I refer to as the "Canbus Bridge").
Arduino Nano for accessory inputs (indicators, hazards, handbrake, oil pressure, fuel gauge, ice warning light, ignition sense, main beam, dipped beam, brake fluid warning)
Arduino Nano for VSS using a BMW hall sensor with 48 tooth wheel on the drive shaft (already present).
The fuel, ignition, and AFR maps are all downloaded directly from the ECU and broadcast as canbus messages at boot with CRC checks to ensure they are accurate. The screens are synced on boot but I forgot to enable it here before taking the video. You can see there is a sync on key-off though. At key off the power is delayed by a basic delay relay board to enable everything to stop before power is cut. The accessory node on the canbus detects key off through its ignition sense.
The system is built using Ultibo alongside the small bits of code on the arduinos. It's a bare metal build, which is why it boots so quickly. The cluster screen actually starts up before the cluster LCD has initialised. I'd love to be able to remove the green boot message but it just isn't possible as it's part of the LCD firmware.
The layout of the clocks duplicates the original dashboard design mostly, although I added a central information section in the cluster that it boots with. The system adds numerous features not available on the original car such as headlight on warning when you shut the engine off, handbrake on warning when you set off, oil pressure detection, low fuel level warning, two separately resetable trip counters, and of course multiple different cluster views - classic, sport, and track. Other convenience features will be added (such as speed limit warning) later.
Every part of the display, on both screens (they both actually run the same application) is configurable through an XML file. So new displays can be added together with linkage between them. Obviously artwork has to be drawn where needed. There are many different kinds of guages and ways to control them - all configurable. For example you can provide code snippets within the XML to control the colour of a vertical bar gauge based on other engine parameters.
There are a number of features I have not shown - the cluster screen datalogs everything automatically, keeping a history of logs up to a configured quantity. The rectangular displays in the cluster have rotatable options so you can change them to different things using the left touch screen - all configured in the XML and there is a health check page in the touch screen that shows coloured warnings. It also has a real-time clock but as you can see I haven't set the time on it.
A bit of work is still needed on the layout in places because some of the XML is from when I had a slightly smaller touch screen (this new one incidentally being a proper capacitive one so is super responsive and accurate).
WOW, that is amazing work. OEM quality.
Thanks. The one thing that bugs me is the messages on the screens when they initialize. That's the thing that makes it look slightly homebrew. I can control the backlight on the touch screen with a small hardware tweak but I have no control over the cluster screen so can't avoid that green boot message or the hdmi message in the top right corner. I knew I would end up with something like that when I bought the display but sorta had my fingers crossed I could maybe find a way around it. Talking with the supplier though the only solution would be to have them design a custom solution for me which would be too expensive for a one-off.
I've got the same screen, looks like anyways. Wish they just had it black. Looked into brightness control a bit but not sad to hear it's not an option lol... Amazing project!
Have you though about Dakota Digital
Since it’s open source, there might be some way to prevent it from powering the screens until after the initialization messages are gone?
@@shakeorefined2514 It's on the firmware of the screens, the only way I can think of avoiding it without re-flashing the screens controllers firmware it's to delay the backlight on so it will turn on the bl after the messages and such.
nicer refresh rate than I've seen with megasquirt displays.
Amazing work my friend!! You can do what I aspire to be able to, I'd love to have the time and drive to be able to teach myself enough to be able to design completely custom, fully-featured systems like this!!!
HOLY SHID DUDE! THIS IS INSANE!! YOU ARE A GENIUS 😮 Absolute dream setup I'm SO IMPRESSED
Total control. I want that in all my rides. We all should. Well done.
You are paving the way 👏
I must say this is bad azz and very inspirational. Thanks for sharing!
Thanks sharing skill and knowledge on your setup. Very cool work
Wow so cool with minimal expenses
This shit is so cool and when I finish learning how a fucking whole ass ECU works so I can fucking use one then I'll def come back cause this shit gonna be sick as hell
beautiful work sir!!! I'm your 100th like!! I would like to see some vids on how to throw this in more mundane autos AKA not legendary autos like TVR/RUF/Etc. I want to be able to do this on anything.
Thanks for the comment. I've never been liked so much :-) The theory is the same regardless of the car really, assuming a certain age (cars that have analog instruments, and don't already use canbus). For more modern stuff the integration exercise will differ in various ways depending on the tech the car already has on board. What I've done here is to create a layered installation - so there is a hardware integration layer that understands the specifics of how certain sensors work on this car. It pushes out standardized messages to the canbus which the other components are coded to understand. The integration board is relatively generic having several ADC inputs and about 9 voltage sensing inputs. This quantity suits my vehicle but others would have differing needs. A lot of the data you see on the dash comes from the engine management ECU; again there is a device mapping the ECU's data stream to a generic canbus stream that the other modules understand.
excellent job, i really would like to know how to do that lol
Very impressive! Thanks for sharing
Very very inspiring
nice job very well explained thanks
Wow! That looks great!
Very nice project!
Hi, tried this message before but it was deleted? Anyway, great work, truly impressive! So you know I have included a small section of this video in a Speeduino explainer for my channel as an example of just how far you can go with Speeduino as the basis, hope that’s okay. The level of integration using canbus is really impressive and something I’ve really played with but this has inspired me! 👍 great work!
I received your original message via an email notification but when I went to reply to it on youtube it was not there, so I assumed you had removed it. Anyway, I tracked down the video and had a quick look. No objections from me.
@@richmet 👍 (love a TVR btw, I’d sell my soul for a Griffith 500 in yellow!)
Owns a TVR, runs it with a $200 standalone ECU that isnt the easiest to setup lol i love it
I'd agree if you don't enjoy problem solving then pay someone else to install something more mainstream. For what it's worth I did not find it hard to set up but I was not trying to shoehorn it into an existing platform which perhaps made it easier. There are two main reasons I used Speeduino. Firstly I wanted the challenge of doing the conversion. Secondly it is open source; some of the features shown in this video would not have been possible without that - displaying of the fuel, ignition, and afr target maps for example.
My ECU choice was not driven by the value of the car. It was driven by the features I needed and the basic capability to run a V8 in wasted spark/paired, for which Speedy is just fine. The TVR is an old, unsophisticated, thing and it doesn't need the latest and greatest ECU to run it far better than OEM distributor and 2 bank simultaneous injection system it replaces.
@@richmet i mean... cool... its still an exotic witch most people would probably run something pre-assembled by one of the major ecu manufacturers.. not knocking your choice at all, dope to see someone with an exotic using an open source managment system. Personally im looking in to speeduino for a 2 rotor 13b (also not many out there running this setup)
@@richmet did you also share your development with the project since it's open source?
@@TheKitMurkit This project is closed source. It is speeduino that is open source. I shared the changes I made to the speeduino project to make this project possible, but the pull request has not been merged.
Hey would you mind sharing the code for the right hand screen, i want to make something similar for a speeduino through canbus but don’t entirely know where to start
Where can I find some kind of a guide how to do this? Would be awesome for my driftcar build running speeduino!
Are you asking about installing speeduino as well or just the dash part? There are various different ways of installing a dash for Speedy depending on how much time and effort you want to spend. At one end of the scale you can just install an Android tablet and use the RealDash software together with a bluetooth connection for serial data and it'll display a dash for you without any software development. At the other end of the scale is my custom dash which is better integrated than a tablet could ever be, has a much shorter startup time, but obviously requires a lot more effort. The way I get data out of Speedy is via the secondary serial interface (wiki.speeduino.com/en/Secondary_Serial_IO_interface). I have open sourced the headless data logger part of this project as a standalone application (github.com/ric355/SpeedyLogger) which might get you started, but it's a long way from that to installing a canbus and building a dash to display data unfortunately.
@@8SecSleeper the data rate on the ecu is maxed out at about 25hz at the moment as the ecu is open source this can be increased easily. This is a reasonably large data set; about 30 different parameters.
@@8SecSleeper For serial comms the way it works is Speedy will respond at a maximum of once every 32 executions of the main loop. At high load the main loop executes around 800-1000 times per second, resulting in a theoretical data rate of 32-40 Hz but this is reduced somewhat because the serial protocol is request-reply so some of the available time is used up reading the requests. For onboard can it is slightly different - the system will process a CAN command every execution of the loop, but it is not broadcast based so can only respond to the PID requests you make. And of course it depends on the CAN bus speed you use. I have not checked data rates as I don't use CAN (my speedy is a mega). I do have a canbus, but I have a Pi Zero doing the translation from serial to CAN as my speedy is a lowly Mega2560 board. My canbus outside of speedy is 1mbit raw.
Amazing!
well done... significant time investment...
You've done a beautiful job, how have you securely mounted those displays? Very impressive.
A bit hard to describe but I'll give it a go. The screens are held in place using a pair of bezels that are attached to the rear of the fascia. Each screen sits in a recess on the back side of its bezel, and is held in place with clamps. The bezel not only provides a mounting point for the screen but in the case of the large screen it hides the metal edges of it. Bezels and clamps are all 3d printed using ABS. To hold the clamps down I glued bolts (via the bolt head) to the back of the fascia. The clamp goes over the bolt, sticks out over the edge of the screen, and is held down with a nyloc nut and washer. The glue is 2 part epoxy (JB Weld) but the bezels themselves are attached with double sided tape. The clamps hold both the screen in the bezel and have the added effect of holding the bezel down too so there's no way it can move. The key is to get the screens to fit tightly in the bezels without any slack.
Several of the computing devices are also attached to the rear of the screens using custom designed cases and mounts.
Hi Richard. Very interesting project. I wasn't aware of Ultibo and it has really tweaked my interest. I am curious though, what framework did you use to create the dash gauges, layout, and such? Or is it from scratch as well (OpenVG?)? I was disappointed to read that ultibo doesn't seem to have a graphics tool yet.
I built my own application specific framework for it Chris.
@@richmet Yes, I found the SDC site after the fact. :)
Now we'll get people who map while driving, as if texting and driving ain't enough! 😂
Jokes aside, great job!
Hey Richard this is great, can you answer one question I dont see anywhere else, what software are the Pis running? Im researching to do make a custom dash for a Subaru, Reading canbus messages is not hard as the car already has them but all the implementations ive seen have long loading times such as linux and tuner studio, I want something like yours key on... few second... gauges. Is this purely an illusion and the pis are just in sleep mode or is there more? thanks!
I built some custom software that runs directly on the pis instead of running Linux. That's why it's so quick to boot.
@@richmet can you share it?
Hey Richard. Great project. Question - which displays are you using? Thanks,
The smaller one is a 7" capacitive touch bought from Amazon. It's unbranded but can be identified by the four mounting lugs on the top and bottom edges, and is 1024x600 resolution.
The larger one is a 1920x720 12.3" LCD from Ali-express seller 'Wisecoco'. It's the one that has a blue driver board with a semicircle cut out of one end of it. Note that neither of these screens allow programmatic control of brightness. I have engineered auto brightness control for the small display with a mosfet and a light sensor, tapping in to the backlight switch, but there is no equivalent for the large screen.
Nice..
Super
hello did you use Qt to make graphical interface? or what software?
No it's entirely custom built using direct GPU calls.
Nice job. I’ve built something similar using a different method, but still utilizing the arduinos. I have questions to ask you Nice job. I’ve built something similar using a different method, but still utilizing the arduinos. I have questions to ask you, is there anyway I can contact you?
Not sure where you picked the video up from but if you're a speeduino user you can get me on the forum, user ric355, or on the speeduino slack community - you can private message me on either platform.
What type of engine ECU are you using
It's in the video title - Speeduino.
Dude 0o0
i have SOOOO many questions
@@yip5471 this is not uncommon
@@richmet ik ik, i’ve been researching it for awhile (especially for hondas) some people have cracked it but the CAN is pretty hard to crack on 2007 on vehicles
hello can you share how you got the speeduino on canbus connected to the display. thanks
There is some info in the video description
how long did this take to set up and is it easy?
It wasn't a case of taking something that already exists and installing it. I had to create everything from scratch.
Why convert the serial signal to CAN? If you programmed it all yourself, wouldn't it be easier to just deal with the raw data?
There are 5 devices on the network and at least two of them need to be able to see engine data, so it needs to be broadcast since you can't share a serial cable between two devices. This level of abstraction also means flexibility for future changes. The very first device I made was a single unit screen which took the serial data directly. The gauges software can still run in this mode although I do not use it on this vehicle.
Need info pls,
Can you produce a diesel engine map reading?
Speeduino does not work with diesel engines unfortunately.
@@richmet
Thank
So 2 questions. Since i live across the pond in Canada TVR was never available here, but I have heard the jokes on Top Gear about the reliability of them. Did this make it more reliable? And also why is the date on the readout 20 years old? Jan 13, 2000 what the.....?
The video was taken at a point when I had been removing and reinstalling it multiple times. The date is the default date the RTC boots with after a battery is installed i.e. I hadn't set the clock when I took the video.
TVRs are no less reliable than other cars of the same era really. They're mechanically simple but they used old engine technology - the Rover V8 engine was originally a Buick design from the late 50's that had many design improvements over the intervening years, mostly in the heads. Mechanically speaking the difficulty these days is getting good quality parts - most stuff is made to a price in China so it doesn't last as long as it should (alternators, rocker arms, stuff like that). The least reliable part is probably the electronics because the wiring and various control modules are getting old now. Mine was fine; I wasn't looking to improve reliability when I did it - it was just intended to be an interesting technology project.
@@richmet Love it by the way. More skills than I got
Can you tune the car using the touch screen?
No. It is not connected to the tuning interface on the ECU; only to the secondary data interface.
@@richmet OK got you, how much work on top of what you have done would it be to allow tuning?
@@111Vengeance it depends how far you want to go really. Something simplistic just to alter the map is possible but you have to think about how it could be done on a touch screen, and also being able to alter the fuel, spark and afr target maps is not the only tunable aspect of the ecu. There are all sorts of correction curves and other settings that form part of the tune. To be able to alter any and all of it and make it forwards compatible with future speeduino releases would be a massive project. I can't recall if this demo shows it but the left screen constantly runs a rudimentary version of auto tune (but it does not actually alter the map). The results are regularly saved to disk in a file which can be downloaded later. To show where it has tuned it places a second set of ve numbers next to the original ones on the fuel map.
@@richmet thanks for the reply Richard, would it not be possible to just run the mobile version tuner studio app on the device when required?
It's a very impressive effort you've done there!
@@111Vengeance The software running the two screens is entirely custom built. It does not run on Linux, ergo it is not possible to run Linux applications on them. And it's not possible to run the mobile version as that requires Android to be running. What you are seeing running is a "bare metal" application; that means that when you boot the computer, instead of booting a Linux kernel it boots my application as a kernel, so in effect the Pi becomes a single-purpose computer.
I do actually have the Pi's that run the left and right screens configured to dual boot between my application and Linux, and there is a button on the settings page to reboot either device into Linux. So theoretically I could install a desktop and then TS on the linux partition and run it that way, but I didn't think that was spirit the of the original question. And tuning with TS would still require a mouse to be added as the app is not really meant for a touch screen. Also I'd still have to connect one of the Pi's to the tuning interface. At the moment if I want to tune I just plug the laptop in and tune it, but I'm beyond needing to do that very often these days.
Can I buy this from you?
Not at the moment unfortunately.
nice work
"1992 when canbus was a twinkle in some engineers' eye" and they were absolutly right.
call electronic specialized garage you will see how bad canbus is compared to OBD1 and carb.
still need proof ? iight i got you.
what car brand are always in garage for DAYS for electrical problems ? EUROPEAN cars. why ? because they have 3 to 7 time more useless electronics on the canbus than others.
im a mechanic and when i accept modern european PoS , 1 time on 3 i have to send them to the closest electronic specialized garage 340 km away. the customer lose his car from 2 week to almost a year. bmw and mercedes are often sent to junkyard the repair cost is way too high. because even those 500 000$ specialized canbus analyzer cant find the problem after over 3000 hours of tryhard to find the problem. so after 5-8 months here in canada the car is often sent to junkyard ( too hard to sell. people know about it ). cheaper to buy another one if the customer is stupid enought to buy another one. its okey to happen from time to time. its normal.. but when this happen on one car in a batch of 20 , thats extremly high.
i like bmw for thier handling confort and look. but ive owned 2 , still have one as a winter beater ( 2019 328i ) and GOD im done with those. lucky me i have a good ole RELIABLE 1999 dakota v8 5.9 magnum for daily use.
Tbh Just sounds like a diagnostics skill issue but yeah all this oem locked canbus trash is annoying af to deal with, keep plucking at modules till it either stops working or starts working again just to read the hex output and voltages to see where it gave up is tedius but no different to having to strip an engine to find out crank main spun a bearing anyways because timing chain guides broke 😂
Absolutely love this. Is it possible to lazy load the system to get the display on the dashes loaded faster? Kinda like the QT dashboard demo? I'm not scared to get my hands dirty coding. 🧑💻
I have recently implemented some changes that speed the boot time a little more by doing 2 things: Firstly, some of the graphics are now 'load on demand' so that carefully selected images are only read from the SD card when they are needed. This reduces initial boot time by about 1 second. Secondly, I have written an 'image vault' feature. This is a compressed file containing all of the images needed (excluding load on demand images) and it is loaded into memory in a single shot. This makes the loading of all of the other images significantly more efficient. Most of the boot time is waiting for the SD card reads, hence the concentration on the images.
The system uses page definitions in an XML file to define the layouts. I did make some changes to only load the initial page and then load the rest in the background shortly after boot, but for technical reasons related to the way the GPU works this is a complicated piece of work for limited gain: As it stands now, the barrier to getting the cluster to appear sooner is actually the boot time of the right hand large LCD screen. It takes about 4 seconds to boot and that is roughly the same time as the cluster application currently takes to initialise. So getting it any faster is a waste of time right now and that is the most significant reason why I put lazy load on the back burner.
The two screens are actually synchronised at boot but I don't think I had it enabled when I took this video. The left hand screen waits until the right screen has initialised before switching from the boot logo. It is ready much sooner because it has a different xml configuration which has fewer pages and fewer graphics.
@@richmet thank you for your reply. By any chance, do you have a GitHub repository or a Instructable? Something I have also been after is having the ability to load a tune on the fly. Kinda like having the ability to have and eco mode for daily driving and a race mode for track day. With your experience with the speeduino system, do you think this will be possible?
@@jared4670 you don't actually need to have two different tunes for eco and performance. This is because the areas of the fuel and ignition maps for those types of driving are different, so both can be done in a single map. Speeduino does have two fuel maps and they can be switched using an input or blended in several ways (blending is typically done when using ITBs which give a poor manifold pressure signal at idle rpms). Another reason you might want two maps is for different fuel types, but assuming same fuel eco and performance can be done in the same tune.