This is pretty awesome. Back in the late 90s I ran a 333Mhz Celeron in a little box under the seat of my car, with a parallel port LCD display, as my MP3 player.
I've thought about building something like this, but it just seems like a ton-o-work. This project seems to have maps+camera, no media player yet.
I do run/build a lot of my own stuff (my own web/email server managed via ansible/docker), I run custom Android roms and I do like building things myself, but with the time tradeoff, I just find it easier to get a Pioneer nav/media unit. (Tried the Joyen Android versions for a bit too, but it's difficult to get a good/safe car UI setup in Android).
Those orange gas plasma flat panel displays were my favorite - so perfectly readable and crisp. I went on eBay recently hoping you could just buy one, or even an old "portable" with a monochrome gas plasma, but I had a hard time finding anything.
Wish someone still made these displays, even in just smaller sizes!
I’ve often wondered why there hasn’t been someone that developed a good Android headunit project. What is it about Android that has made it difficult to make a good/safe car UI? Couldn’t one just mimic Android Auto? Or even just run Android Auto?
Well, Android Auto is proprietary as all get-out, it does what Google wants it to do and nothing else. Google is going to decide what it feels is safe to allow you to do for their own liability purposes, and most of that is going to revolve around Google's own apps and services. (Kinda like how Toyota has decided that it's unsafe for me to type in a phone number at more than 2 miles an hour, even though that's insane, and also locks out my ability to dial 911 while driving.)
And you do need a good car UI if you want to use something in your car, a normal phone interface isn't well suited to safe operation in a car. You want large, oversize buttons, large, oversized text, extremely high contrast (basically, throw Material Design out the window), and the key, where relying on random Android apps is going to fail: You want a unified UI across your functions.
A lot of other UI assumptions go out the window in a car, you need people to be able to interact with it, drop what they're doing, and pick it up again later, so you can't have things that time out or assume you are done with them. You ideally want people to be able to touch-feel some controls if possible, but at the least, you want minimal borders so people can aim for the center of a button and probably hit it without looking at it the whole time. Swipe is a complete no-go, you're in a moving vehicle.
So you don't want phone apps that aren't designed for a car really... at all, which removes most of the perks of using an Android.
I'd much rather build my own system that does the basics I need as quickly as possible than try to get a phone OS to be halfway safe in a car. Command line utilities on a Linux box thrown behind a simple UI screen is a pretty easy bet. (I'm running a Windows box, but I condemn myself at my own risk.)
If you're developing for yourself, you can get much further much faster writing simple code purpose-built to do what you want.
If you can abandon the crapware, audible user interfaces are amazing. I designed one for my CarPC in the early 00's. I used a combination of voice commands, a remote control and USB numpad, with feedback from the computer as text to speech and a HUD. I implemented offline mapping and navigation, MP3 and video playing by category/artist/file hierarchy, wardriving (yes I was that guy), ODB-II, and more. Not having to ever look at a control to use it is freeing when you're in the driver's seat.
You can get things like these, you put it on the dash, and stick a slightly darker patch of foil on the window right above it, then it reflects during night and day:
You can but that list is garbage. They just pulled a list off of Amazon so they can spam their affiliate links. Without a hands on review it's hard to know if they're any good.
I have one in my car - pumpkin audio. It does the job great. Talks to my back up cam - smart mirror, and i've written scripts so it takes pictures of the driver at ignition, opens my last spotify track, last google map search etc
The pumpkin audio website isn't super-informative -- do you know where I could find out if their units support my Toyota's backup camera and steering wheel buttons?
After market head units are a slowly dying industry. More and more new cars are coming with infotainment systems so tightly integrated with the rest of the car that they effectively can't be replaced.
I thought the same, but China is pumping out Android-based CANbus-compatible units every day, with factory-compatible fascia/climate controls/wiring harnesses.
Android is still better than everything the manufacturers are pumping out, despite being very obviously for phones.
Even in my 2006 Mazda 3, a 12 year old car, replacing the stereo with a single-din stereo would mean losing easy display of things like my fuel economy statistics and ambient thermostat. If you pull in the CAN bus you can get it back, but that's just another hurdle.
My theory is Android is too difficult to maintain. There is a significant amount of work that has to be done to keep up with the latest version of Android especially if you are going to make heavy modifications to the functionality of the OS. That's why most aftermarket head units don't bother and you get out of date systems with security flaws. It is much better to build a system from scratch like Tesla and most other auto makers do from a support perspective. Android Auto is probably the best of both worlds for most people.
Hah, nice! I did something similar ~20 years ago, but I managed to find a small PC with and on-board RCA connector and hooked it up to a small ~6" CRT TV (I think even black and white). I topped it off with a ring mouse for controlling my music while driving, but I would boot up and open the music player before I started moving.
Great project. Offline mapping is a great feature addition. I'm working on a similar side project using C++ and Qt. I tinkered with Qt maps for a bit, but found it was sucking up too much of my time building a navigation app with all of the necessary features so I scrapped it. I will probably try to integrate an open source mapping app later on to make life easier.
So far, I got music streaming and voice calls working over bluetooth and I'm currently working on cleaning up the UI. I'm also considering upgrading my board to the i.MX8 which recently came out. Next I''m planning on adding an LTE modem, OTA updates and some kind of basic music app.
How do you handle aesthetics? Sounds like a really fun project but a big challenge, at least for me, would be to make it look pretty and not like a Sunday hack.
Hardware is the biggest challenge and what I assume you are asking about. My first approach was to get a double din computer case, which gives you an aftermarket look. The better option is to go to the junk yard and get a stock head unit and replace the internals. The problem here is finding an LCD that fits the dimensions. Another thing I've been thinking about is using a larger LCD that sticks out of the dash like the Tesla Model 3. Downside here is there is no space for physical buttons which I really like.
Agree, creating something nice is challenging, 3d printings may help but I haven't started it yet, waiting to evaluate different screens first.
I've decided not to dismount the car block but using a phone stand modified for my screen.
It's full of ugly cables, the challenging part was to route a cable from the rear of the car to the front :)
Very neat! I'm still relying on my car's built-in display for the camera, so my computer isn't doing maps or the like, but I've got a computer in my car mostly for music and GPS logging, always neat to see what other people are doing!
I don't have a good comprehensive write-up, but the code is here: https://github.com/ocdtrekkie/HAController The README describes the modules which should give you some idea of what it's designed to do. It's built in Visual Basic and also designed to run my home automation system. It is janky and while I wouldn't mind someone else using it, I wouldn't exactly recommend it. :P
In the car, I run an Intel NUC on the floor of my car, and the display I use is an Adafruit serial backpack-based unit (https://learn.adafruit.com/usb-plus-serial-backpack/overview) inside a plastic enclosure along with a small USB hub and the GPS receiver. The enclosure's attached to my dashboard using the same 3M strips available for IPASS/EZPASS devices.
My first question is always "what do you want to do?" What frustrations do you have, what would make your life easier to automate? A lot of times it is less than you think.
> In Part I, I had to patch qtmultimedia for the camera to work, but Qt compilation is ressource hungry, same goes for the osrm compilation, the memory of the Raspberry Pi is too small
I was just thinking about this today. Is it possible to set up an arm VM for “dev” and port the binaries over to the RPI?
With a not insane amount of work you can get a cross compile toolchain up and at least make binaries. Not a lot of packaging systems focus on the cross-compile workflow for package generation though. (I mean there are some, but it's not exactly the standard for fedora or debian.)
Cross compiling is doable and easier with the newer versions of Debian. One Qt issue I had is that a bunch of stuff is dependent upon OpenGL, which wasn't well supported with the Pi stuff when I was poking around at it. Qt is also just a beast to cross-compile.
Rust is much, much nicer to cross compile but lacks a nice GUI. I've been poking at Cursive.rs for TUI stuff in an attempt to hack up my own scan tool so we'll see where that goes.
qemu is capable of emulating an ARM cpu so yes but won't be able to emulate all the real hardware, especially the opengl ES gpu.
From a compilation perspective I believe using a cross compiler is way more efficient than emulating the whole system.
Generally agree that cross-compilation is a better solution, but I think it could also be nice to have everything (except the drivers for your actual hardware) tested as delivered.
Yea I didn't get that either. I have a Python sensor gathering app (LtSense) that uses the gpsd python bindings and it works really well.
I mean if he's targeting one GPS device, this might work fine, but GPS targets a lot of devices with lots of fixes for broken protocol implementations.
Personally I bought a cheap USB GPS device (GlobalSat BU-353-S4) that offers NMEA compliant strings, and I coded off the NMEA spec. I don't think for a personal project it's unreasonable to say "code for spec, and buy a GPS receiver that meets it".
My system is built for a conversational interface, but I don't have voice recognition in place yet. Questions: Why is a Raspberry Pi required? If a Raspberry Pi is required, why does the computer need to be either MacOS or Linux?
Would it be possible to use this to, say, look for a hotword and then just always return the rest of the command to a single program, since I have my own command structure already in play? I need the on-device voice recognition and hotword detection, but not the actual assistant.
Mycroft is again, a whole assistant setup though, I just need a good local voice recognition component. Command processing and TTS are already built-in to my own code. I'm not totally opposed to adding a Raspberry Pi, but since my existing automation code runs on Windows, I at least need something that can talk to a Windows box.
I’m thinking of replacing my 2010 BMW with something... simpler. Since good mechanics don’t exist I need a car I can work on myself. That means probably not much later than 2005. I see that late 90s 4-Runners are cheap now and nice vehicles but miss a lot of the fancy buttons I have become accustomed to. Early 2000s M3s are similarly priced. Both have DIN headunits. This kind of project would really fill that gap for me.
My question has nothing to do with Qt.. GP said it was using Linux, and the kernel is GPL.. so.. are they compliant? Are they releasing any/all modifications they are making to the kernel for booting it on their device?
I've thought about building something like this, but it just seems like a ton-o-work. This project seems to have maps+camera, no media player yet.
I do run/build a lot of my own stuff (my own web/email server managed via ansible/docker), I run custom Android roms and I do like building things myself, but with the time tradeoff, I just find it easier to get a Pioneer nav/media unit. (Tried the Joyen Android versions for a bit too, but it's difficult to get a good/safe car UI setup in Android).