[GSoC idea] CarPC projects
Oleksiy Protas
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?
--
Oleksiy Protas
National University «Kyiv-Mohyla Academy»
This message is signed. You can obtain a public key to verify it here:
http://minsky.surfnet.nl:11371/pks/lookup?op=get&search=0x81B636D4F015B7EC
Post Scriptum:
Never be led astray onto the path of virtue.
Anthony Kavassis
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.
Oleksiy Protas
On Sunday, March 13, 2011 01:28:37 pm Anthony Kavassis wrote:
> 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] http://stanson.ch/index.php?page=proj&proj=02-AutomotivePC-FrontPanel
(Russian)
--
Oleksiy Protas
National University «Kyiv-Mohyla Academy»
This message is signed. You can obtain a public key to verify it here:
http://minsky.surfnet.nl:11371/pks/lookup?op=get&search=0x81B636D4F015B7EC
Post Scriptum:
Don't go surfing in South Dakota for a while.
Hunyue Yau
> 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?
--
Hunyue Yau
http://www.hy-research.com/
Oleksiy Protas
> Are you suggesting having an audio mixer and keeping some form of
> a normal radio with line out?
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.
--
Oleksiy Protas
National University «Kyiv-Mohyla Academy»
This message is signed. You can obtain a public key to verify it here:
http://minsky.surfnet.nl:11371/pks/lookup?op=get&search=0x81B636D4F015B7EC
Post Scriptum:
Q: Why do ducks have big flat feet?
A: To stamp out forest fires.
Q: Why do elephants have big flat feet?
A: To stamp out flaming ducks.
mark hubrich
Mark
Oleksiy Protas
> 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
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.
--
Oleksiy Protas
National University «Kyiv-Mohyla Academy»
This message is signed. You can obtain a public key to verify it here:
http://minsky.surfnet.nl:11371/pks/lookup?op=get&search=0x81B636D4F015B7EC
Post Scriptum:
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"
mark hubrich
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.
On Mar 14, 2011 4:56 AM, "Oleksiy Protas" <elfy.ua@gmail.com> wrote:On Monday, March 14, 2011 05:57:35 am mark hubrich wrote: > are you going into the engine management...
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.
--
Oleksiy Protas National University «Kyiv-Mohyla Academy» This message is signed. You can obtain a pu...
Oleksiy Protas
> 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.
--
Oleksiy Protas
National University «Kyiv-Mohyla Academy»
http://minsky.surfnet.nl:11371/pks/lookup?op=get&search=0x81B636D4F015B7EC
Post Scriptum:
Stay away from flying saucers today.
mark hubrich
The details are here. ..
http://www.practicalarduino.com/projects/vehicle-telemetry-platform
On Mar 14, 2011 9:03 AM, "Oleksiy Protas" <elfy.ua@gmail.com> wrote:On Monday, March 14, 2011 12:54:49 pm mark hubrich wrote: > I thought so but thought I would mention...
What became with the data after that, where was it fed after being read?
--
Oleksiy Protas National University «Kyiv-Mohyla Academy»
This message is signed. You can obtain a public key to verify it here: http://minsky.surfnet.nl:1137...
Oleksiy Protas
On 14 March 2011 17:24, mark hubrich <meis...@gmail.com> wrote:
> The details are here. ..
>
> http://www.practicalarduino.com/projects/vehicle-telemetry-platform
>
> On Mar 14, 2011 9:03 AM, "Oleksiy Protas" <elf...@gmail.com> wrote:
>
> On Monday, March 14, 2011 12:54:49 pm mark hubrich wrote: > I thought so but
> thought I would mention...
>
> What became with the data after that, where was it fed after being read?
> --
>
> Oleksiy Protas National University «Kyiv-Mohyla Academy»
>
> This message is signed. You can obtain a public key to verify it here:
> http://minsky.surfnet.nl:1137...
>
> Stay away from flying saucers today.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Beagle Board" group.
> To post to this group, send email to beagl...@googlegroups.com.
> To unsubscribe from this group, send email to
> beagleboard...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/beagleboard?hl=en.
>
--
Oleksiy Protas
National University «Kyiv-Mohyla Academy»
Institute of Molecular Biology and Genetics, Ukraine
Dashboard
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
Oleksiy Protas
> 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.
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.
--
Oleksiy Protas
National University «Kyiv-Mohyla Academy»
This message is signed. You can obtain a public key to verify it here:
http://minsky.surfnet.nl:11371/pks/lookup?op=get&search=0x81B636D4F015B7EC
Post Scriptum:
Good day to deal with people in high places; particularly lonely stewardesses.
mark hubrich
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
On Mar 15, 2011 11:49 AM, "Oleksiy Protas" <elfy.ua@gmail.com> wrote:On Tuesday, March 15, 2011 05:54:39 pm Dashboard wrote: > I would say the project has great potentia...
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 th...
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...
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 mi...
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 ab...
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.
-- Oleksiy Protas National University «Kyiv-Mohyla Academy» This message is signed. You can obtain...
Oleksiy Protas
> 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.
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.
--
Oleksiy Protas
National University «Kyiv-Mohyla Academy»
This message is signed. You can obtain a public key to verify it here:
http://minsky.surfnet.nl:11371/pks/lookup?op=get&search=0x81B636D4F015B7EC
Post Scriptum:
Q: How many supply-siders does it take to change a light bulb?
A: None. The darkness will cause the light bulb to change by itself.
dave higton
> On Wednesday, March 16, 2011 01:43:49 pm mark hubrich wrote:
> > 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
I suspect you don't realise just how little energy Zigbee consumes.
Less than the unit-to-unit variation in consumption of BeagleBoards.
Dave
Oleksiy Protas
> I suspect you don't realise just how little energy Zigbee consumes.
> Less than the unit-to-unit variation in consumption of BeagleBoards.
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.
--
Oleksiy Protas
National University «Kyiv-Mohyla Academy»
This message is signed. You can obtain a public key to verify it here:
http://minsky.surfnet.nl:11371/pks/lookup?op=get&search=0x81B636D4F015B7EC
Post Scriptum:
Tonight you will pay the wages of sin; Don't forget to leave a tip.
mark hubrich
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.
On Mar 17, 2011 11:25 AM, "Oleksiy Protas" <elfy.ua@gmail.com> wrote:On Thursday, March 17, 2011 10:04:33 am dave higton wrote: > I suspect you don't realise just how li...
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.
-- Oleksiy Protas National University «Kyiv-Mohyla Academy» This message is signed. You can obtain...
Oleksiy Protas
> 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.
stream data like, say, a rear view camera.
--
Oleksiy Protas
National University «Kyiv-Mohyla Academy»
http://minsky.surfnet.nl:11371/pks/lookup?op=get&search=0x81B636D4F015B7EC
Post Scriptum:
Q: What do you call a WASP who doesn't work for his father, isn't a
lawyer, and believes in social causes?
A: A failure.
mark hubrich
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?
On Mar 17, 2011 12:07 PM, "Oleksiy Protas" <elfy.ua@gmail.com> wrote:On Thursday, March 17, 2011 07:01:29 pm mark hubrich wrote: > I think its similar to a car alarm key...
That's a point, but an alarm key only has to transmit little pulses, not to
stream data like, say, a rear view camera.
-- Oleksiy Protas National University «Kyiv-Mohyla Academy»
This message is signed. You can obtain a public key to verify it here: http://minsky.surfnet.nl:1137...
Oleksiy Protas
> 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
sources.
> wouldnt it being wireless eliminate issues of having
> a long shielded cable trying to block noise interface in data
> transmission?
I still think that the answer to this question depends on individual case. I
might be conservative but I don't see why use wireless when a stationary cable
would do. Although whereas fighting noise becomes relevant, wireless is
invaluable. Hence, I'm all up for supporting both options, even though I may
not have the motive to use wireless communications in my own car.
On a side note, can anyone confirm that BeagleBoard was not accepted to GSoC
this year?
--
Oleksiy Protas
National University «Kyiv-Mohyla Academy»
This message is signed. You can obtain a public key to verify it here:
http://minsky.surfnet.nl:11371/pks/lookup?op=get&search=0x81B636D4F015B7EC
Post Scriptum:
You will be Told about it Tomorrow. Go Home and Prepare Thyself.
