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.