Why user interfaces in space should be simple

On the Apollo 11 mission to the moon, the interface to the computer was simple. Known as the DSKY, (DiSplay and KeYboard), it was exactly that, a simple keyboard with 19 buttons and a display.

The DSKY

Inputting instructions involved converting the English words to a verb-noun pair, which were subsequently input as numbers. The noun referred to a device, the verb indicated the action to be taken [1]. For example Verb 37 was “Change major mode to”, which was used to change programs. To input a number would require the following sequence:

VERB number NOUN number ENTR

List of nouns and verbs

So when Buzz Aldrin issued the command 1668, he was issuing the verb 16 meaning “monitor decimal” and the noun 68 meaning “RNG(+Z),TG(BRK),VI[.1NM.M:S..1 FPS]” [2]. The 68 returned “ground range to landing site”, “time to go in braking phase”, and “absolute value of velocity” [3].

It seems overly complex, but in reality it isn’t.

Want to try it yourself? See how usable the interface is through this simulator.

[1] https://www.hq.nasa.gov/alsj/alsj-CSMdocs.html

[2] http://www.ibiblio.org/apollo/FabrizioPresentationPhotos/A17_VN_Checklist.png

[3] https://www.hq.nasa.gov/alsj/a15/a15LMDSKY.html

Debunking TV technology: Deblurring and enhancing photographs

This is one of my favourite debunks, largely because it is SO nonsensical: enhancing an image through deblurring, or image sharpening. As an example, I turn to Rizzoli & Isles episode “Tears of a Clown“. They are using a piece of video footage to once again find the location of a house. While searching through the video, one of the detectives says:

“Hey freeze it there”… “is that a window?”

Followed by the other detective saying: “I can enhance the image”

The original image is nothing but a blurry mess. Yes, there could be a window there, but considering it’s a house, and there is light coming in, it’s either a window, or a door. There is no way of recovering detail from such an image. To do that, you need more information than a small piece of video. Okay, sure it is possible to remove some forms of motion blur from an image. Blurring can  be described mathematically by the convolution of an image with an entity known as a point-spread function. So theoretically, blur can be removed if the point-spread function is known, however this deblurring is an ill-posed problem. It’s the result of optical blur caused by incorrect focus, or rather a shallow depth-of-field. Things close-up are in focus, those further away are blurred. We could try sharpening the image, but no algorithm would be able to recover the full detail – unless you tried matching against a slew of images taken from people’s basement (if such a database would exist, which of course it doesn’t).

Note also that the original blurred image only has dark information around the lower and right hand portions of the image. There is nothing that would indicate grilles in the window – so where did they come from?

Remember, Garbage in – Garbage out.

Here’s another case. In Numb3rs, episode “Pandora’s Box”, the team investigates a plane crash and the shooting of the forest ranger who discovered the crash. Charlie uses “wavelet deconvolution” algorithm to identify a smudged fingerprint, allowing them to identify the person who tampered with the plane’s software. It may be possible to remove some forms of blurring from a smudged fingerprint, if one assumes the blur is similar to the motion blur found in photographs. Blur of a more random nature may not be so easy to remove.

 

Logging on to a Raspberry pi remotely

For anyone who has a Raspberry Pi (rPi), and wants to access it without having to attach a monitor and keyboard, here are some basic instructions on how to do that. A rPi just by itself is known as a “headless” rPi.

So first a little background. A computer attached to a network always has an IP address associated with it. An IP address is a number of the form 172.16.254.1 .Most networks these days use DHCP IP address assignments, which means that each time a device leaves the network and returns, a new IP address is assigned to it. Each hardware device also has something known as a media access control address (MAC address) which is a unique identifier assigned to network interfaces for communications on the physical network. A MAC address looks like this: B8:27:EB:F2:37:11

So accessing a headless rPi basically involves attaching the rPi to your (wireless) router via the ethernet port (hard wired). Once it is attached to the router, it will be assigned an IP address. With this you can access the rPi and login to it. How do you go about finding this number? So if you have a Mac, you can use a program called Pi Finder. An alternative is to login to the router itself and look up the device table. The rPi will be the one with a MAC address that starts with “B8:27:EB“.

A third way is to find the rPi’s IP address is to use the utility nmap, which is available for OSX, Windows and Linux. Once installed, the following command can be issued on the command-line:

sudo nmap -sS 192.168.0.*

This will find all the devices on the local network, and return information about them. Note the use of the sudo command before nmap. This allows the command nmap to be run as root, the superuser. Why? So it actually displays the MAC address, so you know which IP address belongs to which device. It will prompt for a password – on a Macintosh this is the administrators password. The information generally looks like this:

Nmap scan report for 192.168.0.111
Host is up (0.0040s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
22/tcp open ssh
MAC Address: B8:27:EB:F2:37:11 (Raspberry Pi Foundation)

On the first line you can see the IP address to use. Now it’s as simple as using the command ssh to login to your rPi:

ssh pi@192.168.0.111

where pi is the default user on the Raspberry Pi and raspberry is the default password (note: change the password the first time you log in).

The wildcards in Unix

Although the command line makes Unix über powerful, it is really the subtleties of things such as wildcard characters where the true power lies. Here are two: * and ?

The asterisk, *, matches zero or more characters. For example, a* matches the files a , ab , abc , abc.d

The question mark, ?, matches exactly one character. For example, a? matches aa , ab , ac , etc.

For example, to find all the files ending in .sh in the current directory, using the find command:

find . -name '*.sh'

To list all files that begin with “f1”, but have any value for the third position using the ?:

ls f1?

Or, you can combine the two:

find . -name '7_1?0.*'

In this example find will find all files that begin with “7_1”, have any character for the 4th term, have “0.” for the next two terms, and any terminating characters (either in type or length).

Overflows in space

So when things don’t work so well with programs, sometimes you get an overflow. In the more traditional sense of the term, it refers to an attempt to store a large number in a piece of memory not capable of holding it, i.e. there isn;t enough memory. What you don’t want is this to happen during some critical operation. But that’s what happened on the Apollo XI mission during the landing on the moon phase. The recordings of the landing contain references to “1201 alarm” and “1202 alarm“. The 1201 referred to an “Executive overflow – no vacant areas” whilst the 1202 alarm was “Executive overflow – no core sets“. What did this mean? Well, firstly it had more to do with processor availability.

It turns out that the astronauts checklist required the rendezvous radar to be turned on before initiation of the descent. This caused the 1202 alarm, because the radar was stealing processor cycles, and the computer was required to do too many things.  On landing approach, the CPU was suppose to have a load of 85%, however the radar reduced the available cycles to 13% of the processors time [1]. When the command 1668 was issued by Buzz Aldrin to calculate the “difference between altitude sensed by the radar and the computed altitude”, the extra 10% overflowed the processor’s ability, prompting the 1202. Fortunately the system had “priority scheduling”, which allowed non-critical low priority tasks to be deleted, and allow critical tasks (such as the landing) to be completed.. A short while later the 1201 alarm appeared. Followed by more 1202 alarms. At 650 feet, Armstrong took the lander autopilot off AUTO, reducing some of the load on the system (which still controlled the rate of descent), and successfully landing the lunar lander.

The moral of the story? Not every error or warning will appear during the testing phase of a piece of software.

Check out the whole story of the landing on Don Eyles webpage.

[1] http://njnnetwork.com/2009/07/1202-computer-error-almost-aborted-lunar-landing/

Changing file permissions in Unix

So now that we know what file permissions are, how do we change them? Using the command chmod. 

In its simplest form, the command is used in the following manner:

chmod who=permissions filename

The “who” is a list of letters specifying who you’re going to give permissions to. Will it be the user, group, other, or all of them? The permissions are the same letters you see in the directory listing: r, w, x. So consider the example from the previous post:

To change the permissions to allow members of the group staff to modify the file josephus.c would require:

chmod g=rw josephus.c

To remove permissions from others for the directory codePython:

chmod o= codePython

The permissions here are empty, meaning they are all removed. An easier approach is using a shortcut version of chmod. This allows the use of + and – in place of the =. So modifying the permissions to allow members of the group staff to modify the file josephus.c would require:

chmod g+w josephus.c

And similarly the directory could be modified in this manner:

chmod o-rw codePython

If you want to be trickier still, there is a shorter shortcut, which uses numbers. This is sometimes known as octal mode. Each permission is given a value, for example read=4, write=2, execute=1. So to change the settings for the user, group and others, to read-write-execute could be achieved in the following manner:

chmod 777 josephus.c

The 777 represents the permissions for the user-group-other: 7 = 4 + 2 + 1. To make a file only read-execute would make the value 4+1=5, So 550 would result in permissions of the form r-xr-x—.

Basic file permissions in Unix

Is it crazy to say that Unix created file permissions? DOS never had any, and the ones in Windows were added as an afterthought. Permissions in Unix means I can dump something in the /tmp directory and have it available to all… or not. And 30 years ago when disk space was still precious, /tmp was often your friend if you had large files. So what are file permissions? File permissions constrain who can look at your files, and what actions they can perform. Let’s look at the basic structure. Perform a directory listing using “ls -la” and you will get something that looks like this:

There is a lot of information in those lines. Concentrating on the first half of the listings:

This listing has two items. The first is a file, the second is a directory. This is identified in the first character of each line. The next series of 9 characters represents the file permissions (ignore the trailing @). Next comes the number of links the file has (we won’t worry about this), the username, and the group the user belongs to. Every user belongs to a group. The example above shows that the user mwirth belongs to a group called “staff“. Now let’s look closer at the permissions. Permissions have the following form:

The first three permissions belong to the user, the next three to the user’s group, and the last three to all other users. The values r, w and x refer to read, write and execute permissions respectively.

• Read grants the capability to read i.e. view the contents of the file.
• Write grants the capability to modify the contents of the file.
• Execute allows the file to be run (so is only relevant for programs).

With respect to directories, read means the user can read the contents of the directory, and write means they can add or delete files to the contents of the directory. So how does this translate to what you see in the listing? Consider the permissions for the file josephus.c :

rw-r--r--

This means the user can both read and write the file, and both the group and other are restricted to reading the file. Neither party has the ability to make changes to the file, or execute it. Presence of the – signifies that the particular activity is not permitted. As this is a C program source file, there is no need for a execute permission, as it is not possible. Now consider the other example for the directory codePython:

rwxr-xr-x

This means that the user can read, write and execute files inside the directory (depending on the files individual permissions), but both the group, and others can only read, and execute files, meaning they have no ability to modify files, or delete them.

If you give a file permissions of rwxrwxrwx, you are basically giving carte blanche access to the file. This is never a good thing.

 

Killing programs softly

OSX has a command in the Apple menu called “Force Quit…“. All this does when you select a program, is kill the process ID. Confused?

Okay, so when you run a program, the operating system (e.g. OSX) associates a process-id (PID) with the program, basically so it can keep track of it. Sometimes when you run a program, and it hangs for some reason (i.e. stops working, but does not quit) it needs to be terminated. Ctrl-C may not work, so the easiest way to kill the program is to run the command ps, which returns the status of the current running processes. For example, you might get something like this:

>ps
 PID TTY        TIME CMD
3004 ttys000 0:00.37 a.out

By typing kill -9 3004, the PID 3004 is terminated, meaning the program a.out is terminated, gone, vamoosed! Kill works in the following way:

kill PID_to_terminate

This basically sends the signal TERM to the process, telling it to terminate nicely, cleaning up anything it needs to. If this doesn’t work – and sometimes sticky processes can be somewhat stubborn, a more intensive KILL signal can be used:

kill -KILL PID_to_terminate

But this time, things aren’t as pleasant, and the signal is sent to the kernel instead of the process itself. The kernel will shutdown the process. The -KILL is equivalent to -9.

Now ps won’t tell you everything. It won’t show all the programs running. For that you can use top. The top chunk of information shows a myriad of system statistics – system load, no. of running processes, no. of sleeping processes, CPU usage, etc. The bottom portion shows the actual processes running, or in stasis (a.k.a. idle). Probably more information than the average user needs, but you never know.

 

 

 

The software on Apollo missions

The Apollo missions may have heralded one of the first real attempts at creating a large piece of software to control a physical object. In the case of the Apollo missions this meant navigation. Modern software engineers would be dumb-founded by the lack of formal process. But one has to take into account that this was the 1960’s and the field of software engineering had not yet established itself. Indeed many still considered unstructured programming to be the norm. The Apollo XI mission consisted of 145,000 lines of code written for the Apollo Guidance Computer (AGC). It was written by MIT’s Instrumentation Laboratory. The programs were written in a language called MAC (MIT Algebraic Compiler), then translated by hand into assembler, typed onto punch cards.

The most interesting thing? The only type of reliable memory was rope-memory – constructed by looping wires through a core and around a core to represent the 1’s and 0’s of programs. Each program had to be hand-woven, and took several months to create. The entire memory capacity? about 64Kb – that’s kilobytes. The computer itself ran at 0.043 MHz.

Core rope memory (Courtesy of NASA)

The code was likely not the most efficient in the world, but took flight on the Apollo 8 mission in 1968. It successfully helped navigate the spacecraft around the dark side of the moon (where it couldn’t be controlled by radio waves). Its main aim though was the lunar landing of Apollo XI. In fact the piece of code that performed the landing? It was never tested in space, and it was one of the most complex pieces of software written for the Apollo missions.

Want to look at the code? It’s all here, and is actually very readable (more so if you know assembler of course!) Read more about the software here.

Hackable cars are a reality

Cars are full of computers, hidden away in the recesses of the car body, controlling things. Now imagine driving down a highway at 100km/h when your car all of a sudden comes to a stop. Guess what? Your car has been hacked! If you think this is science fiction, then think again. There are numerous articles on the net detailing how cars can be hacked, like this one from WIRED magazine on hackable cars. Why are cars so hackable? Firstly most modern cars contain anywhere from 50 to 100 computers controlling critical components such things as steering, acceleration and brakes. But usually these aren’t very smart computers, i.e. they don’t authenticate where messages are coming from. Secondly, most of these systems are interconnected, so breaching one means its easy to gain access to others. Hackers could access a car’s core control computer by creating a schism in the Internet-connected entertainment  system and tamper with the steering. This article in Forbes by Andy Greenberg also shows the ease at which a car can be hacked.

These cars were quite safe in the 1990s, when cars were a closed box, but the addition of internet has turned them into a Pandora’s box of hack-ability How complex are these cars? Consider the code that sent Apollo 11 to the moon – 145,000 lines of code (LOC). NASA’s Curiosity Rover mission to Mars? 2.5 million LOC. The average modern car? 50-100 million LOC. The problem? Too much code, and likely code that isn’t built to the same standards as that found in banking applications, or the aerospace industry.

The most hackable cars? The Cadillac Escalade, Jeep Cherokee and Infiniti Q50. What makes them so vulnerable? They have a large wireless “attack” surface – things like Bluetooth, keyless entry, and wi-fi. These can be used by a hacker to gain entry into the system. Next the network architecture – how tightly coupled are these wireless entry points to critical systems, and the cars cyberphysical features, like parking assist.

Truly quit frightening.