The ByteBaker

    Over Spring break I’ve been reading the older archives of own of my favorite blogs: Coding Horror. Though a lot of the posts are worth reading for anyone involved in computer programming, one that I feel is especially worth mentioning is Development is Inherently Wicked. The article talks about how it is almost impossible to fully plan out a complete software project and then have that plan hold throughout the process of creating the software. Though I’ve personally never been involved in a large scale software project, I’ve come to realize how true this is even with small projects.

For the past week I’ve been busily writing a Python package to allow interaction with a Hemisson robot. My initial planning was very simple: I would have only a very simple function-based interface.  The actual hardware interaction would be separate from the part the user used and there would be a simple configuration file which the user could edit. Was this enough planning with which to start writing code? I was afraid it might not be, but in the end it turned out to be a good thing. I managed to write the hardware interface in just a few hours and in just about 80 lines of code. It would have taken far less time, but there was some ambiguity in the Hemisson documentation that made me fiddle around directly with the robot to get things right.

It was when I started to build the configuration system that I had to deal with the other side of the coin. It was very tempting to jump in and quickly come up with some sort of config file syntax and then write up a parsing routine for it.  It would have worked and it probably would not have been much work. But I decided to fight the temptation to hack away and instead read up on Python tools for doing this sort of thing. After reading about online and posting to the Python-tutor mail list I came upon a simple, more elegant solution: the config file would be a Python file itself and I would make use of Python’s intrinsic ability to import modules stored in external files to access it and read. A little bit of planning thus eliminated the need for a rather large amount of complexity and code to handle that complexity. I’ve just finished another round of coding: a part of the actual module that the user will be using. I’ve managed to create simple functions for moving the robot and for accessing its sensors. However since the robot does not include any hardware to keep track of its position, writing more complex functions such as turning through a particular angle will be significantly more challenging. Once again, I need some planning and research.

The lesson I’ve learned is that doing a good job of making software involves a fairly fine balance between making careful plans and just sitting down and pumping out some code. So how can you know which one is more important? The answer is two-fold. Firstly, its a mistake to think that planning and coding are separate actions. They are part of continuous loop and a healthy software project must treat them as such. There has to be a decent level of feedback from the code to the plans and the plans have to make sure that bad code isn’t written just because it is easy and the first thing that comes to mind. Even while I was writing my hardware control routines I had to think about how I would deal with different hardware configurations and how to let the program parse and adapt to the configuration information. Like a lot of computer science, this is a good example of choosing the middle path: realizing that either extreme can lead to a badly implemented or even incomplete project and that staying close to the middle is the best way to go.

If you’re interested in learning more about this approach to programming projects, read though the entire article and Coding Horror and the book that it references.

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 !!

    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.

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 .

A big hello to all my readers. Apologies for being away so long. I’ve moved to the US, where I’ve just started college. I’m still doing orientation, and classes start on Monday. Unfortunately I don’t have a computer of my own, but thankfully there are lots of campus computers (especially in the engineering building where I will be spending most of my time). I’m going to get back to writing articles from next week, probably every alternate day (depending on workload). By the end of the year I would like to move the blog to its own domain and maybe to paid hosting. Right now I have to rush to a chemistry placement test and then to some more orientation activities, but I’ll be back soon with more interesting techie goodness.

A large part of what I post on this blog has to do with new stuff: new technologies, new services, new trends. In order to offset this large amount of information regarding new things, I’m going to periodically write articles under the heading “Backlog”, i.e. articles regarding slightly older technologies and tools, but ones which are still useful today. Don’t worry, I’ll try my best not to turn them into boring history lessons, wherever possible I’ll be drawing comparisons with modern alternatives and giving instructions to put these time-tested utilities to work for yourself. I intend to post one Backlog article a week, starting from next week. And also from next week I intend to post at least every alternate day, if not everyday. Once again, thanks to all my readers for sticking with me through a dry spell and I will try not to disappoint again.

Here we finally are, the last part of the series. This final post will just talk about some common extensions that you probably will find useful.
First off is AdBlock. If you don’t have this extension, get it. Now. It does just what the name says: it blocks ads. Simple and intuitive to use and completely effective.
One of Firefox’s most basic tools is tabs. They’re good enough on their own, but the Tab Mix Plus extension, makes them just that much better and easier to use. There is also another extension called Tabbrowser Preferences. Both of them do mostly the same thing, use whichever one suits you best.
Finally for those of you who equate performance and quality with speed, grab FasterFox, a simple tool designed to make your Fox sleeker and quicker.
Of course there are hundreds more extensions than the few mentioned here. So head over to the Extensions page and indulge!.

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!