At work we once found ourselves in the happy position of having far, far too many applicants for a position. We set a simple test as a high-pass filter. One of the questions was about whether garbage collection removes the risk of a memory leak.
One memorable answer was simply "Of course not." Maybe it's the same guy?
I've got a '16 Honda Civic and a Google Pixel 2. Android Auto works... but it's buggy sometimes. Voice controlled elements frequently freeze everything, and sometimes it refuses to connect. It seems the source of the problem is probably Bluetooth, because turning that off for a moment generally improves things.
Basically, it's totally possible to get Android Auto wrong. I've rented probably 3 different cars with Android Auto and none of them have the problems my personal Civic has.
I guess what I'm getting at is, I'd happily take a reliable, open source implementation of Android Auto in my car over whatever comes in the stock head unit. Would I actually go around hacking firmware in my own car? Honestly it's a possibility.
I'd pay good money* for a system that would package a PiZero, touchscreen, suction cup etc. into a single convenient package that I could plug into the 12v charging point of my car. Especially if it runs Android Auto!
Most cars don’t supply 12v thorough the accessory outlet when the ignition is off, so you’d need some of backup power source. Pis do not cope well with having the power cut off abruptly, so unless you want to carry a spare microSD card around at all times, you’d need some kind of solution for handling shutdowns.
That problem is simply because you're writing to the card continuously.
Make your distro run from RAM and you're fine... that is what most embedded devices do, stick it all in an initramfs.
It's not a big job to wire the detector you're talking about in your first sentence - it's more or less a relay and a capacitor (albeit a big capacitor, or maybe a battery if you put some more wiring and a charger in the circuit)
For the second one... you'd need to maybe consider tapping into the CAN bus and listening for a door unlock event, then powering up off that, and/or stripping everything out of the kernel and services that isn't needed... you could probably get that boot down to 10-15 seconds
I was quite surprised that my 2010 car does provide power through that outlet when it's off. What's your basis for saying _most_? I only have two datapoints myself, so can't generalise.
Android Auto does not need a separate head unit, so I think any 7" tablet with the Play Store would work. Just configure it to tether to your phone when the car turns on.
That's indeed the first thing I thought of. The problem with the Pi0 was that it doesn't have a Display header, so it turned out to be very messy. The 7-inch touchscreen is very big anyway, so the Pi3 actually isn't that big and bulky. I'm sure if ideas like Crankshaft take off, there will be people who make the suction cup structure for you. For now you can buy the touch screen cover for the back, but it doesn't have the suction cup.
PS: If you really hate the bulkiness of the Pi3B, you can try the Pi A+. I haven't tried it because I don't have it, but it should also work.
Give me a decent HUD setup and something that plugs into OBD, and I'm sold, too. I want to have some kind of conky/rainmeter/ubersicht for my dashboard window.
Good HUD is hard. The problem is the length of the lightpath. I've done some experiments with this, your best bet is to place the screen somewhere on the right hand side and project via a mirror onto the windshield. You'll still have to deal with sunlight reflecting off the mirror into the car and you will need a super bright lightsource to be able to use it in daylight. The best solutions end up in front of the firewall to minimize picture distortion.
Available systems in the marketplace seem to suggest that you either need a windshield with special light-filtering properties (as in new Volvos), or you get a separate piece of glass/plastic material to project the HUD onto (every other OEM system I've personally seen). But maybe the light sources simply aren't bright enough.
That separate piece of stuff to project on to is to avoid the ghosting effect you get from a projection reflecting from both the front and the back of the glass/air interface.
I was recently trying to find a solution like this after discovering that my car cannot have an aftermarket radio or hud install without ensuing a whole world of pain. The alternative I landed on though was this:
Well something had to be done. People could buy any head unit they liked. There was even a DIN standard size and connector and they would talk to the car's built in display. Aftermarket units were often far better. How is a dealer meant to sell $MANUFACTURER units with a market like that? (/s, clearly)
I've once left a car that I fully intended to buy because the dealer would not deliver it with a DIN slot. I absolutely hate integrated audio/media/navigation solutions, they always suck and a couple of years down the line nothing will work with them.
Is a whole custom OS really necessary?
Couldn't you just simply use Mopidy(https://www.mopidy.com/)? Possibly with some additional plugins required to make it work for cars.
It runs on RPi and implements mpd protocol, hence, is fully compatible with mpd clients and has many more clients implemented targeting Mopidy itself.
Also, it plays music from Spotify, YouTube, SoundCloud and whatnot.
My reasoning is that it does one thing: Being a dumb head unit. Since it does just that one thing, it can be distributed as a big blob. You don't have to worry about changing that file or this file, following this instruction or that instruction, downloading this version or that version of the packages. It simplifies many things for the end user. I learned that from Retro Pie, a distro that I love.
Power users who want it to do many things can just run/read the scripts in the repo and make it a multi-purpose device. I'd imagine for $100 head unit, many people won't bother.
That being said, I really have to brush up on how to package Qt5 and OpenAuto as Debian packages.
I second this, especially since I have been burned by single-purpose raspberry "distros" multiple times in the past in the audio sector. Maintaince is more work than people often realise.
Does anybody know of any software that implements Android Auto or Apple Car protocols to display content on existing head unit? Maybe something that could run on a Raspberry Pi.
You could try looking into some of the Android forums where they have unlocked the head units and have demonstrated being able to flash custom roms, although may be a bit different from what you're looking.
That does seem interesting. I was looking at whether it was possibly to flash/replace the head unit software if a few years old Camry the other week, but didn't find anything useful. Do you happen to have info on which android forums someone should look in?
Same here. Really disappointed in the lack of communication from Mazda. There is some open source software for the Mazda head unit that runs Android Auto, but nothing on the CarPlay front yet.
Most of the CarPlay specifications are locked behind the MFi program which makes it difficult for an open source solution to exist for it.
I've been wishing for something like this or a standalone unit for CarPlay. It would be amazing if I could just mount something in the CD slot in my car and plug in to the aux jack. I'm sure Apple would have a cow at the idea though.
There are aftermarket radios that support Android Auto/Car Play. Assuming you don't have a weird in-dash radio, you should be able to fit something like this[1].
If you have a small phone then you have a bigger screen. Plus no more having to temporarily mount the phone if you can mount the head unit permanently. I have used a couple of phone holders, they suck and broke after a while. So I often just glance on the phone which sits in the cupholder when I want directions.
I always wanted to go the other way - being able to cast video into my head unit, like a phone. I read that MirrorLink is inherently VNC and USB networking. Does anyone have a MirrorLink «server» stack that can run on a board with OTG?
Can this work somehow as a bluetooth handsfree for a phone?
I've thought about putting a rpi in my dash before, but it always comes down to that single feature that I would miss from the headunit that I'm using now.
I hope it's more full featured than regular Android Auto that is so basic (compared to what is built-in in my Skoda) that enabling it just degrades my "driving experience". The only added benefit is traffic info in Google Maps.
It should. It's a MVP right now, so it doesn't need to achieve many things, and I don't want to make a broad statement. I think having a controlled test environment does help a lot. The official one is cheap and good too, so I don't feel guilty about saying it supports only that.
Thanks for the reply, I'll get the official one then, I asked because the official PI stuff are a bit harder to get via the channels I use, like Amazon, where the price for other displays is also like 1/3 of the official one (maybe they are garbage?). It makes sense to me to start something new with a narrow setup and not many moving parts btw...
This is one area where I kinda hope open source doesn't have much success. OSS seems to struggle with UX and a poor UX in a car unit will get people killed. Simply put, this kind of system needs to function almost entirely without the driver looking at the screen. The demo in the video fails hard at this. Android Auto and CarPlay are only non-nightmarish because the primary control mechanism is voice and they're integrated with steering wheel controls. Even then, they're likely to be too distracting for drivers to avoid accidents.
These kinds of systems need a lot of user testing with sophisticated eye tracking setups before we can feel comfortable letting the masses use them while driving. OSS developers just won't be able to afford that. Once cars are driving themselves, then I can see OSS entertainment units providing value. But as long as a human driver is responsible for not killing all the car's occupants and anyone who might come in (violent) contact with the outside of the car, there should be a high safety bar for these kinds systems and I'm not sure OSS will ever be able to clear that.
In fairness they have big touch buttons and stuff placed in corners so you can quickly locate. The ones on this device are tiny and require visual interpretation to find. And I can’t see this getting steering wheel integration any time soon, so there’s more attention you have to pay it.
Not always. About 50% of the time I need to mess with bluetooth settings on my car because it paired to the wrong device. That involves navigating through at least three menus and hitting small-size buttons on the far side of the screen from the driver.
Humility is a beautiful virtue to see.