You'll make a lot of people extremely happy! Go for it.
Newbie to these forums here: Just thought I'd voice an idea myself and a couple of friends came up with to see what you think...
Having read through the software listings in this forum and spent a good few hours Googling, it would appear that the majority of the software available for car PCs is windows based and tends to be a single application that attempts to cover all bases.
While these apps are indeed very good at what they do, they leave no scope to be extended to other aspects of the vehicle or, indeed, for any uses past music, GPS and DVD/video viewing. If you want to do this, you need a full arsenal of little apps and utilities that make using them on the move incredibly dangerous!
I have so far written chunks of software that one way or another ended up being used in, on or around cars such as an ALDL reader (engine diagnostics for GM vehicles), position logging, mobile phone control for GPRS / GSM internet access and so on.
It occurs to me that all of these systems could be quite easily hooked together to provide a coherent, multi-faceted, extensible car-puter that could cover as many bases as the user wanted to impliment.
Take my Nissan Patrol for example. Currently, I listen to music and broadcast radio, make phone calls, use amateur radio, undertake wireless networking surveys (legitimately, I hasten to add!), and use GPS to find my next job.
I'm getting progressively more annoyed by having a standard head-unit for music and broadcast radio; a hands-free car kit with fiddly, almost incomprehensible buttons; a plethora of things to twiddle on my amateur radio rig; a laptop that's bungie-strapped to the centre console with a thumping great lump of coax hanging out the side that makes its way to the 2.4GHz antenna on the roof AND a StreetPilot III GPS unit pirched on the top of the dash.
Being a Linux networking person by trade and having colleagues who work with open-source OSs on a daily basis, we figure that most (if not all) of the above can be replaced with a single machine without having to use propriatory software: Hands up any of you who can truthfully say they've bought a copy of XP specifically for their car installation?
In good old UNIX tradition, we propose to approach the problem by creating multiple chunks of software that does one part of the whole job, but does that part exceedingly well.
Each system within the car (be it GPS, music, network monitoring, amateur radio etc) would be given its own daemon to look after that particular task. GPS and the network discovery is already covered:: GPSd and Kismet-server both trundle along in the background, giving information to whatever client requests it.
Likewise, you could have a music daemon responsible for playing MP3s. Ask it "show me a list of music in this directory" and it would. "Play this file" and it would, the interface having only to pass the most rudimentary of commands to it in order for a relatively complex task to be undertaken.
By decoupling the front- and back-ends of the complete system, you are not tied to having a front end where you really like the interface but the organisation of the songs sucks, or a chunk of navigation software that's great, except it doesn't support your GPS. If you don't like a component, you can change it without having to get rid of the bits you like.
If this is implimented as we invisage with standard network sockets providing client <-> daemon communication, there's nothing to say you can't have the user interface running on a totally different machine to the servers! Anyone can then write either interfaces or daemons while making use of all of the others that are already present and working.
Again in the Linux spirit of things, anything we produce along this line would be released under the GPL and hence would be freely available for general use and modification. Also, any of the protocols we invent would be fully documented to encourage the development of plugins and different UIs etc...
Presently navigation is mobile-Linux's achilees heel, however I'm currently working on that (having borrowed the nav CD from a friend's Audi - the data format is actually well documented if you know where to look!) and so there should be a GPL'd route-planning package available in a reasonable time frame.
As I say, all still vapourware at the moment but it IS going to happen as I'm gonna loose my rag with this car full of toys I have at present!
Comments, criticisms, feature suggestions, "wouldn't it be nice if..." and "someone's already done this, mate" type messages welcomed
You'll make a lot of people extremely happy! Go for it.
The ultimate CarPC - Wow!
Definitelly! I would like to help except I only code in Delphi. Pascal, you know... But other then C++, I am your man
i've been thinking of something like this for a while not, except for one problem.. I could barely "hello world" my way out of a paper bag... if that makes any sense
A while back, I started building components that can be used in a CarPC system. To date, I have made significant progress with this project - GPS Mapping and Routing on Linux
I am also working on a framebuffer based front-end which is completely decoupled from backend engines such as the GPS mapper and OBD interface.
The various components are platform independent with the exception of the frontend which is linux specific (though not hard to port to other systems).
If you would like to join forces, let me know. We can work on different aspects of the Car PC environment. I program backend stuff in C and user interface in C++ (fat-free software). Everything is open source.
Its my belief, that once this projects sourcecode is out on SourceForge, people will start submitting patches.Originally Posted by god_of_cpu
This has been mentioned several times by others including myself. To make everybody happy, there are two camps that would require Open Source applications:
- The Linux camp
- The Windows camp
V.O.I.C.E.S. is developed currently by SilentAdmirer and just getting the Beta together. Although it's not Open Source, it is intended to be contributed to by anyone who can develop in C++. Obviously this would please the Windows camp, but does not help the Linux camp.
06 Volvo XC90
Use to have installed MII 10000/512Mb/40GB, Lilliput 7", OPUS 90W, Wifi-G PCMCIA, Head Unit Aux adapter, Delorme GPS, XM PCR, Audigy NX, RR
Car PC downloads: http://carpc.harteveldt.com/
Thanks everyone for such an animated response already! quite a lot more interest than I anticipated
Firstly, a few specific replies:
mpattonm: as far as I can see, the language any particular module is coded in is effectively immeterial:: as long as it can hold a relatively sane conversation via TCP/IP, you could be writing a gadget in Objective Caml and the rest of the system wouldn't even notice!
god_of_cpu: We looked in quite close detail at the project you suggest and, initially, we thought "Great! Off-the-shelf software to use!", but it appears monolithic in construction - one large Master Control Program with all of the Tron-esque problems that go with it... By abstracting everything from everything else via a network layer, the whole thing is decentralised whilst remaning coherent. There is no specific master and slave relationship - any component can query any other component as they are all stand-alone systems in their own right. Don't like the GUI? Use a different one! Whilst the plug-in / skin model serves an application designed around a specific task very well indeed (XMMS, Photoshop etc) it limits the scope of the application terribly. What if you want to add more / fundamentaly-different functionality to the GUI? You can't do that with a skin or a plug-in. This "system" - or rather group of systems - could theoretically be tweaked to do whatever you want with very little effort, simply by writing glue code or other daemons. Having said that, there's nothing to say a GUI / daemon author couldn't include a plug-in API with which people can extend his/her chunk of code!
sumit_b: That GPS mapper looks brilliant! I'd only been looking at ways of persuading GPSDrive to do what I wanted, something that was proving to be quite a headache... Also, I'd (mistakenly) automatically assumed that any GUI would be based around X, but the framebuffer idea would certainly get shot of a lot of the bloat! Anything that can evict X from the system has to be a good thing!
skippy76: Whilst Linux is my platform of choice, I totally agree that Windows is in dire need of some open software as well. Due to the nature of this design, there is no reason at all why it can't be ported to Windows:: The daemons can be massaged to run as system services whilst the front end can be a standard userland app, the network communication protocols staying as-is. I personally have no real need for a Windows version of this, but I know at least one person I've spoken to who would appreciate it. We shall rule nothing out and hence we may as well envisage Windows / Linux / MacOS support from the start.
Finally to everyone who has offered help - thank you! We are almost certainly going to need it! Such has been the response both here and amongst others that we'll try and get a mailing list set up and a draft spec of the protocols so people can begin to throw ideas into the pot for the core design.
If we can pull this one off I'm sure it'll all be quite a departure from the norm
Thanks once again,