OpenEmbedded bug found and squashed

I’ll be using Python extensively for my robotics project with Gumstix. The goal is to come up with a set of modules that let the user create high-level behavior programs for the robots without worrying about how to control the hardware. Of course none of this is going to happen if I can’t actually get the Python interpreter to work on the Gumstix.

The basic Linux installation on the Gumstix doesn’t come with Python, so I had to put in on there manually. The Python packages for Gumstix are very modular, which lets installation of only the needed packages without anything extra. Instead of just installing the required packages on the Gumstix I decided to create a fresh root filesystem image, since I would be installing it on multiple Gumstix. What I really needed was the Pyserial package which provides a nice Python interface to serial ports. That was the only package that I added to the buildscript (more on that later), hoping that it would pull in all the required dependencies. After I finished the build and reflashed the Gumstix using the wiki instructions, I booted up and started the Python interpreter. But to my horror, it wouldn’t load the Pyserial module. Apparently it needed an older implementation of various string functions which weren’t pulled in. So I repeated the process, by adding the older module to the build script. Even then the Pyserial module wouldn’t load because it couldn’t find the struct module. By this time I was starting to get frustrated, because the struct module should have been pulled in with just a basic Python implementation. The struct module handles conversions between Python values and C structs represented as Python strings. This module not being found meant that somehow the entire OpenEmbedded Python system was fundamentally broken.

After a bit of research with the help of Google, it turned out that there was an error with the python-2.5-manifest.inc file which contains a listing of all the files that make up the base Python system. This file had an incorrect reference to which files actually implemented the struct module. This problem had occurred in the OpenEmbedded system around November last year and had been fixed, but somehow the fix had not found its way into the Gumstix version of OpenEmbedded. So I’ve dutifully filed a bug report and submitted patch, and I’m hanging on to my corrected Python manifest while the patch is implemented (which will hopefully be soon).

This whole experience of tracking a bug in a system I hadn’t created and finding a fix for it was quite an interesting experience. On one hand it was quite frustrating because the problem wasn’t it something I had an intimate knowledge of. On the other hand it forced me to learn a lot about the OpenEmbedded build system and I also learned how to go about looking for documentation, all of which will come in handy as I keep working with Gumstix and the OpenEmbedded system. And last but not least, it led to my first ever patch submission for a large software project — not much of a contribution, but it certainly makes me feel good !!

Setting up Kermit to work with the Gumstix

One of the most direct ways to talk to a Gumstix is via a serial port. Though a serial port is rather slow and is not the best for day to day operation, it comes in handy to do initial setup and repair. It’s also useful for flashing the Gumstix and installing a custom kernel and filesystem. Since I’m running a Linux host machine, I have two options for programs for connecting via serial: minicom or kermit. I started off using minicom because it was in the Arch Linux software repositories and because the configuration was very easy. However the problem is that the Gumstix cannot receive minicom file transfers, which make minicom useless for reflashing the Gumstix.

After compiling Kermit from source and starting it on the proper device, there are a number of options to be set before one can actually connect to the Gumstix. Doing this everytime is extremely tedious and error-prone so it’s easiest to create a simple script with the following:

#!/usr/bin/kermit +
kermit -l /dev/ttyUSB0
set speed 115200
set reliable
fast
set carrier-watch off
set flow-control none
set prefixing all
set file type bin
set rec pack 4096
set send pack 4096
set window 5
connect

I saved this script under the name konnect and placed it directly in my /bin directory. After marking it as executable with a sudo chmod +x konnect, I could execute the script and have it open up Kermit with all the required configurations in place. If you want to use this script, you should change /dev/ttyUSB0 to whatever serial device your Gumstix is actually connected. My laptop doesn’t have serial ports so I connect via a USB-serial adapter. You should also make sure that the device can be accessed by the user you run the script as or else it will keep throwing up permission denied messages. If you don’t want to mess with file permissions, you can run it as root via su or sudo.

The Gumstix Game Plan

    The last few weeks have been rather busy, but with at least two light weeks in front of me, it’s time to get started with something serious. My first project with the Gumstix will be to use them to drive the Hemisson robots. I had thought about creating some sort of a simple “Robot Control Language” and then have the Gumstix translate that into serial commands to drive the Hemisson. However inventing a computer language, no matter how simple isn’t an easy task and I would like to have my first project be something simpler.

The point of using a Gumstix to talk to the Hemisson is so that a user can write higher-level algorithms without worrying about details such as making the wheel turn. I also want to use a programming language that has a relatively small amount of syntactical baggage and where it is easy to use function libraries without endless recompiling and linking. Luckily I know just such a language — Python. Python’s modules make it easy to create, use and distribute useful code. Being interpreted, there is no compilation needed which means that a user can easily write and debug programs on a host and then run them on the Gumstix without any change. Also important is the existence of the pySerial module which allows simple access to a machines serial ports: something which will invaluable to me.

Eventually performance might become an issue: the Gumstix is after all, somewhat limited in terms of its hardware and users might want to implement complex algorithms to determine the behavior of the robots.  It may become necessary to re-implement the control library in C for the added performance edge. However since Python can easily operate with C functions, the Python programs won’t have to be rewritten (though some alterations will also be needed). You could say that in some ways the Python module will be a prototype for a more powerful and efficient C implementation sometime in the future, but I can’t guarantee that at the moment.

My first step is to brush up on Python and get used to the pySerial module and see what functionality it offers. I’m not going to be using the Gumstix for a while, but rather communicating directly from laptop to the Hemisson until I have at least a rough working implementation. But before I start working on a final implementation, I will be testing the serial connection between the Gumstix and the Hemisson and making sure that Pyserial can work with it as well. With all the preliminary steps completed I can start work on a robust, full-featured module. I’m not quite certain how much work the module should handle i.e. should it just translate movement instructions from the Python code to serial or should it have algorithms to implement things like turning through angles or rotating? These are not decisions to be taken lightly because they will have a direct effect on how users will be writing their programs, and its something that I’ll be discussing with my professor. The best idea might be to implement some higher level functions but leave the underlying simpler functions open as well.

I’m not going to venture a timeline for the project, because I have other priorities which take precedence (classes for example). But I would like to have a working version by the end of the semester (beginning of May), progressing to something which is full-featured and reasonably bug-free by the end of summer (late August). With Spring Break starting in a week, I should be able to familiarize myself with both Pyserial and the Hemisson serial interface in two weeks time. After that its just a matter of proper planning and getting things working.

What can I do with my Gumstix?

Gumstix is a very versatile platform as long as you can efficiently make use of the its modest hardware capabilities. The Connex 200xm board that I will be working with has a 200Mhz Intel XScale processor, 64MB of SDRAM and 16MB of strataflash for storage. The operating system that comes installed on the strataflash memory chip is a lightweight but full-fledged Linux distribution, which can be easily modified and rebuilt using the OpenEmbedded development environment. The small storage size means that any large applications will require an additional storage component in the form of a micro SD, Compact Flash or MMC card. But the 64MB of SDRAM should be more than sufficient for most embedded applications that you want a Gumstix to handle.
Now that I have a stable connection open to the Gumstix via both serial and USBnet, it’s time to move and start exploring what it can do. One of the possible uses for the Gumstix would be as smart controller board for simpler electronic systems such as simple robots. Since the OpenEmbedded system supports running programs written in high-level interpreted languages such as Python and Perl, it opens up the possibility of writing programs in those languages to control these simple robots. This is something that I intend to investigate in the relatively near future. One of the goals for my Gumstix project is to make the Gumstix control the Hemisson robots which have a much simpler 8-bit, 20MHz microcontroller. Though it is certainly possible to program the Hemisson microprocessor directly in C, this would not be particularly easy, and the programs would be limited by the processor’s capabilities. More on the Hemisson robots later.
The various extension boards available (especially those incorporating wifi and Bluetooth)make it possible to use the Gumstix as lightweight servers, possibly communicating with various other mobile devices (and other Gumstix). It would be interesting to study what network architectures would make the most efficient usage of a the lightweight, mobile nature of the Gumstix. Once again there is an obvious application in robotics: creating intelligent, decentralized swarms capable of solving a wide variety of problems.
Although the swarm networking is something that I am very interested in eventually exploring, my first goal will be to figure how to create a good interface between a host computer, a Gumstix and a Hemisson robot. Among the things I have considered is creating a simple BASIC-like language which the Gumstix would then interpret to drive the robot. I’m also going to look at the other expansion boards available to see if any of them would help make my job easier.

Starting with Gumstix

The Gumstix are a set of small single board computers designed for embedded, low power systems. Because they have a motherboard-and-expansion architecture, they can be fit into a large variety of uses. They run a custom Linux distribution which is small and lightweight, but supports a wide range of functionality. Though Gumstix have been used to power things ranging from robotic fish to UAVs, my own goal is much simpler. This is primarily a learning experience for me to understand how the Linux kernel works as well as a hands on introduction to systems programming.

Even though the Gumstix is a full featured computer, it is quite lightweight, meaning that it makes sense to develop software on a more powerful machine and then to transfer it to the Gumstix. The most direct way to do that is to set up a serial connection from a host machine to the Gumstix using on I/O extension board. I’m currently using a Connex 200xm board along with an I/O expansion that gives me 2 serial ports, a mini-USB port and of course a power input. My host machine is my trusty Linux laptop running Arch Linux. Since Arch is not exactly a mainstream distribution, many of the guides and instructions that I find on the internet might be have to be modified slightly to work with my setup.

My first task was to get a serial connection up and running. Since my laptop is very recent it doesn’t come with any serial ports, so I needed a USB-serial adapter. That created some problems initially because I couldn’t find the device that the serial port mapped to. I was looking at the normal USB devices listed under /dev but the actual device was under /dev/tts as USB0 (though it was accessible as /dev/ttyUSB0. That problem being solved it was time to plug things in and get started. I’m using minicom to talk to the Gumstix over serial, because minicom is in the Arch package repositories, but much of the documentation seems to be geared towards kermit. I’m willing to change if I find that necessary. There is some setup required to set minicom to the right device and baud rate and to turn off modem dialing. But Minicom’s built in configuration utility makes that a snap.

Once I connect via serial and power on the Gumstix, I can see the entire boot sequence. It starts by mounting the U-boot bootloader which then loads the rest of the system. The entire system is stored on Flash memory on the board itself, though it is possible to extend the storage via MMC and CF cards. Via serial it is possible to login as root and make serious changes to the system. My only gripe is that point is that there is no power switch on the Gumstix which means that I have to physically pull out the power adapter every time I want to power it down. It might be worth considering some sort of external switch so that I don’t have to keep doing that.

Though the serial port is certainly good enough for the time being, it might turn out to be slow in case I need to start transferring larger files. Luckily the Gumstix can use the miniUSB port as a network interface and so can any Linux distribution with a recent kernel. It simply involves loading the appropriate kernel module (it’s called usbnet on Arch), detecting the network interface by running a ifconfig -a and then setting the usb0 port again using ifconfig. Running

ifconfig usb0 192.168.0.2

on the Gumstix followed by (as root):

ifconfig usb0 192.168.0.1

on the host will set up a network connection, which can then be used to log on to the Gumstix via SSH. This configuration needs to be redone every time the Gumstix is restarted. But the Gumstix can be set up to retain the static 102.168.0.2 IP by opening /etc/network/interfaces and replacing

iface usb0 inet dhcp

with

iface usb0 inet static
address 192.168.0.2
netmask 255.255.255.0

The usb0 interface can be activated at boot on the host machine as well, but I find it easier to alias it to a shorter command so that I can have it only when I need it.

Now that I have two separate fully-functional interfaces setup to my Gumstix, I’m in a position to begin thinking about serious development. There are a number of options available which require some thought as well as a careful analysis of what I want to achieve with the Gumstix .