Saturday, November 23, 2013

Initial SW Testing

So a while back, I decided to test the client/server approach to the CarHUD with a simple server that just responded to the GUI client with random numbers.  (I've been working on code and figuring other stuff out, I know, I should be posting what I'm doing)  What I found was quite annoying.

It didn't work as well as I planned.

This happens in the Engineering world all the time.  It's also why you do iterative testing throughout the design/build of your idea.

So what ultimately happened?  The jsocket class I found and was using wasn't as responsive with the pygame GUI when I went from test code to actually trying to get everything talking to the car via the OBD-II device.  There was also issues in getting everything working on bootup in the CarHUD OS.

I changed my method and added a threading feature to my ELM-327 library, this is in a separate branch in my bitbucket repo.  The goal here is to establish the device within the pygame GUI and run that thread separately and use the Python Queue module to transfer data between the ELM-327 thread and the pygame thread.

I had attempted to test this, but it got cold where I live and I inadvertently blew a fuse in my car.  Didn't know the seat heater was tied to the cigarette lighter circuit.  Got a replacement fuse and some fuses for the old dvd player system that I'm using for a monitor (since I disassembled mine).  Got the wrong size fuses for the dvd player...

Once I get a new set of smaller sized fuses for that cigarette lighter adapter, I'll be able to test again.  Hopefully I can try that out tomorrow.

In other news, I've started another bitbucket repo for the CarHUD layer in Yocto.  It isn't complete and I'm still trying to figure out how to get it work without modding or forking the Raspberry Pi layer.

Holidays are coming up and I'll be busy with those.  If I get time and some results, I'll post them.

Friday, October 11, 2013

All Quiet on the Western Front

Hopefully you all haven't begun to think I've forgotten the blog.  In fact, it's been a crazy couple of weeks (or months, I've lost track).

So what is going on with the CarHUD.  I'll tell you while the people who live diagonally from me are having a small domestic dispute.  Such fun for them at a 9:25pm.

While I was off on my whirl wind travel across the US and craziness at work, I have been thinking about the projector stuff and wondering why my Yocto build attempts kept failing.  The wondering caused more thinking and more thinking caused me to need a slight break and I had to throw down some Halo 4 action on Legendary to bring myself back to reality.

I've also been spending an excessive amount of time Chromecasting The Ben Heck Show from my GTab 2 to the TV.  I did get my daughter excited for the show, but not enough yet to sway her from being a Doctor/Nurse/Rescue Helicopter Pilot.  She's 5 so I have some time.

I won't bore you with the Yocto issues, but I was trying to run my normal build and the system was throwing an error because a file didn't have a license variable set.  Ultimately the file doesn't need a license file variable as it's actually a file that is used to create a build image.  I was testing an attempt at corralling all my changes to my build environment so it will be easy for you all to build this when I'm done.  Will have to work on that later.

On to the projector stuff since I did bore you with details about the Yocto issue.

I'm dead set on those 8x8 LED Matrices from AdaFruit, but they're out of stock and I didn't get any for my birthday like I kinda hoped I would.  But I did get some other parts (thanks to Element14) that were cheaper and would allow me to figure out some of the GPIO stuff on the Pi.  I got 3 momentary SPST switches that will control LED brightness (up/down) and one for LED Matrix mode (all LEDs on, Alternating On/Off, etc).  I also got the MicroSD card adapter and a 26pin extender to solder onto my peripheral component circuit board, and some 10k resistors.  This board will interface with all the other stuff LED Control buttons, the SparkFun OBD-II UART Circuit board (also didn't get), and the LED I2C devices with an 3.5VDC to 5VDC level shifter.

The level shifter is a new addition to the design because, in my research (you should always research) I found that a single 5VDC I2C device with the RPi is ok, but if you add additional devices, it could cause issues.  So, to alleviate those issues, I need to get one of these bad boys: https://www.adafruit.com/products/757.

I also disassembled my LCD monitor again, for good this time, as I forcefully removed the backing behind the screen itself.  I drew out how I need to build the housing for the LCD panel and control board.  The design will probably change or flat out not work, so I'm waiting on actually doing anything with it.  I would like to try and use the monitor without a backlight and throw my own light through it to see how well it works.

On the Software front, I've added some features to my pyelm327 code.  I also created a new repo for the CarHUD controlling code and that can be found here at pycarhud.  This is the first mention of this new repo.  Right now it has the CarHUD daemon server code and a test Client code.  pycarhud depents on code in pyelm327 so if you play around with it, you need both.  There isn't much (or any) documentation, but its Python and easy to read.  Depending on your OS, you may have to change serial devices in the code to make it work on your system.

I'm currently working on the initial write of the projector controller code (LED stuff).  This will require wiringpi2-python and python-smbus.  I haven't added this code to pycarhud yet, but it will eventually get there.

That's all for now, going to get back to coding.

Sunday, August 25, 2013

The Make vs. Buy Decision

So I probably mentioned a while back that I was going to build a circuit board for the STN1110 chip of which I have a sample.

I've also been traveling quite a lot, so I haven't had time to work out designs and schematics by hand, but I have had a ton of time to think.  This thinking has led to a dramatic epiphany.

Buy a pre-built STN1110 circuit board and then mod it to my hearts content.

The decision to make versus buy comes up a lot in the Engineering world, especially when you start moving from engineering builds to factory builds.

Let's take a walk down the pros and cons of this possible decision of mine.

Pros
Make Buy
Full control of design Existing design
Have fun doing it myself Design has been tested by a lot of people
Get to hack to make it work in the system

Cons
Make Buy
Don’t have the design complete Don’t get to have as much fun
I can't solder well Pre built
Time to build Have to hack to make it work with the system

Sorry for the ultra craptastic table formatting, let's just say it's my throwback to the original web v0.5.

Looking at the tables, it's easy to see that there are good and bad points to both options.  Also notice that hacking the pre-built made the pro and con list.

One thing that didn't make the tables was cost, because, in my thinking about it, it'll roughly be the same price to make the circuit or buy pre-built.

Ultimately, I'm going to buy the pre-built circuit board and then mod it to work with my setup.

I plan on getting the OBD-II UART board from Sparkfun.  The main modification will be to remove the DB-9 connector, cutting off pin 9, and then re-soldering the connector.  I'll then wire my own 12VDC to the circuit to remove the constant dependency upon the car's battery.

Saturday, July 20, 2013

pyelm327

Last night I set up a bitbucket account and this morning I got the setup.py script working for my ELM-327 device library/driver.

Here is the link: https://bitbucket.org/xtacocorex/pyelm327

The documentation isn't all there yet on how to install and run, but I did provide a sample script that you'll have to edit.  On Linux the script has to be run with sudo or you need to change the device permissions of the com-port the ELM-327 device creates.  No elevated permissions are necessary for OS X.  I haven't tested it on Windows yet.

From my testing so far, the com ports defined in the elm327unitttest.py script are as follows:
OS X: /dev/tty.SLAB_USBtoUART
Debian Based: /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0

Windows will probably have it be COMX, where X was the next available com port when the device was attached.

I set up an issue tracker on the bitbucket page, so if you run into issues with the library, put the issues there and I'll take a look at them.

This is a mostly complete library, but there could be issues that I haven't run across.

I plan to add some more of the ELM-327 command set, I only wrote the basic stuff I needed for the CarHUD.

Friday, July 19, 2013

Quick Update

Just wanted to throw out a quick update.  I created a bitbucket repo for my ELM-327 Python Library, but I don't have any code pushed to it yet.  I also have to create the setup.py script for it and test to make sure it works.  I'll have a sample script provided that can be used to run with and see how it operates.

I'm going to be fairly busy for the next couple of weeks, hopefully I can get some time to put ideas on paper and collect my thoughts.  Maybe I'll get a couple of schematics sketched out the old-school way with a pen.

Saturday, July 13, 2013

Initial Projector Requirements and Thoughts

Since I'm not done with the embedded OS yet, I'll touch on the projector system.  I've been thinking about this a lot recently as the design and implementation will dictate other aspects of the total system design.

If we refresh our memories on the Requirements Page, we can see that Tier 2 requirements have been defined for the projector system.

I'll copy them here:
  1. The projector system shall receive video over an RCA Component signal.
  2. The projector system shall be powered by 12V.
  3. The projector system shall be able to control brightness.
Here's what I currently have, hardware wise, for my projector system:

3.5in LCD Monitor

Yep, just the monitor.  I think I paid $18.29 for mine from a different seller on eBay.  Cheap enough that if I break it, I'm not out of a lot of money.

Here is a nice picture.


This is my idea for the projector.

My plan all along was to disassemble the LCD monitor and cut the connection to the backlight.  I also am going to remove the metal backplate that evens the backlight out, leaving just the raw LCD panel and the control circuit board.

For my new backlight, I found these really cool 0.8in 8x8 LED matrices from Adafruit that have an i2c controller.  The i2c controllers allow for four of the devices to be hooked to the Raspberry Pi's i2c lines.  I think I only need two of them initially.  The LED's themselves have 16 levels of brightness, which meet my Tier 2 requirement of being able to change the projector brightness.  The brightness will be controlled by 3 buttons connected to open GPIO pins on the RPi, one for increase, one for decrease, and the other will be a mode button to cycle between all LEDs on, every other LED on, and every 2 LED on.

So what does this design mean for the rest of the system?

Well, I now have to get the schematic drawn up for the STN1110 OBD chip since that will hook to the RPI uart lines.  I need to get all the components and attempt to get my ideas prototyped out.

On another note, I'm probably going to be working on putting the OBD library and ELM-327 device code on github soon.  Need to get a setup.py file created that will install it properly.

Wednesday, June 26, 2013

Fun with Yocto: Now Where did I Leave my Cookbook?

Looking back a couple of posts I said we wouldn't dive into lower Tier requirements.  So much for that plan.  I kind of like what I did with the last post.

Yocto is an interesting beast.  And when did SW developers come up with the cooking references?  Seriously, when I was messing with compiling Paranoid Android for my Samsung Galaxy Tab 2 7.0 the build environment was littered with lunch, brunch, etc.  The one set of commands that really through me for a loop was: mka bacon.  I spent weeks trying to figure out what mka did in this bash script.

Tangent over.

Yocto is all about recipes and uses a tool called bitbake to build your custom operating system.  See, there is the cooking theme again.

I am going off on another tangent here to say that Yocto isn't what is actually built.  The OS you end up building is called Poky and then there is another codename for the specific release of Poky you download and build.  Not going to lie, I have no idea what the codename is for what I've built for the CarHUD.  I don't think it matters; in the end we're going to end up with a pretty kickass embedded OS that will be lean and mean (all the while creating a wasteland of extra space on an 8GB SD Card).

Another excellent bit of news is that I didn't have to figure out how to get Yocto to build an OS for the Raspberry Pi.  The following fine people have done a fantastic job of doing it for us.
We aren't going to get into the nitty gritty of actually building the full up CarHUD OS in this post.  I'm still working on it and nothing has been put into any sort of version control system.  We are going to get a working version of Poky (or whatever it's called) running on the Pi.

You also need to have a ton of harddrive space.  The Yocto Project documentation says up to 50GB.  According to the super awesome command: ($ is the command line prompt)
$ du -ch | grep total
I have 11GB in the directory I downloaded Yocto into and have subsequently built numerous times.

If you just tried that command in Windows and it didn't work, I'm here to tell you that you have to do this on a Linux box with a newer distribution installed.  You could possibly use a Virtual Machine for this, but your mileage may vary.

Let's install the needed system dependencies in order for this to work.  Navigate to http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html and find the Packages section and install the ones for your system.

We'll be using the method detailed here: http://www.pimpmypi.com/blog/blogPost.php?blogPostID=7. We should all thank Jack Mitchell for his tutorial.

First up, open up the terminal.  If you aren't a command line junkie, I feel a little sorry for you.  It is a great place to hang out.

In the terminal go to the directory you want to download Yocto.  I have a folder in my home directory called Projects.  I forgot to use lower case when I created the folder and for some reason decided to follow the non-standard Linux way of using all lower case.  Way to go Ubuntu, way to go...
$ cd; mkdir ~/Projects; cd ~/Projects 
Now that we're in the Projects directory, we're going to pull down a copy of the Yocto build system and recipes using Git.  Git is a version control system.  If you don't know what version control systems are, they allow you to keep track of modifications to files.  Git is relatively new to me, I've been a Subversion user for a long time.  If you don't have Git on your computer, install it with your distros' package manager.

Let's clone!
$ git clone git://git.yoctoproject.org/poky
The result of the cloning produced a directory called poky inside of Projects, we need to go there:
$ cd poky
Anyone else thinking of Gumby?

Once inside the poky directory, you can do the following to see the build structure.  The following is output from my current setup:
$ ls -g -o
total 84
drwxrwxr-x  7  4096 Jun  9 21:29 bitbake
drwxrwxr-x  9  4096 Jun  9 21:29 build
drwxrwxr-x  8  4096 Jun 25 22:40 carhud_os_build
drwxrwxr-x 14  4096 Jun  9 21:29 documentation
-rw-rw-r--  1   545 May 22 18:34 LICENSE
drwxrwxr-x 22  4096 Jun  9 21:29 meta
drwxrwxr-x  7  4096 Jun 23 21:09 meta-carhud
drwxrwxr-x  5  4096 Jun  9 21:29 meta-hob
drwxr-xr-x 17  4096 Jun  9 21:29 meta-openembedded
drwxr-xr-x 14  4096 Jun 25 20:33 meta-raspberrypi
drwxrwxr-x  7  4096 Jun  9 21:29 meta-skeleton
drwxrwxr-x  7  4096 Jun  9 21:29 meta-yocto
drwxrwxr-x  9  4096 Jun  9 21:29 meta-yocto-bsp
-rwxrwxr-x  1  1592 May 22 18:34 oe-init-build-env
-rw-rw-r--  1  2038 May 22 18:34 README
-rw-rw-r--  1 17436 May 22 18:34 README.hardware
drwxrwxr-x 10  4096 Jun 16 21:06 scripts
You can see all sorts of meta directories.  These contain the recipes, think of them as sections of a cookbook.

You'll see that I have the Raspberry Pi recipes downloaded, which you will now need to do.
git clone https://github.com/djwillis/meta-raspberrypi.git
We also need the Open-Embedded recipes:
git clone git://git.openembedded.org/meta-openembedded
The Pimp My Pi tutorial has you check out a specific revision of Poky and the Raspberry Pi layers, but I didn't do this and went ahead with the latest.  I'm living on the edge.

Now we get to start the basis for our CarHUD image.  Do the following in the terminal:
$ source oe-init-build-env carhud_os_build
This command will set up the build environment for us and will put us into a directory called carhud_os_build.  You can verify this with the pwd command:
$ source oe-init-build-env carhud_os_build
### Shell environment set up for builds. ###

You can now run 'bitbake <target>'

Common targets are:
    core-image-minimal
    core-image-sato
    meta-toolchain
    meta-toolchain-sdk
    adt-installer
    meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'
Now on to the configuration, we need to get into the conf directory.
$ cd conf
We're going to edit layer.conf to do the first customization of our build.
$ nano layer.conf
Inside this file, change the number of threads equal to the total number of threads your computer can handle.  Replace x with your number
BB_NUMBER_THREADS = "x"
PARALLEL_MAKE = "-j x" 
You also need to make the Machine a raspberrypi.  Find the section of machines and comment the last one in the list and add your own
MACHINE ?= "raspberrypi"
I ended up changing the package system to use Debian packages.  You can choose to modify this if you want.
PACKAGE_CLASSES ?= "package_deb"
At the bottom of the file, we need to add a line to whitelist a license.
LICENSE_FLAGS_WHITELIST = "commercial"
Save the file by hitting Ctrl-x, pressing y, and hitting Enter to confirm and then exit.

Now lets edit bblayers.conf:
nano bblayers.conf
Lets add our layers inside the BBLAYERS variable below meta-yocto-bsp and above the closing ", replace <username> with your username:
/home/<username>/Projects/poky/meta-raspberrypi \
/home/<username>/Projects/poky/meta-openembedded/meta-oe \
Above the BBLAYERS variable, add the following two variables:
PREFERRED_PROVIDER_jpeg = "jpeg"
PREFEERED_PROVIDER_jpeg-native = "jpeg-native"
Save the file by hitting Ctrl-x, pressing y, and hitting Enter to confirm and then exit.

Let's go back up to our carhud_os_directory:
$ cd ..
[Insert the music at the beginning of 2001: A Space Odyssey]

Now is the time to build a minimal image for the Raspberry Pi.  Once we get this building successfully, it'll be used as our basis for everything else.
$ bitbake rpi-basic-image
When this completes, flash the image to an SD Card.  The image is located inside your carhud_os_build directory:
/home/<username>/Projects/poky/carhud_os_build/tmp/deploy/images/
Flash the .rpi-sdimg using normal methods for flashing your Raspberry Pi's SD Card.

The build is barebones to the max.  The SSH Server is running, so you can log into the system that way  or over the UART lines.  Username for the build is root and there is no password.

I want to thanks Jack Mitchell for his tutorial that we're using as the basis for the CarHUD OS build.

It will be some time before I come back with a post about Yocto.  I'm on vacation in a week and I am still working on getting everything into Yocto that I want there for the embedded OS.  The next post most likely will be about some ideas for the projector.

Sunday, June 23, 2013

Fun with Yocto: Defining Tier 3 Requirements for my Embedded OS

I've been working on the CarHUD for quite some time now, essentially taking my own pace ensuring I get everything just the way I want it to be.  It's nice not having a deadline for a project.

A while back, I was testing out an initial version of HUD code with my old Chevy Malibu.  Needless to say, the car got hit in one of the snow storms we had out here in Iowa this past winter and I got a used Subaru Outback Wagon.  The code had an interesting effect in the Malibu, after three minutes of driving with the code grabbing OBD data from the car, the script (I'm using Python) would hang.  I never figured out what happened before I got the Subaru* so I went to test it one day since I had to run to Sears to get something.

Just imagine a slew of wires all over the car, I pulled the power cord for the Panasonic DVD player we got for our van to power my 3.5in monitor.  That had to get plugged into the rear of the vehicle since I needed the front port for the Raspberry Pi.  The ELM-327 dongle cord was routed over the steering column.

I was pretty excited, I got to Sears without the script crashing.  Ran into the store, got what I needed, and came back out.  Turned the car on to get everything setup again, plugged the monitor and the Raspberry Pi into their respective power sources and nothing.

The first thought was to the discussions on proper shutdown of the Raspberry Pi and how if you pull power, you can corrupt the SD Card.  I didn't want to believe those reports, but sure enough, I wasn't getting the Pi to boot.

After getting home, severely disappointed, I had two things to do:
  1. Check to see if I pulled the lasted running/working code to my Ubuntu 12.04 machine
  2. Re-flash the SD Card with the Raspbian image I had downloaded
Needless to say, I had developed the code on the Ubuntu machine, so it was there.  I couldn't determine if what I had was the latest, but it would work.

The SD Card was another story.  I spent a long time trying to re-partition and fix the card, but to no avail.  Nothing I did would allow me to flash Raspbian.


What was I left with?  A crappy 8GB SD Card that was unusable.  Did the power pull in the car finally kill it or did the card itself have an issue?  The world may never know, but I went an got a SanDisk and vowed to figure out how to make a read only root filesystem for my Pi.

Are we ever going to get to Yocto?  Yep, right now.

I first heard of Yocto following the UDOO computer on Kickstarter.  In the previous post, I mentioned my uncles 55 Chevy project.  I'm helping him develop a cruise control module that will interface with a MegaSquirt ECU and MegaSquirt GPIO (for transmission control).  These modules talk over CAN and the cruise control system would need to also in order to obtain current vehicle speed.  I mentioned my HUD project to him and how I was using a Raspberry Pi, and he stated he had an Arduino that he was messing with to deal with actual control of this cruise control system.  He also needed a way to display dashboard and had thought about using a Raspberry Pi.

I found the UDOO for him since it does both general computing and microcontrolling at once, and we could probably run Android and get a decent dashboard GUI setup for him.  As one of the UDOO's project updates, they decided to support Yocto since there was a ton of interest in the computer.

Ok, back to how this relates to the Pi.

I will say that Yocto is daunting since the documentation is a little confusing in places.  It's supposed to corral the Open Embedded system, so that must be more of a mess.

I'll eventually get into how I am actually using the Yocto build system, but for the time being, I'll show the Tier 3 requirements that are flowed down from the Tier 2 Requirement "The HUD Controller shall be programmed with an embedded version of Linux."

Tier 3 Embedded OS Requirements:

  1. The Hud Controller OS shall support a read-only root file system
  2. The Hud Controller OS shall be able to run existing Python code developed on an Ubuntu 12.04 machine
  3. The Hud Controller OS shall use pgame to display the information to the HUD
  4. The Hud Controller OS shall use the framebuffer to display the graphics
  5. The Hud Controller OS shall support the Raspberry Pi's GPIO, single pin, I2C, and UART.
You're thinking "Great, he went back to requirements."  Don't leave the blog yet, these requirements tell us what we need to put into our Yocto build.

These requirements place constraints on the OS and tell me that I have to put essentially all of Python (I use version 2.7, haven't bothered migrating to 3.x yet) on the system and I have to install pygame and it's associated requirements (some of these aren't part of Yocto).  I also have to install the Raspberry Pi specific GPIO libraries that are available.  It also means that I can't use X11, not that I would want the latency of it starting up anyway.

As it stands now, I'm essentially done with the OS configuring.  All I need to do now is get my all of my code into the system so it gets installed during the build and to enable the read-only root filesystem. I haven't turned it on yet since I've needed to copy stuff to the SD Card for testing.

Definitely more later, the series on Yocto is far from over.

* I did end up figuring out what was wrong, the OBD device had issues talking to the car as fast as I wanted it to.  I ended up blaming the OBD library I was using and wrote my own.  This is a topic for a later post.

Thursday, June 20, 2013

Current CarHUD Project Status

Since I've probably forced everyone away with boring engineering work, I figured I'd status the project.
I've been developing my SW on an Xubuntu 12.04 system.  It's all Python and is portable between the two computers (the laptop and the Raspberry Pi).  I've been working on and testing the code for quite some time and have had to re-write the way I deal with the OBD-II data.  I'll get into that in another post where I talk about trade studies.

I decided to go with a client and server approach.  The server will be a Python daemon script that runs on bootup (by init.d) and the client script will run when the user is auto logged into the OS.  Right now I have the daemon server code complete and two simple text based clients written.  One client is for quick testing and the other is for driving around and pulling real-time data on the laptop.

I'm working on how I want to display the actual data, my thought is to use pygame since I have old test code using those libraries.  The problem comes into play with the operating system, I'm not using Raspian, Arch, or Adafruits Occidental.  I am building a custom OS with Yocto.  I am going with Yocto for a couple of reasons:
  1. I can get a true read only root filesystem
  2. I can get a quick booting OS by stripping out stuff I don't need
  3. My uncle backed the UDOO computer on Kickstarter (my suggestion) and it will be supported by Yocto and we plan to install his UDOO into a 55 Chevy

The projector is big on my mind because I have to figure out how I am going to make my lamp system.  I came up with a pretty neat approach to it yesterday and refined/enhanced the idea today.  We'll cover that in a post sometime soon.  I do need to make sure I have i2c and raw gpio access in my Yocto build.

That's all for now.

Friday, June 14, 2013

CarHUD Requirements

Since this is an Engineering blog, we're going to dive into requirements for the Phase 1 system.  It may be boring, but requirements detail your end design.

As a Systems Engineer, I do a lot of different things in my day job.

I'm assuming your mind went directly to the movie "Office Space.  The part where Tom Smykowski tells the consultants that he takes the specs from the customer and gives to the engineers is sort of a broad generalization of a Systems Engineers role.

I got lucky and was put into a position where I do a lot of integration and testing, but the main thing Systems Engineers do is Requirements capturing and verification.

Requirement Tiers

All requirements are derived from a single source, the Tier 1 document.  This is what would be provided by a customer.  In the case of the CarHUD, I'm my own customer and will be defining the high level system requirements.  The requirements in this document are written at a very high level.

Here are my Tier 1 requirements:
  1. The CarHUD shall be based around a Raspberry Pi computer.
  2. The CarHUD shall project information to the car windshield.
  3. The CarHUD shall use consume less than 180W of power.
  4. The CarHUD shall interface with the vehicle over OBD-II.
There are lots of rules about how requirements should be worded, but I'm not going to be strict with this project.  Depending upon your job, you may be required to follow rules with your requirements documents.

Why were these four requirement chosen for Tier 1?
  1. I had a Raspberry Pi and was looking for a 
  2. I need to define how the system will display information, where is it going to be shown.
  3. Cars have a 12V battery and cigarette lighter sockets allow for 15A.  This will define the power consumption for all the system components.
  4. This requirement tells us how we need to interface with the vehicle.
From here, we can start to flow down the Tier 1 requirements into more detailed requirements.

For the Tier 2 requirements, we'll break them out into sections:

HUD Controller:

  1. The HUD Controller shall be programmed with an embedded version of Linux.
  2. The HUD Controller shall use an ELM-327 based device for interfacing with the vehicle.
  3. The HUD Controller shall use use the ELM-327 command set as tailored for the implementation required, specific features required for diagnostic purposes are not needed.
  4. The HUD Controller application shall start upon boot of the computer.

Projector:

  1. The projector system shall receive video over an RCA Component signal.
  2. The projector system shall be powered by 12V.
  3. The projector system shall be able to control brightness.

Power:

  1. The HUD Controller shall consume no more than 1A at 5V.
  2. The HUD Controller shall consume no more than 1A at 12V.
  3. The projector system shall consume no more than 8A at 12V.

For more detailed projects, you'll have multiple Tiers of requirements.  For the CarHUD, there is no real need to delve into lower level requirements.


Sunday, June 9, 2013

CarHUD System Overview

Before diving into the details of the project, I should discuss the system as a whole.  To begin, we need to ask ourselves a question.

How do we get information from the car?

All modern cars contain a diagnostic port with various implementations of the On Board Diagnostic (OBD) system.  There are many protocols used by different manufacturers to talk to various components of the cars electrical system, but they are all covered by the blanket of OBD.

With a quick Google search, you can find tons of hits for OBD, specifically version II.  You'll also find a lot of devices being sold on eBay that will talk OBD-II.  Most all of these devices use the ELM-327 and interface to USB or Bluetooth.

I picked a ELM-327 to USB device from a company called Interfuse and had it shipped from Wisconsin.

So where does this put us?  We have an OBD-II device and our Raspberry Pi.  How does one put these together to make a HUD system?

Phase 1: ELM-327 to USB based HUD

For simplicity sake, the first HUD system will use a commercial off the shelf (COT) ELM-327 device hooked to the Raspberry Pi.  Here is the system diagram:


The diagram shows a pretty simple looking setup, you have a power supply, the Raspberry Pi, your ELM-327 device and a projector system.  We'll get into the projector design later on in this blog as it's out of the scope of this post.

This setup isn't without its flaws.  The ELM-327 devices all pull 12 volts from the connector interfacing to the car.  This allows them to get proper signal voltage levels to talk to the cars computer and also power the device itself.  The USB device will pull some power over USB, but is not able to talk to the car without something providing 12 volts.

The dependence on needing 12 volts from the car battery is a concern because you cannot leave the device permanently connected.

This leads us to Phase 2.

Phase 2: STN 1110 based HUD

The STN 1110 chip uses the ELM-327 command set, but houses the ELM-327 code on a faster processor.  This can only mean good things as you can then talk to the microprocessor and the car faster.  I haven't found a pre-built device using this chip, so I intend to build my own.  Here is the system diagram for this phase.


As you can see, it's very similar to Phase 1, but it has it's own 12 volt line allowing me to keep it hooked up permanently and freeing up my ELM device for diagnostic use when necessary.  I won't go into the details of the Phase 2 design, we'll leave that for a later post.

Project: Car Heads Up Display

I have always been fascinated with airplanes and aviation, which is the reason why I got a degree in Aerospace Engineering.  My brother and I are huge fans of military aircraft and one of their features is a heads up display (HUD).

The HUD is an interesting piece of equipment that used to only be available in fighter aircraft, but is now making its way to commercial aircraft.  In an airplane, the HUD displays important information to the pilot so that s/he does not have to put his head down to look at his instruments.  Some of the information displayed include altitude, roll and pitch angles, angle of attack, airspeed, mach number, and compass direction.

There are HUD systems built into certain cars, but that doesn't help me because I don't have one in my Subaru.

Because of the way I drive, I cannot see the speedometer on my dashboard.  This isn't safe to me, but I can't change how I drive, it's too ingrained into my system now.

The main objective of the HUD would be to put the speed of the car and the current RPM to the windshield.

Other information that would be nice to display are: current Lat/Lon, direction (in a similar format to a Fighter HUD system).  These are not in the main plan and will only be done if I get a USB GPS system to hook into the system.

Inevitable First Post

So, as you can tell, this blog is about Engineering with a Raspberry Pi computer.  The main goal is to document what I'm doing with my Raspberry Pi and the projects I am creating with the computer.

Give me some time to get everything set up and I'll be back with a brief overview of the current project.