Hello,
I accidently came across the beagleboard project website and instantly an idea
of the implementation of my ancient dream crossed my mind. Ever since I got
myself a car I was wondering on unifying all the computer-like entities inside
in a single device, providing an unseen level of customization, scalability,
logical unity and central control over all the «electronical» stuff aboard.
What I am seeking to accomplish is building an open modular system for the
carputer software. While some of the software just needs to run similar to how
they work on PCs (e.g. web-browser), others may benefit much more from being
tied in a framework utilizing rich input data source (OBD bus, cameras,
touchscreen, voice control, conventional input sources, panel buttons, GPS
data, maps, bluetooth, internet, radio etc etc) and multiple output options
depending on driver needs. I mean something akin to what JACK is to sound but
more complex due to heterogenous data nature. I want to build a whole
architecture which can prove useful for vehicle software development and that
should have some sort of hardware to be built upon.
Beagleboard looks very attractive as a base for such a project because:
• The heat production and power consumption are ultra low as well as the size
allowing to utilize the standard 1-DIN case.
• OpenGL can allow for rich end user interface and [on a looooooong run ofc]
for expanding the output to some sort of HUDs.
• It already hosts a variety of connectivity opportunities while others are
easy to implement.
• DSP can prove useful due to big amounts of multimedia playback requires as
well as processing camera signals, speech recognition, voice control etc.
I browsed the projects page and found 3 projects concerning the deployment of
carputers on BeagleBoard but they seemed to be stillborn and moreover did not
quite grasp the idea being focused on a traditional navigator+mulitimedia
system bundle.
The last reason is the also my main point of discontent with commercially and
opensource carputer solutions which inevitably are reaching in either shell-
based in-vehicle-infotainment or your-ordinary-os-on-the-small-screen
direction rather than providing an extendable framework on which additional
software may be built upon.
Can somebody tell if such a project has a future within summer of code program
or just per se?
Using the Beagleboard as an on-board computer is a great idea indeed.
Couple of points for this type of project:
1. You'd need a filtered 12V to 5V power supply to protect from power
spikes. In case of trying it out in a vehicle with MOST bus, since
these vehicles have constant 12V you'd need to adapt a power
management solution to recognise when the Beagleboard should go to
stand-by/shutdown.
2. Do you want Beagleboard to be a 1DIN kit that connects to an i.e.
Xenarc LCD or would it better if it was a 2DIN solution? If its 2DIN,
you could simply use an existing 7 inch touch screen for Beagleboard
and then build a plastic 2DIN chassis for that all-factory look making
it a much nicer design. If you want to use Beagleboard as add-on to a
7inch VGA monitor, you'd still need to get an active HDMI->VGA
converter which means an extra box and also another power supply for
the converter box.
3. Which OS do you want to run in your car? Although you can find
several software solutions for a Linux/Windows my opinion on this is
that it would be great to expand XBMC with a skin that is easy to use
for vehicular use. Another possibility is to develop a UI using Qt or
use Android and generate a UI with Flash.
Using Beagleboard to build your own vehicle on-board computer would be
a nice effort and I agree with you that there are several application
areas that can be explored.
Thanks for the reply!
In case of trying it out in a vehicle with MOST bus, since
these vehicles have constant 12V you'd need to adapt a power
management solution to recognise when the Beagleboard should go to
stand-by/shutdown.
Well, I guess my current car was made before the advent of MOST bus thus I
wasn't really aware of it, this calls for a little research for the sake of
the solutions repeatability.
2. Do you want Beagleboard to be a 1DIN kit that connects to an i.e.
Xenarc LCD or would it better if it was a 2DIN solution? If its 2DIN,
you could simply use an existing 7 inch touch screen for Beagleboard
and then build a plastic 2DIN chassis for that all-factory look making
it a much nicer design. If you want to use Beagleboard as add-on to a
7inch VGA monitor, you'd still need to get an active HDMI->VGA
converter which means an extra box and also another power supply for
the converter box.
I personally would stay away from 2DIN because in my point of view, having a
dashboard display neither really serves the informational purpose nor does
provide a convenient passenger entertainment display. My current thinking is
reusing a 1DIN case from a used (pref. broken) audio head unit along with its
detachable panel for the start, utilizing the UI and sound amplifier, with
displays attached being a flexible option. I thought beaglebox offered
multiple ways of connecting to a display, including USB one which for now I
like the most, however this may be because I little better at software than
hardware.
I have some bits here and there on reprogramming the detachable panels to work
as a composite USB HID device offering standard USB interface to alphanumeric
display, sound(volume,positining, mixer etc) control and it's keyboard [0].
This would cut the costs and maintain repeatability of the setup, while it may
be interesting to manufacture an UI panel of our own. I can't decide yet, but
the first option is a safe start anyways.
3. Which OS do you want to run in your car? Although you can find
several software solutions for a Linux/Windows my opinion on this is
that it would be great to expand XBMC with a skin that is easy to use
for vehicular use. Another possibility is to develop a UI using Qt or
use Android and generate a UI with Flash.
My current thinking is rather to provide more of an architecture of
interprocess object-oriented exchange of data and control in a vehicle, than
to build a conventional mediacenter+navigator+sensors_display bundle, however
that still includes the media needs and XBMC seems a good candidate for that
part. I think of making the core library graphic-independent (for instance
allowing displayless operation having only an alphanumeric string on the face
plate as output) with links to different potential displaying modes (monitors,
HUD, eyewear, oh the future 
). For a monitor enabled setup an stripped X
Window server with some basic apps like a browser and said media center seems
logical though, it's just not that I'd focus myself on just running X inside a
car for that's already very easy I guess and not worth the challenge, or am I
wrong? For the UI for my custom app bundle using the aforementioned API, I'd
stick with Qt+OpenGL pair.
[0] ISC
(Russian)
Hello,
I accidently came across the beagleboard project website and
instantly an idea of the implementation of my ancient dream
crossed my mind. Ever since I got myself a car I was
wondering on unifying all the computer-like entities inside
in a single device, providing an unseen level of
customization, scalability, logical unity and central control
over all the «electronical» stuff aboard.
What I am seeking to accomplish is building an open modular
system for the carputer software. While some of the software
just needs to run similar to how they work on PCs (e.g.
web-browser), others may benefit much more from being tied in
a framework utilizing rich input data source (OBD bus,
cameras, touchscreen, voice control, conventional input
sources, panel buttons, GPS data, maps, bluetooth, internet,
radio etc etc) and multiple output options depending on
Are you suggesting having an audio mixer and keeping some form of
a normal radio with line out? Do most cars have that much space
to mount a 1DIN CarPC + a normal radio? Given how small the
beagle board is compared to 1DIN, prehaps integrating a AM/FM
tuner in the same 1DIN along with a power amp to drive speakers?
Are you suggesting having an audio mixer and keeping some form of
a normal radio with line out?
Well, I flaw a bit on the exact details by now, but I guess I don't need the
mixer, just the amplifier and probably radio.
Given how small the
beagle board is compared to 1DIN, prehaps integrating a AM/FM
tuner in the same 1DIN along with a power amp to drive speakers?
Yes, you probably got it correctly. One 1DIN case to host the amplifier,
radio, beagleboard, its power adaptor, utilitary wiring and some additional
stuff. I think there should be enough place for all this.
are you going into the engine management as well? I was thinking about converting my sand rail to fuel injection because I’m putting a turbo on it and carbs suck for turbos. I entertained the idea of a Beagle ignition/fuel control system. There’s already an open source solution for code example somewhere based on freescale.
Mark
I'm afraid we're about different car computers here. My primary idea is to
concentrate all the informational, control and enternainment electrics in one
device, which is a carputer, replacing the whole audio+navigator+[insert 4
more devices you use here] stack while engine controls depend on ECU. ECU
provides an OBD2 (or similar) interface, therefore a carputer may gain
indirect control over some of that kitchen which is going to be the case (I
plan on making a convenient OBD2 library API as well), but still it's the
other computer. Making a Beagle based ECU sounds interesting but is out of the
scope of the project. I also think that those devices should be kept separate
for safety measures.
I thought so but thought I would mention it anyway. I did an arduino project reading obd2 using elm chip from a scanner. They are handy for handling the different protocols.
What became with the data after that, where was it fed after being read?
I would say the project has great potential if you can build the
software right. Don't think of it as an addon for a vehicle. Think
of it 'being' the HMI for the all vehicles. Then what would that
person 'driver' want? An IVI, Cluster, and multiple headrest monitors
for passengers. Easiest way I can think to do this is a Beagleboard
for each display. The IVI should have AM/FM/HD radio, check SiLabs,
plus GPS and a hard drive of some type, Wifi and Bluetooth with all
profiles and a Dual-Array Mic for voice control and Phone call use.
The Cluster should have CAN input and link back to the IVI. Each
Headrest should have RF audio output for use with wireless headphones
and too link back to the IVI unit as it is the media storage unit.
USB 3.0 might be your fastest route of linking together all units. TI
just started to get into USB and did so with USB 3.0 hub chips.
Lastly make the IVI unit able to use a few different sizes of LCD
panels. Not everyone has the same idea of a Center Stack. All minus
the Cluster need to be Touchscreen.
Software. Needs to be very flexible, Full 3D ability. Swiping gauges
for the cluster, Sliders for the EQ. Also think, some people will not
want A/C controls, others will, so some type of Relay board might be
needed, let those make their own "plugin" to control that additional
board. Same goes for cameras. To fit most every idea of use for
cameras you would have to support about 7 units, round that to 8 and
you should be safe (think Vehicle Blackbox and LDWS 'Lane Departure
Warning System').. And so on....
The idea has great potential, it will hang on how to link the
different pieces together and how friendly you make the software...
Take a look at QNX Automotive...
Mike
I would say the project has great potential if you can build the
software right. Don't think of it as an addon for a vehicle. Think
of it 'being' the HMI for the all vehicles.
Precisely this. I'm sick of idea carputers only serving some small purpose, I
want it to be an extension of automobile controls.
Easiest way I can think to do this is a Beagleboard
for each display.
One XServer handling them all at once. Should be enough.
The IVI should have AM/FM/HD radio
check
plus GPS
check
and a hard drive of some type
flash card rather or SSD but still
Wifi and Bluetooth with all profiles
check
and a Dual-Array Mic for voice control and Phone call use.
check
Lastly make the IVI unit able to use a few different sizes of LCD
panels. Not everyone has the same idea of a Center Stack.
Flexible with LCD at all. It's all X. You plug whatever you want, you may not
even plug a thing if you don't feel like, it still works.
Software. Needs to be very flexible, Full 3D ability. Swiping gauges
for the cluster, Sliders for the EQ.
My point is: provide API to interconnect logic and UI and make a hard split
between them. You want 3D? Here you have it. You want not, just plain
interface or without graphics at all? Still the same software stack works for
it.
Also think, some people will not
want A/C controls, others will, so some type of Relay board might be
needed, let those make their own "plugin" to control that additional
board.
Everything is modular thanks to API and nothing is set in stone like
commercial analogues, full open-source y'know.
Same goes for cameras. To fit most every idea of use for
cameras you would have to support about 7 units, round that to 8 and
you should be safe (think Vehicle Blackbox and LDWS 'Lane Departure
Warning System').. And so on....
Can support any number of them in any role. The user just installs a camera
and configures a way he'd want to us it as. The API handles everything again.
Ooh ooh, ooh how about this. …
The communications between the master control and components can use zigbee? Modules can be manufacturered for various devices to include them to the system. Only wiring requires 12v from somewhere in the vehicle.
The master control beagle can be embedded into a tablet screen module that is a detachment face off the dash. When it is docked in the dash, its battery is charging and also connected to other devices that require hard wiring.
Does TI produce a Zigbee SOC? Devices that are usb like webcams could be plugged into a zigbee module that would provide it 5v and handle the video stream?
Mark
Ooh ooh, ooh how about this. ..
The communications between the master control and components can use
zigbee? Modules can be manufacturered for various devices to include them
to the system. Only wiring requires 12v from somewhere in the vehicle.
That sounds cool as in coolness, but for statically linked components I can't
justify for myself the use of wireless link, wasting more energy than a
conventional cable, and I guess I'm not alone at this. Still it is an
interesting concept for longer vehicles, like, say, trucks or vehicles with
detachable rear parts as we only need to hook to power cable then but not any
additional wiring. Would vote yes for the support of such a feature, but doubt
I'd need it to be used in my own lil' car.
The master control beagle can be embedded into a tablet screen module that
is a detachment face off the dash. When it is docked in the dash, its
battery is charging and also connected to other devices that require hard
wiring.
Oh, I thought it's rather think to serve as a detachment plate, but a nice
idea indeed.
Quoting Oleksiy Protas <elfy.ua@gmail.com>:
Huh, I did think their consumption is ultralow, but being this low amazes me.
Still, I was merely applying Occam's razor here, as wireless signal will
probably always waste more energy due to lack of directedness compared to a
conventional wire, and waste is translated into fuel sooner or later. I'm not
against the idea though, just pointing out that it may be an alternative in
cases when wiring is unavailable.
I think its similar to a car alarm key chain. Mine has a watch battery and I changed it twice in the 6 years I had my truck.
That's a point, but an alarm key only has to transmit little pulses, not to
stream data like, say, a rear view camera.
The camera would still require a power source regardless if it was wireless or hard wired. If it was powered from a 12v wired from the vehicle, or only needed one wire for the power, as the gnd would just be from a metal part of the vehicle, wouldnt it being wireless eliminate issues of having a long shielded cable trying to block noise interface in data transmission?