Crankshaft – A GNU/Linux for the Raspberry Pi as an Android Auto headunit
getcrankshaft.com
getcrankshaft.com
Humility is a beautiful virtue to see.
One memorable answer was simply "Of course not." Maybe it's the same guy?
Of course not. ;-)
I've rented probably 8 different cars with Android Auto.. this seems as good.
But does that mean it's any good?
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.
*A medium amount of money
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.
Case for pi and touchscreen: https://www.amazon.com/gp/aw/d/B01HV97F64/
Suction cup: https://www.amazon.com/gp/aw/d/B076XZ9JN7/
Car charger: https://www.amazon.com/gp/aw/d/B00ISGCAJM/
Might require a little finagling...
Rpi startup takes a little while, so I don't know how nice it would be to wait 1 minute for your android auto system to startup.
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
The linked "features demo" video on youtube shows it booting into the Crankshaft app from power on (through Rasbian Lite) in ~11 seconds.
https://www.youtube.com/watch?v=tFEpfuDBDjM&feature=youtu.be
Even with noatime?
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.
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.
https://forum.xda-developers.com/android/help/heard-2016-hon...
I've been waiting far too long for Mazda to ship their promised CarPlay update and I'm wondering how I might take matters into my own hands.
Most of the CarPlay specifications are locked behind the MFi program which makes it difficult for an open source solution to exist for it.
[1] http://www.kenwood-electronics.co.uk/car/nav_mm/carplay-mm/D...
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?
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.
Question: How is Amazon Auto different from just sticking your phone onto your dash?
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.