Crankshaft – A GNU/Linux for the Raspberry Pi as an Android Auto headunit(getcrankshaft.com)
getcrankshaft.com
Crankshaft – A GNU/Linux for the Raspberry Pi as an Android Auto headunit
http://getcrankshaft.com/
67 comments
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?
One memorable answer was simply "Of course not." Maybe it's the same guy?
>Maybe it's the same guy?
Of course not. ;-)
Of course not. ;-)
> Bugs? Ideas? Want to help? Think this page sucks? We think so too.
After watching the demo video, this seems to work as well as Android Auto built into many cars.
I've rented probably 8 different cars with Android Auto.. this seems as good.
I've rented probably 8 different cars with Android Auto.. this seems as good.
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.
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 guess so. It runs Android Auto.
But does that mean it's any good?
But does that mean it's any good?
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!
*A medium amount of money
*A medium amount of money
"Official" rpi Touchscreen:
https://www.amazon.com/gp/aw/d/B0153R2A9I/
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...
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...
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.
A battery and something that detects the power has been cut off and does a shut down/standby.
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.
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.
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
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
Pretty sure he's already done that second part.
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
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
If you watch the video, the bootup time of the distro involved is significantly less than one minute - more like 10 seconds in fact.
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.
That's surprising. Seems like it would be easy to inadvertently drain your battery.
Mine too, from 2003. Stupid design, even then.
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.
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:
https://www.autopi.io/hardware-dongle
https://www.autopi.io/hardware-dongle
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.
Do any cars come with DIN slots nowadays? Looks to me like they're all custom-moulded into the dash. Very irritating.
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.
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.
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.
Android Auto is more than just music/audio. It has on-screen navigation, and other driving- friendly features.
It looks like it's built on Rasbian with some binaries and systemd units, so it's not really a custom OS.
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.
Distro's are the new apps, bootable SD cards the new floppies.
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?
This is what I'm actually interested in.
Here's a thread from XDA about the Honda pilot, may be a good place to start perusing
https://forum.xda-developers.com/android/help/heard-2016-hon...
https://forum.xda-developers.com/android/help/heard-2016-hon...
I'm interested in the same use case, it would be great if this is possible!
Perhaps this is obvious but a simpler solution is to just install [1] Android Auto on your Android phone. Does this work on iOS? Of course not.
[1] https://www.android.com/auto/
[1] https://www.android.com/auto/
I do this now and it is not a useful as this project.
I hope projects like this stick around long enough to provide some postmarket support after the manufacturer gives up.
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.
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.
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.
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].
[1] http://www.kenwood-electronics.co.uk/car/nav_mm/carplay-mm/D...
[1] http://www.kenwood-electronics.co.uk/car/nav_mm/carplay-mm/D...
So why would I want to use this instead of just turning Android Auto mode on on my phone?
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.
Cool.
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 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'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.
Comment: I assume that my next car will have Alexa
Question: How is Amazon Auto different from just sticking your phone onto your dash?
Question: How is Amazon Auto different from just sticking your phone onto your dash?
As an aside, it's always nice to see a clean, readable web site like this.
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.
I wonder if this works with any PI display.
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.
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.
Have you used a modern factory touchscreen head unit? They're pretty much unusable without looking either.
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.