Anthology of Interest

Tamara has been pestering me to write a blog entry. Thus the "engineering failures" entries below. The NEAR Shoemaker one is my favorite.

We started playing Ultimate on Tuesday nights. The first game was last week. It was the first time I had played a team sport since grade 10, which was almost nine years ago. It was also the first time I had done any significant running... since grade 10. Well, apparently cycling doesn't do a whole lot for the muscles you use while running. I can ride 80km and not feel muscle sore, but an hour and a half of Ultimate left me dead, and I was sore until Saturday or Sunday.

Today was our second day. Some how I managed to tweak a muscle or something this weekend, even though I did practically nothing physical. Running today killed, but I understood what was going on a little better and was able to make a few plays.

On the code front, my FDTD simulation Phred is coming along. I'm going to stop tool building are start simulating actual structures soon. Yay! I guess that means I should get some more work done on that thesis too....

NEAR Shoemaker suffered a nearly fatal failure on December 22nd, 1998, at 22:00 UTC, as the spacecraft was executing rendezvous burn 1 (RND1). The failure caused mission control to lose contact with the craft for 27 hours, after which NEAR was found in it's lowest safe mode, Sun-safe-rotate. Controllers were able to figure out a way to get NEAR to it's target, the asteroid 443 Eros, but with a significant time penalty and a very narrow fuel margin. The only permanent damage suffered by the craft was a contamination of the multispectral imager's optics by propellant residues.

The Mars Pathfinder mission, while widely proclaimed to be flawless, actually had a small bug in the scheduling code which handled tasks while the craft was operating on the surface of Mars. This bug caused intermittent computer resets, each of which resulted in the loss of data.

The Mars Climate Orbiter (MCO) fired its main engine at 09:01 UTC, September 23rd 1999, to begin orbital insertion into Mars orbit. Telemetry with the craft was lost five minutes later as it was occulted by Mars (went behind Mars as viewed from Earth), but communication was expected to be recovered twenty minutes later when it was supposed to reappear from behind Mars. No signal from Mars Climate Orbiter would ever be heard on Earth after 09:04:52 UTC, Thursday, September 23, 1999.

The chain of events leading to the destruction of Ariane 5's maiden voyage, flight 501, began well before the launch. When the launch vehicle is sitting on its launch table, on-board computers use inertial measurements to make sure the vehicle knows its exact location on Earth. The rotation of the Earth and the sway of the vehicle in the wind must be taken into account so that the launcher can precisely place its payload in orbit. Instruments take measurements of the accelerations the vehicle is experiencing, and the Inertial Reference System (SRI) computer takes this information does a few operations on it, and then passes it to the on-board computer, which uses it to compute the position of the vehicle. Once the vehicle lifts off, it is no longer necessary to compute where the vehicle is on Earth, but the computers continue to analyse the data for about forty seconds after liftoff. This only occurs because it was required for Ariane 4, from which Ariane 5 inherited its tried and true SRI units. However, Ariane 5 operates on a different time line and flight path than did Ariane 4, and the software running the SRI units on Ariane 5 wasn't changed to take this into account. This was largely because the SRI units were believed to be the most reliable parts of Ariane 5 since they had already been extensively tested on Ariane 4.

After flight 501 lifted off, the vehicle experienced accelerations much greater than it did on the ground. Because the accelerations are much greater, the numbers used to represent accelerations in the SRI computers became very large. About 39 seconds after liftoff, the number related to horizontal acceleration became so large that when it was converted from a 64 bit floating point number to a 16 bit integer so that it could be passed to the on-board computer, an error occurred, which caused the SRI computers to shut down. Ariane 5 is equipped with two SRI units, so that one can take over if the other fails. In this case, both units failed in exactly the same way, so the data received by the on-board computer was not correct data, but instead a diagnostic pattern generated by the SRI computers after they had shutdown.

The on-board computer interpreted the diagnostic pattern as flight data, and that caused it to incorrectly command the engine nozzles on the solid rocket boosters and on the main engine to deflect as much as possible. For the rocket, this was like making a very sharp turn in a car that's moving very fast; the car will roll, or in Ariane 5's case, large aerodynamic forces caused the solid rocket boosters to separate from the main stage. At this point, Ariane 5 did what it was supposed to; it exploded.

An inquiry into the failure of flight 501 found the defect in the ADA code that performed the unprotected type cast, and the larger design defect that allowed that specific bit of code to run after Ariane 5 had lifted off. These defects were fixed, and haven't bothered Arianespace since.

References

I wrote this a long time ago. I have lots of other engineering / space stuff that I wrote up for a web site a few years ago, so I thought I would post some of it here too.

I tried to ride my fixie up Mt Douglas this afternoon. I got maybe a third of the way up by zigzagging and huffing and puffing as I have never before huffed OR puffed. Then I went a little too far on to the shoulder of the road and my front tire slid out when I tried to zig my zag. So I ended up pushing it the rest of the way up. Which is probably good, because it didn't get any less steep, and my heart and lungs would have given up sooner or later.

So I took some pictures and walked around, then headed down. There were actually quite a few people up there. On the way down, there were cops and fire trucks and ambulances, due to someone having managed to flip thier car. I'm not sure how they did it... but maybe people can take a look at the picture I took and offer a theory.

I took the "seaside" tour route, which offers very little in the way of seaside and rather a lot more in the way of residential side streets. I wanted to find my way to University by a certian route that avoided "Cardiac Hill", but unfortunatly I found myself at the bottom of... Cardiac Hill. I should have taken my map with me. I couldn't make it up Cardiac Hill last time I tried, and had to push this time too. Gah.

Oh well, by the time I can make it up Cardiac Hill and Mt. Douglas on my fixie, I can be sure that I have made significant gains fitness wise.

In case you think me mad, the Victoria Wheelers cycling club holds hill climb competitions, which seem to have been annual up until 1999. The Mt Douglas one was done in record time in 1999, 5:02. A goal to aim for I guess (haha).

Interesting paper about people who are incompetent and in denial, and thus unable to recognize that they can and should improve.

Of course, I am not incompetent....

Something I spotted in Debian's new package listing the other day: DevHelp for GTK+ and friends. It's basically just a little web browser app that has a side bar for searching and a table of contents, but I find it easier to use than the documents on the web. It also nicely collects everything into one place.

So if there are any GTK+ coders reading this, try it out.

If you don't already have enough ways to waste time, try weboggle. It's like boggle, but on the web. It's strangely addictive, and makes me realize how limited my vocabulary and pattern matching skills really are.

Tamara, ignore this post. You never saw it. It is not here.

Tamara! Stop playing! You're kicking my ass!

While I'm talking about photos, I want to mention gThumb. gThumb is an image viewer that I've been using for a long time. I've used it's predecessor GQView, before the gThumb code base was forked and converted to GTK+ (at least I think that's what happened).

GNOME's default image viewer, Eye of Gnome, kind of sucks. It was totally unusable back in the day (before GNOME 2), and kind of works ok now, but is still not very good. gThumb kicks EOG's butt all the way.

gThumb does lossless JPEG rotations (although they really need to be on the toolbar, and they really need to be mapped to a hotkey; it's a really common operation!), photo album generation, and it's a good all round viewer.

I do wish the catalog support was a little better. I've been treating catalog like albums; all the pictures from a given day are put in a specific directory, and the good ones are put in a gThumb catalog. Then the catalog is used to make a web album. Adding pictures to catalog is a little onerous unfortunately, but not too bad.

Comment editing is a bit weak as well. It would be nice if one could edit comments in the photo properties dialog, but you can't because gThumb comments are not stored in the EXIF data for the file. They are stored separatly instead. That is the sensible thing to do if you want to be able to add comments to files without EXIF data in them, or to files which are in a format that does not allow for EXIF data.

Since catalog and comment data is not stored in the image file, moving files or renaming them outside of gThumb basic leads to losing any info that gThumb has attached to that file. If might be nice for gThumb to be able to manage "repositories" or "libraries" of photos, where it has complete control of the directory structure and metadata that goes with the images.

I propose libraries or repositories because it would be handy to be able to put all that data in different locations depending on disk space availability etc. It would also make it easier to set up shared photo libraries. That would be extremly useful on the iBook, where my wife and I have to manually copy files between our two iPhoto libraries, when we should be using only one copy. Using libraries would also make it possible to break up the amount of data that the program has to deal with at any one time; I've read that iPhoto does not deal well with extremely large numbers of photos.

The file system could be treated as a library, where the meta data such as comments and categories could be either disabled or stored the way it is now. I think being able to browse through the file system is one of the most useful things about gThumb. Perhaps my greatest annoyance with iPhoto and iTunes is that it is not possible to work with a file unless it has been imported into the respective program's library.

I whipped up a little Python script to take the photos off of my digital camera the other day. It looks for a directory in a photo library location named for the current date in ISO standard format (YYYY-MM-DD), except without the dashes, and copies the pictures off of the camera.

It is run by the Linux hotplug system; the kernel runs /sbin/hotplug when a USB device (such as my camera) is plugged in (but it could be a firewire, PCI, etc device). The /sbin/hotplug script looks at the data it recieves from the kernel via environment variables, and thinks to itself, oh, I'll run /etc/hotplug/usb.agent.

That script then looks for the vendor and product ID of the device (among other flags) in /lib/modules/XXX/modules.usbmap and /etc/hotplug/usb.distmap, which are indexes of all the devices that the various modules that the currently running kernel knows about. Sometimes new devices will work with older modules, and it is necessary to add information manually, so it will also check for the device in /etc/hotplug/usb.handmap. If the information is found in any of these locations, the named driver is loaded into the kernel if it is not already.

It's pretty handy to be able to run scripts when devices are detected... such as copying all the photos off of the digital camera. That's where the /etc/hotplug/usb/*.usermap files. They map USB vendor and product IDs to names of scripts to run. All such scripts have to live in /etc/hotplug/usb. They should be owned by root and should not be writable by people other than root. This is because they are run as root, and thus pose a certian security risk.

So now my script. It's written in Python, as I mentioned, and it uses gPhoto2 to actually talk to the camera. It's lacking somewhat in error detection, if it is run without the camera actually being connected for instance, and it doesn't check for duplicates or anything, but it works. It writes a little log file about its conversation with the camera to /var/log/photo_import.

You can get it from this link right here. I hate it when people make links like that. Oh well.

A nice thing I've notice about this method over importing photos into iPhoto is that it doesn't put the camera in view mode. It just starts downloading, and keeps on downloading until it is finished. iPhoto leaves the camera in view mode, and if there are a large batch of files to be downloaded, the camera tends to shut off half way through. The only way to keep it from turning off seems to be to flip through photos occasionally as the download occurs. Maybe that's just a perculiarity of my camera though.