Too many Directions!

In working with the Overo COM line I have come to a revelation.... well.... more of an observation really.

My revelation is this:

There are so many more possibilities as to what can be done using the Overo COM line of computers than can be accomplished by one person!

DUH! one might say - that is obvious. What really brings it home for me is looking at the computer itself with all of the different capabilities built into it's design. This machine has so many different interfaces built into it's design Gumstix had to settle on a sub-set of the interfaces to bring out to the outside world! I suspect they would have had to make the COM board bigger if they wanted to bring all of the capabilities out from the OMAP Cortex-8 processor just because there is no physical way to have the interfaces access the outside world through the two 70-pin connectors on the current boards. Too bad as there are other interfacing capabilities on the OMAP processor that are not accessible.

OK - So now you have some idea of the quandray I face - so many possibilities, so little time! the following is a partial list (as I am sure you can come up with ideas I have not even considered) of things I want to do with this machine....

1. Intellegent firewall/router/access point.
There is no reason the machine could not handle this sort of application - it is based on Linux and there are all sorts of applications to implement a firewall/router/wireless access point using the Overo COM computer.

2. Wireless MESH-Based communications data collection & processing system.

This is one neat idea as what I envision is the COM system configured to run wireless communications between multiple COM machines and using a MESH network for redundancy of the network link. Given the computing power of the OMAP-3 processors and using the 3530 gives the ability to perform DSP based processing one should be able to come up with all sorts of monitoring/control system ideas for this computer. Heck, you can even have a display using the machine's video capabilities for such things as process control and monitoring. Talk about inexpensive control systems!

3. Intrusion Protection System.

Hmmm - How about a computer system small enough to fit in a cigarette case but able to detect unauthorized access to a network - maybe even able to thwart a hacker attack on a network too. There are software applications for linux that allow monitoring and intrusion prevention (using firewall controls) that can run on the COM machines. At 600-MHz the COM machines clock is faster than a Cisco PIX-515 firewall if that gives you any idea of the capabilities. I know - this is an ARM based RISC machine - so what - it is still FAST! (grin).

4. Intertial Navigation System.

This is an interesting idea I had. There is enough compute power and interfacing capabilities in the COM machines to build an inertial Navagation system! At first I thought it would cost an arm and leg to build such a device as the cheapest one I could find on the Internet runs more than $4000 USD. Well - a little research reveals you can obtain the hardware for a GPS, 3-Axis Magnatometer capable of very low magnetic field measurements down to 0.015 u-Tesla and a 6-degree of freedom solid-state gyro/accellerometer package for less than around $200 - $250 USD! Given the Earth's magnetic field ranges from around 30 - 60 u-Tesla there is no problem in detecting the direction/orientation of the Earth's magnetic field! With a GPS, Magnatometer and gyro/accellerometer package you can build your own inertial navigation system that rivals most expensive packages for a small fraction of the cost. What can you do with such a system??? How about sailboat autopilot? UAV anyone?

5. Magnatometer Mapping System.
Building upon the inertial Navigation System you could use the 3-axis magnatometer output along with the GPS information to produce a map of the magnetic field in an area - by moving back and forth along a line and sweeping the area and given you know the orientation and direction of movement based on the sensor inputs from all of the sensors and GPS you can draw a "map" of the earth's local magnetic field strength and orientation relative to the sensing system over a given area. Basically you have a method to detect iron/steel objects by the affect they have on the local magnetic field. Buried treasure anyone???

6. Perimeter Monitoring System.

An interesting thought here. Why not use the COM machine as a perimeter monitoring system. Since you can get a LCD display for the COM machine you could actually "draw" the perimeter you are monitoring on the display then change icons/colors to denote where things are happening. By using wireless sensors and coupling back to the COM using wireless communications you could actually deploy a monitoring system rather quickly. I am not delving too much into the details here but there are all sorts of possiblities!

7. Home Entertainment System.
I follow several forums such as the Gumstix and Beagle-Board Forums and I get this idea from the Beagle-Board forum. Seems there is an effort out to build a home entertainment system based on the linux operating system. This would be a natural thing for the COM computer as it runs linux. The really nice thing is the Gumstix Overo line and the Beagle-Board both use the same OMAP processor (at least the OMAP 3530) so the same applications software will run on both boards. Granted there may be some small differences but for the most part there is very little difference as far as applications software is concerned. One such application is a home entertainment system - it is in development on the Beagle-Board so should port directly over to the Overo COM machines too (grin).


8. Home Control/Monitoring System.

This idea is a combination of the perimeter monitoring system and the home entertainment system. Why not combine them to have a total home control and monitoring system - you would use the television as the display for the system when you needed to check on it and then could watch movies played through the COM board or TV from an external source. All you have to do is use your imagination to come up with all sorts of possiblities!

As you can see I am having a great time coming up with ideas - now all I need is the time to work on them! Hopefully in the coming months I will actually have the time to put into implementing some of the ideas mentioned here. As I work my way through them I plan to post the information here so others may follow along and hopefully make some improvements on my initial implementations! That is what public domain software/hardware is all about - improving upon ideas! Everybody comes out ahead!!!

I thought of some more ideas and have listed them below but did not expand on them - see what you can come up with for them and let us know! Who knows - you may come up with the next killer application!!!

9. Network Monitoring System.

10. Communications System.

11. VoIP PBX System.

Your Ideas here.

As you can see - If you can dream it you can do it! All it takes is just some common sense and a will to succeed. It also helps if you have an understanding of the projects and know where to find the parts. Comments??? Ideas??? Let me know!!!

Working on the development side of things

For the last several weeks I have been working on the development side (software implementation) for the Overo series of COM (Computer On Module) units. This has been rather an interesting experience as the Overo line is a rather new (read: bleeding edge) computer system so the software is being created in a very fast pace in terms of development. Unlike a Windows based machine you have to run a development system to implement different applications or make changes to the Linux kernel for different hardware drivers if they are not active in the factory installed version. You can installed pre-compiled applications using an application installation program but if the application is not already built or you are wanting to use a linux hardware driver that is not already factory installed then a development system is a must. Besides, it can be very educational to see how things are done under the hood, so to speak. The development system chosen for the Overo line by Gumstix is called OpenEmbedded which is an open source development system for embedded computer systems (interesting - wonder where they came up with the name?).

Until now I have worked with cross-compiler systems where you were actively involved in the cross-compile process, such things as creating and modifying 'make' files (used to setup dependencies, setup variables used, call the different development applications and so on) to installing the different cross-compiler and library files and compiling the different parts of the development system toolchain. Most of the development systems I have worked with also require "switching" to a virtual filesystem for the actual cross-compilation process to protect the underlying operating system otherwise it is very easy to trash the operating system and crash the development computer system!

In using the OpenEmbedded system that has totally changed! Most of the 'grunt' work is now handled by the OpenEmbedded system itself, from downloading the different parts needed to cross-compile C source code, compiling the cross-compiler tools and software libraries, installing the different parts used in the proper locations within the development computer's filesystem, downloading the different applications and Linux kernels used for creating the operating system and applications, determining the different dependencies (which parts need to be compiled in what order so the different parts and applications can 'find' the needed links and library headers) - then - building the whole operating system and applications along with the filesystem, boot-loaders and startup scripts needed to run the system and applications on the Overo line of computers! Gotta love that! Now - the learning curve for OpenEmbedded is steep (at least it is for me) but is very doable and if you do become accomplished at creating bitbake recipes (recipes are the script files that tell BitBake how to accomplish something) you can build most any application without the laborious task of writing 'make' files.

Now - this is the part most here will find difficult. The OpenEmbedded system runs on Linux systems ONLY! Part of the reason for this is most of the embedded computer systems working with open source are based on Linux so it makes sense to develop in the same environment as the target system operating system is going to be. OpenEmbedded will NOT work in Windows (unless you are running a Linux system on a Windows based machine)! This may change in the future but I would rather stay in the Linux environment so as not to muddy the water too much - just think of the headaches you might encounter trying to run Windows compilers to build Linux operating systems on computers that have a whole different architecture from the machine the target system is targeted to! This is not as bad as it might seem! My home development system IS a Windows based system ( I like gaming and most of the games I play are not written to run in Linux!) but I can run Linux on the system without any issues and still perform other tasks in Windows at the same time.

How can this be you ask?

Simple - in one word - Virtualization!

I use VMWare's free VMWare Server to run different "Virtual" computers on my Windows system. This allows me to have multiple computers exist on the same hardware and I have enough computer resources to run Windows (XP) and three or four virtual machines at the same time on my machine. Of course it can get confusing at times but the capability is there (grin). Now there is a caviat to using a virtual environment... you want to have enough physical resources on your machine to allow the virtual machine to run decently. In other words you want to have at least 1-gig of RAM and at least 100-Gigs of hard drive space available otherwise if you have only minimal RAM in the machine the virtual machine may not have enough memory and will start swapping to the virtual drive (this really bogs things down) and if you don't have enough hard drive space you will "run out" of virtual hard drive space in the virtual machine - this is worse than too little memory! Having said that here is what I did to create a development system for the Overo line.

Here are the (very) generalized steps I used:

• Downloaded the Free VMWare Server and installed it on my computer system. The VMWare server also needs the Java Runtime package so I downloaded that as well then installed it on my machine per the instructions on the Java website.
  
  
• Once I had the VMWare Server installed I opened the VMWare Server application and created a virtual machine for a Linux System. I setup the memory for 512-Megs to start and configured the hard drive storage for 80-Gigs of space. For the 'network' settings I use 'bridged' mode so the virtual machine would use the computer's interface and the virtual operating system would be able to use DHCP to obtain the information needed to connect to my home network automatically. The configuration for the virtual machine is stored on the hard drive a several files (this includes the virtual hard drive image) which makes saving copies very easy - just copy the files and you have a backup!
  
  
• The Linux environment I use is Ubuntu Linux workstation. I downloaded the Ubuntu 9.04 version (latest stable version) as an ISO file (CD image file) and saved it on my machine in the directory where I built the virtual machine for the development system. The reason you save the ISO image in the same location as the virtual machine storage is very simple - in the VMWare Server environment you can only "see" items that are stored in the virtual machine directory!
  
  
• To install the Ubuntu 9.04 Workstation software in the virtual machine you need to configure the CD-Rom drive settings in the VMWare Server settings for the virtual machine to use the ISO image as the CD-Rom. This is very easily done during the configuration of the virtual machine as there is a question during the configuration as to what to use for the CD-Rom - you just select the Image setting and browse to the Ubuntu ISO image file previously saved in the virtual machine directory - this is the only place you can browse from within the VMWare Server which is the reason I saved the ISO file there.
  
  
• Once the virtual machine was configured I started the virtual machine and opened a virtual machine window. The Ubuntu system starts up just like the CD version - I selected the "Install Ubuntu" selection to install the Ubuntu system in the virtual hard drive. After answering a couple of questions (keyboard and mouse type, timezone, user name and password, etc ) the Ubuntu installer fires up and completes the installation of the Linux system into the virtual hard drive and then waits for you to "remove" the CD-Rom media and reboot the virtual machine.
  
  
• To "unmount" the Ubuntu ISO you just edit the CD-Rom settings for the virtual machine in the VMWare Server and set the CD-Rom to either none or the physical one in your machine (personally I set it to the physical one). Ubuntu will complain since it was running from the ISO image but just answer "yes" to the question then reboot the virtual machine. When it comes back up you will be running in Ubuntu 9.04 (or whatever version you are using) Linux in a virtual environment!
  
  
• After Ubuntu was installed on the virtual machine I performed a system update to download any new updates for the system. While this is not a hard requirement I like to have a system that is fully up to date before using it for development.
  
  
• The next step is to install the Openembedded development system in the virtual machine. I used the steps located on the Overo Development Website (Link) but there are a couple of differences for the Ubuntu 9.04 version:
  
  
  1. One has to do with the notes on the webpage where the instructions state to add the following to the sysctl.conf file; 'vm.mmap_min_addr = 0' . The sysctl process does not recognize this command so I left it out where the instructions stated to place the command.
     
     
  2. A second item has to do with the 'way' the development system operates in the current default download of the OpenEmbedded system. BitBake (the MetaData executor) and OpenEmbedded use Python ( a programming language) to implement the development system - the default download configures the system to use "Python" whereas the Ubuntu system uses "Python-2.6". How can that be an issue - it is as the system gets 'confused' as to which version to use - talk about making a mess! Also, it is very difficult (at least for me) to determine exactly what fails during a build when this confusion occurs. The answer to this issue is really simple - just update the OpenEmbedded development system. If you follow the instructions to install the OpenEmbedded system I listed earlier then all you need to do is go into the org.openembedded.dev directory and type the following command: git update which downloads the current updates for the OpenEmbedded system. One of the updates corrects the Python "confusion" issue so things work properly after the updates are done. NOTE: I am being metaphorical here when I say it is a "confusion" issue but it makes it easier to describe (grin).
     
     
  3. When you reach the point where you perform your first build be prepared to wait a while for it to complete! On my system, connected to the Internet at 8-mbit/second it takes about 12 hours for the development system to download all the parts needed and compile the console (CLI) version of Linux for the Overo computers. Once you have performed a successful first build the time is much shorter as all of the development parts have been downloaded and compiled and all of the source files for the console version are on your virtual hard drive.
     
     
• Once the development system has been installed and you have built the first recipe (omap3-console-image) successfully you can build the GUI desktop version for the Overo line by using the 'bitbake omap3-desktop-image' command in the overo-oe directory of the developement system. Of course, if you have not built the development system and are just reading this that last sentence probably will make absolutely no sense what-so-ever! (grin). A note - there are a great many parts to the GUI version that have to be downloaded so this first build also takes a fair amount of time! On my system the combined first build of the console and GUI versions took about 26-hours total to accomplish. Of course, your time will be different based on your computer hardware and your internet connection.
  

If you do decide to setup a development system for the Overo line I would advise you insure you have enough memory and hard drive space! On my system the GUI version of the Linux operating system for the Overo line takes about 22-gigs of space. If I wanted to build ALL of the applications and drivers currently available it would require around 40 - 45 gigs of space to store all of the information needed.

I am thinking if there is some interest I could create a VMWare image of the development system with the OpenEmbedded and BitBake applications installed. The VMWare image would already contain the all of the OpenEmbedded updates at the time of the image build. All you would need to do is download and install the VMWare Server software, install the image then perform the console and GUI bitbake builds to have a Overo development system of your own. Let me know what you think...