Continuation of the previous post, which was the equivalent, but for hardware. The finale of this post and the last one is that I ended up using Android for my in-car system (as opposed to some base version of Linux)…in fact, I’d say you need not read any further: it’s mostly just babble. It’s actually a bit Troll-ey to be honest.

Software

Android

PROS

• Out-of-the-box touch-based OS for small screens (i.e pretty much perfect for the job)
• I’ve found BTSSM which shows the ECU data for me from the car’s ODB2 port (via USB). Further down the line hopefully TorquePro, but Torque Pro and two OBD2 port adapters I have just do not want to talk and be friends (Queue Hug ;)).

•  
• I get how to do Android -to- Arduino comms stuff, so I can get at external switches and sensors and stuff – there are some ports from the old system I plan to wire into
• Loads of apps: Android Auto, Maps etc and I’m relatively proficient in Android/ Java dev so I can tailor my own stuff. And they all are of the same look, and designed for touch.

CONS

• Android not that slick running on a Raspberry Pi 3 whatever way you go – I think it boils down mainly to memory and  CPU/GPU processors, but maybe in part (and hand-in-hand with) optimisations that big phone/hardware companies can exploit but man (or woman) in his (or her) garage do not have the resources to explore:
  • There’s Google’s own Android Things but that does not have a UI, in the Android home screen sense. I think you could make it work, but (lots of extra) work is the salient point. This tutorial has code for a rough-and-ready ‘launcher’, or you could install APK for a 3rd party launcher but I feel you’d keep coming up against hurdles – as described here.  I wish Google would do a full-tilt version of Android for Raspberry Pi that you could take things out of to get Things, rather than vice-versa.
  • There was RTAndroid. Its now transitioned to a freemium kind of model, Emteria OS. Good on them I say. I have been working with the free version. Bar a couple of features and a banner on the bottom of the screen reminding you that the world cannot be free, its the same as the full version. It also reboots every 8 hours…think you’d struggle to drive in New Zealand and not drive into the sea, or end up where you started.
  • I literally just found this free: LineageOS (previously the now-defunct CyanogenMod) build for Raspberry Pi 3…by a man (or woman), KonstaT, probably in a garage, maybe in Finland. I will at some stage try this to compare it with Emteria, in particular, the boot time.
• Input from external hardware (the ‘comms stuff’ I was so confident on in the PROS) became more convoluted than I’d hoped*

* Bit of a surprisingly one: I had planned not to bother setting up an Arduino as a proper -bespoke’ USB device. FYI the Arduino is the bit in the system taking in info from external sensors, the hard-buttons in the centre dash etc. Instead, I had planned to just use an Arduino Leonardo as an HID keyboard as a short-cut.

The keyboard plan was: buttons and sensor signals come into the Arduino and my Arduino code sends this to the Android device just as a regular keypress (or series of them). As far as Android is concerned it’s just key presses from an external USB keyboard. The hick-up here is that it is not possible (or let’s say ‘it is not straightforward’) to run a background service on Android and listen for USB plugin keyboard key presses: onKeyDown in a service? (Global Hot Keys).

I think there are some (convoluted) ways to get around it, there seem to be a few posts and apps that by use the Accessibility API and keyboard maps and blah blah blah…easier to forget the idea and just make the Arduino my own bespoke USB device – then I can do as I wish.

Of course my ‘I think there is a way round it‘ has ABSOLUTELY NO VALUE OR GROUNDING WHATSOEVER against the word of Romain Guy. But that fact I can write it unchallenged (until it’s done and I say “I told you so”) is the beauty of this, the backstreets of the internet blogosphere.

Linux – as a distro running on a Raspberry Pi3

PROS

I struggle to find any pros with this really. Pain in the arse. It would just be shit.

CONS

Lots I can think of:

• Is there a touch-friendly Linux UI? Is everything you run in that UI going to adhere to the same UI design language? Quick answer: no to both of those I think (well I have not found one) if you are planning on using Raspbian as the OS.
• There is a for-a-car version of Kodi which might have been an option (running on Raspbian) – that’s probably the way I would have gone had I not gone with Android and Emteria OS. Kodi plug-ins are written in Python which I’d quite happily re-visit.

• Or you could create your own ‘in-car OS’ running in and on top of Raspbian, like these guys/gals at I-carus seem to have done.

ECU info

This is what put the brakes on me going any further down the Linux-based system road. I bought a K-LINE VAG USB cable off eBay and found that although it did not work with Torque pro’s SSM2 beta (Android) it did work with FreeSSM on a Windows PC- SSM is Subaru Select Monitor, Subaru’s own special blend of ODBII.

I found a guy, Nikolay Marinov, who presented a video of how he had been working on all sort of magic to get FreeSSM going on raspberry pi and modified the UI to be a little more touch-friendly. A YouTube vid of him presenting it at some OpenFest conference in Bulgaria is below:

He also talks about plugins that runs a little server in the background so you can poll FreeSSM for info from other programs. Despite this, his fork on GitHub of the FreeSSM has just remained as per the main branch. I emailed him and messaged him a couple of times but never heard from him.

That was a while ago and it since looks now like he and the guy who maintains FreeSSM have been communicating with the latter wanting to review changes to code prior to merging it,

Anyway. FreeSSM uses QT, which is a cross-platform GUI system for C++ developed my Nokia. Some big players use it in some big applications, including Tesla in on their in-car screens I did get FreeSSM going on raspi – you have to jump through a through hurdles to get QT running (http://www.qtrpi.com/)