11 This is the End

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

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

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

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

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

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

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.