Hindenstix

11 This is the End

2008-05-15T00:28:00.008+01:00

It's been a long time in coming; the dust has settled, exams are finished and we've received our final grade for the project. As expected, the grade had to reflect the fact that the project was never completed and obviously suffered as a result. Nevertheless, the feedback we received from Graham was very fair, helpful, and helped to highlight some of the areas in which the project was lacking - most notable was it not being finished, I suppose.
To conclude this record, I'll finish as I've progressed - by discussing the aspects of the project attributed to me, as I don't want to be speaking for the team as a whole. Hindsight is a great thing, and there are a good few things I would have done differently had I known at the beginning what I now now.

Firstly, I should have first checked that everything we needed was on the current buildroot revision, and upon finding that something was missing, I should have updated immediately. Flash first, ask questions later.
Luckily enough, because I had documented what I was doing as I went along, I had reference points to work from when I did update and things went wrong, but if I hadn't been logging my actions I would have been back to square one. Since the buildroot update did actually cause a lot of problems in the end too, flashing early would have given me more time to work up a backup plan for the aspects that ended up broken - namely bluetooth, for which I came up with a backup but the rest of the team didn't have time to implement.

Secondly, integration was an absolute nightmare. Although we're obviously not blameless in this, I would partially put this down to inexperience - and this would be supported by the fact that some other teams ran into integration problems on their own projects. We hadn't really any experience with putting a fairly diffuse project - in this case, using new hardware, and getting C, C++, and Java talking - together, and we'd assumed it would be a cakewalk: it wasn't. As far as my role in this was concerned, I managed to get the given programs compiled and working on the gumstix, so I was a bit happy with this, but obviously it's pretty useless if it's not all working.

I would be lying if I said it wasn't a bit of a pain working on the gumstix, especially when things went wrong. However, I would also be lying if I said I didn't have any fun while working on the project. For anyone reading this who may be working on gumstix for a project, learn from my mistakes! Use the many resources on-line and post to the mailing list if you're having problems - hopefully they'll be more helpful in your case than they were in mine!
Thanks to the rest of the team - Semir, John and Donal - and thanks to everyone who lended a helping hand with the project, most notably Graham and Lorcan. It's been enjoyable keeping this blog, and may it serve as a lesson to any potential gumstix projects in the future:

Abandon hope all ye who enter here

Just kidding ;)

~Fin

10 Coming Soon...

2008-04-28T16:53:00.003+01:00

I'm pretty busy with the lead-up to exams, so I'm going to delay my final conclusions and report until exams and assignments are finished and the dust has settled. Unfortunately, the project never really got fully off the ground (there haven't been enough puns) because of issues with integration and the gumstix doing us the favour of kicking up a fuss at the last minute, but I feel the need to do a final write-up of what went right, what didn't, and what should have been done differently, knowing what I now know.

09 Frustrated Flashing

2008-04-09T01:21:00.007+01:00

Since we need more packages on the gumstix than we were given, I went about flashing the file-system, playing it safe by first checking out a revision slightly after they started including C++ support by default in the buildroot.
Checking out revisions is very easy, just a standard subversion checkout command:

# svn co http://svn.gumstix.com/gumstix-buildroot/trunk gumstix-buildroot

for the latest build, or

# svn co -rXXXX http://svn.gumstix.com/gumstix-buildroot/trunk gumstix-buildroot

for a specific revision, where XXXX is the revision number required.

I began by installing the extra packages onto our current gumstix revision - if it ain't broke, and all. Checking out revisions, while easy, takes a bit of time. Then, the making of the revision takes an even longer time: probably around 2 hours or so for the latest ones. Couple this with another 40-60 minutes for transferring the file-system via serial to the gumstix, and you've got a long wait ahead.

Flashing the file-system is fairly straightforward:

{Interrupt the boot}
GUM>loadb a2000000
{Access transfer menu in hypertrm and send rootfs.arm_nofpu.jffs2 file}
GUM>protect on 1:0-1
GUM>erase all
GUM>cp.b a2000000 40000 ${filesize}
GUM>boot

This went through easily, but upon finishing, the wireless capability ceased to work, much to my chagrin. Some tinkering lead me to a discovery that the wifistix board wasn't being seen at all, despite being powered. After some searching online to no avail, I decided to just try another file-system.

I tried a few post-1444 revisions but running the makefile just wasn't working for some reason. Having run into this hitch, I decided to just opt for the latest release - supposedly not the most stable but it managed to make successfully, so it was worth a shot.
However, it turns out that the bootloader currently being used by the gumstix, u-boot 1.1.4, was older than the compiled u-boot provided with my new revision: u-boot 1.2.0. This meant that not only did I have to flash the file-system and kernel to the gumstix, I also had to replace u-boot which, as I understand from the U-Boot wiki, is tantamount to manually disarming a minefield - one slip-up and I'm toast.

GUM>loadb a2000000
{Access transfer menu in hypertrm and send u-boot.bin file}
GUM>protect off 1:0-1
GUM>era 1:0-1
GUM>cp.b a2000000 0 ${filesize}
GUM>reset

Thankfully this went off without a hitch. Upon booting I was getting some errors, but this is understandable as I hadn't flashed a kernel or a file-system; there was nothing there to load.
Putting on the file-system was the same as previously quoted, and transferring the kernel was very similar:

{Interrupt the boot}
GUM>loadb a2000000
{Access transfer menu in hypertrm and send uImage file}
GUM>katinstall 100000
GUM>katload 100000
GUM>bootm

This enabled the gumstix to boot, which I was very happy with as I now knew I hadn't bricked the unit. However, not only did the latest revision not fix my wifistix problem, it also appeared to break the bluetooth capability. I tried, again, searching online and tinkering around myself but I'd been left with all my previous problems, as well as some new ones, neither of which seemed to have answers online.

So, I decided to flash the file-systemagain, to revision 1445 this time as I'd seen it mentioned as working on the buildroot wiki. Another make, another transfer, and the wifistix was being detected again - I was very glad here, as it ensured me that the system wasn't bricked. Unfortunately, there were still a few problems with the wireless; I was able to scan for networks, but not able to connect to my home network. A bit of searching around online lead me, ironically, to a page about gumstix wireless on the UCD trac. Turns out that the revision I was using dropped the last character on the network essid.

So, at this stage I had my extra packages on the gumstix, and was actually able to test them out. C++ cross compilation worked fine, albeit with a small hello world programme. gpsd was also present, as was gpspipe, which was an excellent sign as they had not previously been included. Unfortunately though, I wasn't able to test either of these features because of the bluetooth not working.

At this point, I'm facing a dilemma: do I flash to yet another revision of the file-system in the hope of fixing the bluetooth, and risk breaking something new, or do I attempt to fix the bluetooth on the current revision? I've been attempting the latter all day, with no result, so I may have to flash a new revision. I'm hoping a solution to my bluetooth problem will pop up tomorrow.

08 GPS and Filesystems

2008-04-07T03:43:00.005+01:00

Rejuvenated from the midterm break, and my trip to Nice I dived right back into working on the Gumstix...almost. An exam on the first week back after the break scuppered that slightly, but our subsequent team meeting with Graham went pretty well in terms of discussing milestones, completed as well as upcoming, and this got me focused on the project again. Graham suggested a good plan of attack for getting at the GPS receiver that just hadn't occurred to me previously: bypass the gumstix and try talk to it through a normal unix/linux box. This way I'd be able to spot if connecting and communication was working smoothly with the proposed utilities, before porting them all onto the gumstix.

Unfortunately, I don't have Bluetooth on my laptop, but thankfully John does! Ironically though, John's laptop decided to bork itself the very minute we tried to start testing. Fortunately, it was only a minor breakage (in terms of things I needed working, anyway...) and we were able to test out gpsd and gpspipe in communicating with the GPS receiver.
As previously mentioned, the first step to this is to bind /dev/rfcomm1 to the MAC address of the GPS:

# rfcomm bind 1 00:0E:6D:5B:41:05

From here we merely need to start the gps daemon (gpsd) with rfcomm1 as an argument, and begin piping (gpspipe) the data being produced by the GPS receiver.

# gpsd -n /dev/rfcomm1
# gpspipe -r

Everything appeared to be working fully, with a stream of information being printed to screen from the GPS unit. We didn't try too hard in deciphering the data the GPS was providing as this wasn't the main goal of the exercise, and making sure that these functions work on the gumstix is a higher priority at the moment.

With this small victory in hand, I decided to try and finally flash the gumstix file-system. Firstly, I added any necessary extra packages to the buildroot and recompiled; no problems there, and the file-system was ready. I transferred this new file-system over serial, which took an absolute age, but seemed to be a safer option than flashing over, say, SSH.
When the file-system arrived it booted with no problem, for which I was rather glad. Then I realised that the wifistix activity light wasn't flashing; for some reason it just wasn't working. Figuring that I may have left out a package in the buildroot, I went back to the configuration section but unfortunately nothing jumped out at me. I did read on the gumstix wiki, however, that wifistix support is not automatically enabled in some of the older gumstix revisions - I suppose this is an excuse to get a newer revision with, hopefully, some problems ironed out.

Unfortunately, I stayed up quite late with the transferring of the new file-system (I think this may have taken close to an hour for a 3mb file), and slept in for a team meeting; oh dear...

07 Bluetooth

2008-03-12T01:43:00.005Z

I finally got around to charging the provided Bluetooth GPS receiver last week; the given charger is a car charger, rather than a mains charger - a small hindrance, but not insurmountable. Once I got the unit charged, I took baby steps in testing the Gumstix's Bluetooth capabilities, attaching the antenna for the first time.
Scanning for nearby Bluetooth devices is fairly similar to scanning for WIFI networks. Using the single command:

hcitool scan

the Gumstix is able to list (with some accuracy) Bluetooth devices in the vicinity. I was able to pick up both my phone and the GPS unit with this scan; so far, so good. Apparently, some Gumstix revisions have issues with the default speed of Bluetooth communication, but thankfully I didn't run into this problem.

Scanning out of the way, pinging was equally little hassle. The scan had provided me with the MAC address and name of the Bluetooth device scanned, and pinging is another single command:

l2ping 00:0E:6D:5B:41:05

The first character is a lower-case L rather than a 1, and the characters following the ping are the MAC address of the GPS unit.

Things start to get a little hazy here.

On the Gumstix's Bluetooth wiki there is a guideline on setting up a GPS unit with the Gumstix system. Everything was pretty self explanatory until I happened upon mentions of "rfcomm bindings". A bit of reading lead me to understand that to establish a serial Bluetooth connection to another device (a "pseudo-tty" connection as one of the documents mentioned), we must use a Bluetooth protocol named "Radio Frequency Communications". Seems understandable enough, but it'll still need further reading to get fully.

Anyway, to help me get to grips with what the rfcomm binding actually did, I attempted to create an rfcomm binding to my phone rather than straight to the GPS unit, as my phone has an interface, and I'd be able to see if anything was happening. Yet another single command:

rfcomm bind 1 00:0E:6D:5B:41:05

The number after "bind" tells the Gumstix which pseudo-serial port to use, and the subsequent characters are, again, the MAC address of the destination unit.
I started to get requests on my phone for a connection to the Gumstix; excellent! However, they were looking for a PIN. At first, I tried entering nothing, but that lead me nowhere. Some more reading informed me that I'd have to set the security options on the Gumstix, which I considered doing until I located the PIN file in the "/etc/bluetooth" directory. Using the PIN in this file, I still couldn't connect my phone to the Gumstix, but when the PIN was entered it took slightly longer in refusing my connection, so I guess that's good; besides I'd established that the Gumstix was attempting to communicate with my phone; enough for the time being.

I tried the same rfcomm connection with the GPS unit, and it connected without hassle. However, the next steps listed on the wiki lead nowhere, as the command to start the GPS daemon (gpsd) failed, as it's not on the Buildroot revision on the Gumstix. I'll have to enable this, and the GPS pipe (gpspipe, handily enough) to get decent data from the GPS unit.
This means I'll have to flash the file-system ASAP if I want to get GPS set up, so I'll be doing this over the break. I'm going to enable C++ in the Buildroot also, as Semir's asked for it. I was considering putting python on, but I believe this takes up a good bit of space on the Gumstix itself because of the compilation utilities, and I'd rather keep the space on the Gumstix as free as possible, to avoid using the CF card and adding any extra weight.

That's about it for my recent activity. I weighed the components the other day for Donal: the GPS receiver, WIFIstix, Connex board, and Robostix weighed in at roughly 150g - not even eligable for Flyweight category in boxing, but an excellent weight for attaching to our blimp.

I'm off to Nice for a week, beginning Thursday. Work will re-commence upon my return!

06 Pictures

2008-03-04T21:26:00.007Z

As promised, this post will contain a mostly pictures of the system, and a few screenshots of the Gumstix in motion so, without further ado...

Here is the given Gumstix computer, with a ten cent coin placed tactfully nearby for size comparisons. This picture includes the mainboard, console board and wifistix, and would be capable of using Wifi, or connecting to a computer via serial.

Of course, just leaving the Gumstix sitting there is fairly pointless, so I connected it via serial port to one of our computers to get it set up. I used hyperterminal to set up a connection, using the information from this very useful wiki page

Having connected to the computer, I worked on getting wireless working properly on my home router, as discussed previously. Restarting the wireless connection a few times led to my happiness in seeing my given static IP popping up each time, so I was able to disconnect the serial board from the Gumstix and connect only the wifistix.

Of course, Murphy's law states that having bragged about getting a static IP working on the Gumstix, when I go to get a screen-grab of me SSHing triumphantly into the Gumstix, my laptop decides that it's not having any of it, so my faithful readers(!) will have to make do with a putty SSH.

So I've remotely logged into the Gumstix computer, which gets rid of many restrictions on the unit, as we now know what IP it will have each time it boots which means that we don't need the serial connection unless we're flashing the file-system, or changing the wireless information. Also, in testing the cross-compilation toolchain previously mentioned that comes with Buildroot, I had to SCP (secure copy) the compiled binary from the host machine onto the Gumstix, which confirmed that transferring files between host computer and Gumstix is very easy.
Finally, here is the little "Hello World" C program at work on the Gumstix computer. I'll be working on trying to cross-compile more advanced programs next, as well as working on the Bluetooth aspect of the project.

So that's about it for pictures. I'll have a few more screengrabs and hardware pictures when I start working on the Bluetooth aspects of the project; the cross-compiled programs will likely speak for themselves.

Right now though, I'm planning on setting up a TODO wiki page for the project on the CSI trac (which I'm not finding half as useful as the old GForge page, unfortunately).

Over and out!

05 Intermission

2008-02-28T21:09:00.008Z

Due to some exams and assignments this week, unfortunately I didn't get much of a chance to work on the system. I'm going to try and get some pictures up of the unit and its functionality tomorrow, however.
Next on the plans is checking the system's Bluetooth capability. I'll start out small on this at first, as big steps can lead to big problems, and I'm not really familiar with working on Bluetooth devices. The Gumstix Bluetooth wiki specifically mentions how to connect to a Bluetooth GPS receiver, which will obviously be useful once I get the Bluetooth running and scanning stuff. The wiki also links to a freely available PDF of a chapter from the book Make Projects: Small Form Factor PCs, which seems to deal with the Gumstix's Bluetooth capabilities. If so, it'll be a must-read.

Apart from the Bluetooth, I'll have to check the cross-compilation capability for a C program more complex than "Hello World", and the C++ cross-compilation capability also, as I'm not sure whether our revision has the ability to run C++ out of the box (my gut feeling says no). I believe we'll be using C for controlling the servos (although this isn't set in stone), but it may be beneficial to use C++ for some of the other aspects of the system's development. If C++ isn't present on our revision, I'd imagine that putting a newer buildroot on the system will solve the problem, which I'd be more than willing to do if it made anyone's life easier.

It also seems that we need no longer set up a WIFI repeater on the Gumstix system, as Donal has located one that communicates with a base-station unit located near the router providing the WIFI. Now all we need to do is take the weight of the repeater into consideration when calculating the overall weight of the system. This will take some of the work off the Gumstix set-up and maintenance, and gets rid of the problem of the Wifistix not being able to act as an access point. So that's one hurdle overcome!

To end this post on a good note - we've received the go-ahead to order a (suitably sized) blimp for the project! Obviously, excellent news, as the blimp is essentially the raison d'être of our project.

04 Buildroot

2008-02-25T14:26:00.010Z

As mentioned, my first buildroot download was less than successful. This was more than partially my fault as I set about downloading the buildroot package before reading the entire buildroot wiki page, and some supplementary articles, all of which mentioned that the latest version of buildroot (which is downloaded by default if a revision is not specified) may not be stable. Great.
Since it was mentioned that running the makefile supplied with buildroot takes rather a long time, I killed the latest version in its tracks, and set about downloading the version corresponding to the Gumstix system's version - I figure that, to begin anyway, I might as well try and use the given version and only upgrade if it's needed.

This package seems to have not downloaded properly, probably due to me not cleaning out the folder of half-built files before running the new makefile, so I cleared out everything and started afresh.
Keeping with the buildroot wiki, I did the following in order:

Step 0:
svn co -r 1161 http://svn.gumstix.com/gumstix-buildroot/trunk gumstix-buildroot

1161 being the buildroot version currently on the Gumstix. Then it was just a case of running the makefile.

Step 1:
cd gumstix-buildroot
make defconfig
make

and that was that. Granted, the final make took several hours, but it's all automated, so I left it running overnight.

Since I'm not planning on replacing the file system - not yet anyway - I went straight to the programming wiki page, and whipped up a c "hello world" to cross-compile. I copied this sample makefile, which seems a bit confusing and will need some deciphering, and compiled my program. A small scp later, and our Gumstix system was greeting the world.

03 Wireless Woes - Part II

2008-02-25T01:22:00.004Z

Having connected the Gumstix to the router, I decided to try getting a static IP working on the system. Thankfully, the hard part of connecting was over, as a brief look at the Gumstix Tutorial gave me the information I needed. Again editing the /etc/network/interfaces file, I commented out:

iface mwlan0 inet dhcp

and replaced it with

iface mwlan0 inet static

which was obvious enough. After this I just added values for the static IP I wanted, the netmask, and the gateway, and everything was up and running as expected, excellent!

Well, not quite.

Somewhere along the line, I've no idea where, I'd picked up a new wireless network on the block: one with the exact same name as my current one, but in ad-hoc form. Puzzled, I instantly assumed the Gumstix was responsible; it is, after all, the newest system, and one with which I've no experience - perhaps I'd inadvertantly set up an ad-hoc network. Unplugging the Gumstix, however, did not seem to affect the network.
Next, my thoughts turned to dad's laptop. Perhaps, in his need to get online, he'd inadvertantly set up an ad-hoc network! This turned out to be a red herring too.

At this stage I was becoming rather annoyed: my minor success with the Gumstix was being tainted by a tough, unruly ad-hoc network that refused to die. Maybe someone outside was trying to trick us into connecting to this network instead of our own for some reason? It seems not; no unmarked vans parked across the street.

Turning off all computers in the house also failed to solve the problem...initially. Then, as quickly and mysteriously as the network had appeared, it was gone!
Numerous "iwlist mwlan0 scanning" calls on the Gumstix (every five-ten minutes for the past hour) turned up nothing except my own, trusty router.
Very odd, indeed, but probably something of my own doing.

So, after all of this drama, the Gumstix is up and running on my own router, with encryption and a static IP. I may attempt to cross-compile something tonight, as the buildroot seems to have completed successfully this time, but all this ad-hoc chasing has worn me out.

02 Wireless Woes - Part I

2008-02-25T00:46:00.006Z

In keeping with posting all aspects of my learning, this post will deal with my experience in setting up the Gumstix for use with my home router, along with some very odd issues along the way.

The day we received the Gumstix system, I wasn't present during the demonstration. I was informed, however, that the system was up and running on the college wireless network, with a computer connection via serial, within moments, and was scanning Bluetooth devices nearby with equal ease - excellent, I thought to myself.
That night when I arrived home, I attempted to get the system working with my home router, optimistic that it would work right off. Of course it didn't.
I'll hold up my hands and admit that I was being foolish in thinking I could plug it in and all would be well, obviously there would be some issues with WEP keys and the rest. So, just to ensure that I could get wireless working at all, I turned off my router's encryption for a few minutes and, low and behold, the Gumstix picked it up and connected. I SSHed in, messed about for a minute to make sure all was well, and then exited.
So ended my first foray into Gumstix wireless.

Yesterday, having downloaded buildroot on my laptop's Ubuntu, I decided to get a simple "hello world" cross compiled, to put onto the Gumstix, to make sure all was well. Once again, I disabled the router's encryption, and fired up the Gumstix; everything working again. However, it turns out that the buildroot download was not successful and my little program failed to compile, so I set about downloading buildroot again, and turned off the Gumstix for the night. Unfortunately, I forgot to reset the router's encryption. Not that big a problem, as long as some unscrupulous individual doesn't notice, but it seems to have lead, indirectly at least, to some rather annoying issues, as will be described in part II.

The following morning my dad mentioned, in passing, that the wireless wasn't working, so I reset the router's encryption and set about getting the Gumstix working on it. A bit of searching through Nabble's Gumstix forum lead to this post. Given this information, I commented out this given line in /etc/network/interfaces:

pre-up /sbin/iwconfig $IFACE essid any txpower 100mW

and replaced it with:

pre-up /sbin/iwconfig $IFACE key XXXXXXX key open essid "My_Network" txpower 100mW

as was advised in the above linked post. It worked like a charm, and I was up and running on my router. God bless Dave Hylands, I can see his (many) posts helping me more than this one time.

Next up was getting a static IP working on the system.

01 Team and Project Background

2008-02-20T14:54:00.005Z

As mentioned, the reason I'm using a Gumstix computer is because I am currently undertaking a project with three others; Dónal, John and Semir, with the aid of a teaching assistant, Graham.
Our project proposes to use a small, lightweight blimp to carry a Gumstix computer equipped with a Wifi repeater and GPS system. The Wifi repeater will enable the provision of wireless connectivity to areas in which setting up a fixed wireless network would not be feasible, while the GPS system, coupled with attached motors, will enable us to control the blimp's movements and set destinations for the blimp to travel to.

We must demonstrate a fully functioning system before the college will supply us with a blimp, so it is imperative that we set up the system as soon as possible, and create a simulation to show that the motors, GPS and Wifi repeater function as expected. A document containing the details of the simuation system is currently in progress.

00 In the beginning...

2008-02-20T14:16:00.005Z

To begin, a short introduction: I am Cillian Murphy, a third year Computer Science & Economics student in University College Dublin.

This blog will chart my learning, progress, achievements, and failures in managing a Gumstix computer system, which was provided to us for our team's current software engineering project - more on the team and project later.

This will not be a foolproof tutorial in how to set up a Gumstix system, as I will chart all failures as well as successes. Where possible, I will endeavour to post any methods I use to solve problems I encounter, and will try to refrain from posting failures without a solution, or an idea of how to solve them - hopefully to avoid misleading anyone who might stumble across this blog and take it step-by-step!

So, let's get started...

EDIT: As per a request from a course lecturer, anything particularly interesting in our setup (bluetooth GPS system, I'm looking at you) will likely be posted to this wiki