Department of Machine Intelligence and Perception (DMIP)
University of Edinburgh
1969 -1975

Freddy: some background history, from a personal viewpoint 

================================================

I did an MSc and a PhD in Donald MacKay's Department of Communication at Keele University. (You may know his son, David Mackay at Cambridge.) At the end of my time at Keele I wrote to Donald Michie inquiring whether I might join the Department of Machine Intelligence. I was invited up for an interview at Hope Park Square in the summer of 1969 (I recall). I thought the place was very exciting, with some interesting people. Robin Popplestone gave a talk - I don't remember the topic - and then he talked informally about ideas for robot research. Robin had a toy tank controlled by a wire, and was thinking about hooking it up somehow to the computer (Elliott 4120 with 64K 24-bit words at that time).

 

At some point I believe I talked about the work I had done at Keele, trying to understand the human sense of touch using computer-controlled stimulation equipment. My supervisor, Pat Wilson, had built a tactile stimulator that was based on an IBM print head with an array of 5x7 pins (about 1cm x 1.5cm) for which he had built 35 vacuum tube drive circuits. It fell to me to interface this equipment to the Department's PDP-8 computer (8k of 12-bit words) and write the assembly code to drive it. I also wrote a system to run psychophysical experiments, presenting patterns via the stimulator to a subject and recording the responses and response times, and analyzing the results. This was my first real sleeves-rolled-up involvement with computers. [As an undergraduate at Cambridge I had been allowed to write one program in Autocode for EDSAC II, which had vacuum tubes and 1 inch diameter ferrite core memory.] I had a lot of fun at Keele doing various things like reverse engineering the Fortran compiler and run-time system and then extending the functionality. I also wrote a mag tape-based bibliography management system that was still in use 10 years after I left.

 

Anyway, the folks in the DMIP must have thought all this was relevant, so after my visit I got a letter from Rod Burstall. He said they had just received a disk for the computer and were wanting to modify the Multi-Pop timesharing system to use it, so did I think I could do that? This was a bit of a disappointment because I really wanted to work on AI and robotics. I had no idea what was involved, but thought I could learn, and at least this would be a way into the Department, so I said "yes".

 

When I arrived to work at DMIP I was told "We've already got someone working on disk-based Multi-Pop (Ray Dunn and Dave Pullen), but we have this robot that we've built.. Do you think you could interface it to the computer?". The robot was Freddy I, a vidicon TV camera on wheels. Steve Salter had built the mechanics, and he subsequently built a sample-and-hold circuit for the TV signal, but he did not know about computers and digital electronics, so I had to design and build the digital side of the system.

 

The first task was to design and build an interface to the computer. The Elliott 4120 had been upgraded to a 4130 and moved from Hope Park Square to a computer room on the ground floor of Forrest Hill. It was maintained by ICL (who had taken over Elliott Computers) who were extremely nervous about us connecting home-made hardware to their computer. There were two key problems. First, they wanted the interface to be "bomb-proof"; they wanted it to withstand the accidental connection of mains 240 V AC to the inputs! Second, because the I/O hardware performed asynchronous handshaking, the peripheral could hang the entire computer if it failed to respond; the interface had to autonomously abort the transfer if the peripheral failed.

 

To solve the first problem, Stephen Salter suggested we use two semiconductor rectifier diodes to shunt each input. That would clip input signals to about +/- 0.5 V, so an input of 240V would be short-circuited and the computer would only see a small voltage. We put a small fuse in series with each input, so that if the diodes shunted a large current the fuse would blow and protect everything. I don't think we ever did accidently connect anything to mains voltage, but ICL were satisfied (if still a bit nervous).

 

Solving the second problem was straightforward. I had to learn all about the I/O hardware and the signalling protocol, of course, but I found designing the interface not too difficult, including adding a watchdog timer to avoid hang-ups. The interface was mainly a passive protection device, transparent to the two-way communication between the computer and the peripheral equipment. The computer was in control of the data exchange, but the peripheral could raise an interrupt line. The data was transferred as 8-bit bytes in parallel.

 

Stephen made another interesting suggestion. Forrest Hill had been wired up for an intercom system, with a number of cables going from the computer room to various rooms in the building. Each cable was composed of about 24 wires, each individually wrapped with foil, rather like low-quality co-ax cable. We did some experiments and found that we could send a 2 MHz signal along the wires, from the lecture room on an upper floor to the computer room and back, without much attenuation and without cross-talk between the wires. This meant that we could connect equipment in almost any part of the building to the computer. In particular, since Freddy I was fairly easy to move, we could take it upstairs to give demonstrations in the lecture room, as well as using it in a downstairs room. All we had to do was design suitable amplifiers to drive the long wires with +/- 0.5 V signals. The computer interface incorporated driver amplifiers for the out-going signals, and Schmitt trigger circuits to translate the incoming 0.5 V signals into appropriate binary signals for the computer logic.

 

The interface unit was approved by ICL, was installed in the computer room and connected to the 4130. I then had to design the robot end of the connection with the associated control logic. Freddy I was a fairly simple system. It had a TV camera which looked down and forwards at about 45 degrees. There were two stepper motors that drove the two wheels, and there were bumper bars in front and behind which operated microswitches.

 

The 24-way cable from the computer interface plugged into a connector in the control rack for Freddy I. There were driver and receiver circuits, complementary to those at the other end, and registers to hold the data transferred from and to the computer. There was also a little logic to interpret the command sent from the computer and load the right data into the register.

 

The simplest I/O task was to read the state of the microswitches. This simply required setting the bits in the sending register according to the switches and transmitting it back to the computer.

 

The next simplest task was to command the motors to take one step. The command from the computer specified whether or not to step each motor (2 bits). Steve built the analogue drivers for the motors and all the control logic had to do wa initiate the step.

 

Reading in an image from the TV camera was more complicated. The TV sampler only measured the brightness of one point at a time. When the scan reached the chosen point, the brightness signal was sampled and held on a capacitor.

​

Freddy I could move the two wheels independently forward or reverse (one step at a time), so it could turn on the spot. The TV camera was fixed and could not tilt. Originally the camera pointed vertically downwards into a 45 degree mirror, so that it effectively looked straight ahead, about 2 inches from the ground. We found, however, that bits dropped inside the vidicon tube onto the photocathode, so we got a new camera and Steve mounted it at 45 degrees, and threw away the mirror. There is a detailed description, with a picture of the initial version of Freddy I, and even the control and status codes for the hardware, and the user API in the article:

 

H.G. Barrow and S.H. Salter, "Design of low-cost equipment for cognitive robot research", in Machine Intelligence 5, B. Meltzer and D. Michie (eds.), Edinburgh University Press, pp 555-566, 1969.

That article also gives some early thoughts about Freddy II. A later article is specifically concerned with Freddy II:

 

H.G. Barrow and G.F. Crawford, "The Mark 1.5 Edinburgh robot facility", in Machine Intelligence 7, B. Meltzer and D. Michie (eds.), Edinburgh University Press, pp 465-480, 1972.

"Mark 1.5" really means Freddy II, but still in development.

 

One of the first things we did when Freddy I became operational was to develop some techniques for object recognition. Following a suggestion from Robin Popplestone, I implemented an object recognition system that used region-finding and described the view in terms of properties of and relations between the regions. Recognition was performed by matching view descriptions. I had a set of simple objects that the system could recognize, including cups. (I have a sequence of pictures showing cup recognition.) The system could be trained to recognize new objects. This system was one of the first to be able to recognize 3-D objects that were not polyhedra. MIT and Stanford used polyhedral blocks and wedges because they were easy to model on a computer and their images had only straight lines. We took the approach that we should associate with an object a set of 2-D views and match these with tolerance, rather than trying to model it by a 3-D geometric model. Think about the problems of geometrically modelling a tree, and then recognizing a second tree, for example. Our approach does seem to be similar to what we do in our heads. See:

 

H. G. Barrow and R.J. Popplestone, "Relational Descriptions in Picture Processing", in Machine Intelligence 6, B. Meltzer and D. Michie (eds.), Edinburgh University Press, pp 377-396, 1971.

 

As you may have gathered, I was a major contributor to the Freddy projects. I worked on the hardware design, the control and sensing software, I wrote a real-time operating system for the Honeywell 316, the display software (no GPUs back then), the image processing software. I am responsible for the searching and layout stage of the demo (Pat Ambler helped me with some of the object recognition, and postdoc Chris Brown developed the heap breaking techniques); Robin Popplestone did the actual assembly (helped by Pat Ambler). The assembly code was only about 10% of the system - this was back when Robin was just beginning to develop ideas about assembly. The assembly sequence was interactively coded by hand and used a couple of high level routines: constrained move and spiral search fitting. It used force feedback, but no vision, and could not recover from disasters (as it says in the paper).

​

Harry Barrow January 2009