This is not a CV

Beware, reader: here I talk about how on earth I have come to be so interested in understanding the world, and experimenting for this purpose with computers, robots, and the like.

How one tends to have the feeling that doing a Ph.D. in mobile robotics was something unescapable

I've been interested in understanding how things work from very young. Applied to computers this is related to hacker culture (in the ``good hacker'' sense, as e.g. Eric S. Raymond says).

Before computers

Before even knowing what a computer was, I liked fiddling inside the guts of some toys I had (remote controlled car model, notably) to understand how it worked, and try some experiments for better understanding. I also liked building animated things using ``Lego Technic'' much more than I liked classic Lego I played before. See Laurent Moll's web page for more old Lego models.

Discovering the computer

About 1983, I discovered computers and programming at the "Centre Mondial Informatique et Ressources Humaines", a place seemingly designed precisely for this purpose. Then I had a ZX81, then, in 1985, the Amstrad CPC 464. I was fascinated by the apparent unlimitedness of programming and the variety of things you could do (something many people buying computer-like artifacts are still unaware). Intuitively, it looked like you can create and play almost infinitely without depending on asking mom all the time to buy extra model rails or Lego pieces. :-)

At that time I started to think about some issues.

For example, I noticed the similarity between memory limitations on a computer, and limited number of gears/spindle in a mechanical artifact.

Also I wondered if my computer could reason about real world objects and events. I remember estimating whether the 64kb memory of my CPC could be enough to hold enough rules of French to communicate through that language :-).

I also asked myself if my computer could control other devices at home, and whether it was interesting (I did not knew the word ``interoperability'' yet).

Programming the computer

I programmed sometimes the things I read in ``Pour la Science'' (the french edition of ``Scientific American''). I remember programming on my CPC a simple simulation with fishes and sharks on a torus planet: fishes multiplied, sharks ate fishes and thus multiplied also, and try to see if remarkable things happened.

In 1989 I learnt Z80 assembler (for the Amstrad CPC), and make some pretty things. Then I had an Amiga 500 and started learning MC68000 assembler. Meanwhile I discovered Dungeon Master, the game I liked best: true immersion in a rich simulated world allowing many interactions and freedom. By the way, the game that fascinated me on Amstrad CPC was ``Elite'', because of the freedom of action (no scenario imposed, yet many possibilities), and thus the feeling that a full world exists inside.

Fascinated by 3D graphics, I started to re-invent on my own some basic 3D equations based on a ``shoe-box'' (pinhole camera) model. Using those I wrote a program able to represent a wire-frame world from any location, pointing toward any other, using a specified origin, target point, and focal length (distance between observer eye and the center of the screen, in pixels), while naturally maintaining a horizontal horizon line on the picture.

Understanding the computer more deeply

I liked to know how the machine worked inside, at least an abstract model. I had a book explaining how the CRTC, the sound generator, the gate array, and other things inside the CPC worked, and I tried some funny effects like having an interlaced 640x400 video mode on the CPC, which usually doesn't perform much more than the normal 200 scanlines (Arkanoid used something like 256x256, but not 400). I have never achieved as stunning demo as, for example, the "Logon system" group did at the time, though I had a project of a demo with real-time wire-frame 3D graphics, and/or a kind of movie player with simple inter-frame compression (I had it work on a simple animation that spins a square).

Then, for some reason I lacked access to a computer for a while, starting at middle of year 1990.

So I played with what I had at hand. After making on a friend's HP28S another simple labyrinth game with pre-computed 3D graphics (graphics and masks were computed on the machine itself), I had at the end of 1991 a Casio FX7000Ga. After a Mandelbrot program, I wrote a basic ray-tracer for the Casio FX7000 (the program showing a plane and sphere, with dithering, tightly fitted in the available 422 bytes). The picture next to this text shows what it looked like. It's not produced by the original program, instead by a minimalist example of raytracing in OCaml that I wrote in january 2007. I also wrote an optimized algorithm to represent a block world in 3D a la Dungeon Master (not precomputed this time, rather a kind of one-dimensional ray-tracing, but with anticipation). It didn't fit in the available 422 bytes. Fortunately I had found a way to hack the Casio to divert the memory normally available for A-Z variables and use it for the program (only the contrary is normally possible: reduce program memory, to allow more for variables). With this hack I had up to 630 bytes for program.

Using the same memory hack, which allows a crude way to access the full 2kbytes RAM, I designed a program that prints the full character table (something not normally possible for the user). It include one of the japanese alphabets, namely the Katakana.

By the way, I discovered by chance a ``hidden'' auto-test feature of the FX7000-Ga: memory test, keyboard test, and the like. The memory tests finishes with a sentence in Japanese (transcript here in latin alphabet) ``Reset shtekarashto ushte kudasai.'' (I believe it means ``Please press any key for a reset.'').

Then I had a HP48, a more powerful machine, on which I started a Dungeon Master clone, first in RPL (Reverse Polish Lisp, the standard user language), then in System RPL (also named ``External'') language, more powerful but a bit like Chinese to learn, then finally in Saturn Assembly, for speed, but always respecting the interoperability between HP48 models (S/SX/G/GX) by avoiding useless assumptions that break the portability.

(Actually I already had done a very simplified, yet good-looking, labyrinth game on a friend's HP28, before I had my FX7000).

So...

What is the lesson up to now ? I like fiddling with machines and experiment new things with them, especially beyond what is considered the ``standard'' use of the machine. At that time it meant: assembly language and a good understanding of its guts is more powerful than using the supplied language (BASIC/RPL...).

Electrical Engineering and Computer Science

Then I passed the competitive exam to enter Ecole Polytechnique.

Among all the things and studied there, I liked especially those about

• mathematical operations and their application on image processing (we used the Khoros software, through its GUI named ``Cantata'').
• 3D computer graphics (lessons written by Olivier Faugeras, taught by Claude Puech and Francois Sillion)
• general purpose signal processing and its application to sound and image (convolution, Fourier, error-correcting coding, Jpeg and GSM compression), a lesson by Stéphane Mallat. After those lessons I knew better than before why I couldn't stand ;-) seeing a picture that has been resized by removing p lines out of q, instead of a proper interpolating algorithm.

What I liked top were the experimental works

Given a robot (486 PC running DOS, with two motored wheels with encoders, two magnetic sensors, and a camera with ISA frame-grabbing board), a friend (Alan Schmitt) and I were asked to give to the robot the ability to follow a path marked by an electric wire under a white adhesive tape (on a dark but shiny floor). No hardware driver nor API was supplied, so Alan and I had to browse the hardware documentation and figure out what and where to poke into the ports.
After that, we were asked to do the same thing using the camera instead of the magnetic field (a driver for the framegrabber was supplied). After experimenting, we designed a simple algorithm. We set the grabber to a low-res picture (about 96x60) to have about 10 fps. We scanned each line from left to right, seeking positions where brightness rose then dropped more than a threshold. If those positions were both found, and neither too close nor too far, then they were supposed to be the sides of the white tape, and the middle position was taken into account for an average calculation. After scanning all lines, the robot turned proportionally to the deviation of this average position with respect to the middle of the screen. Also, if the number of relevant points was high, the robot went fast, and if it was lower (it happens for example when the reflection of the window makes a white stain in the image, or because there is a sharp turn), then the robot reduces speed, and doesn't lose track.
This simple solution gave the whole system quite good performance: it could run fast and was not disturbed by the reflected sun on the shiny ground, since most irrelevant points were ignored and did not deviate the average much.

Our BEST work was the application of the lessons taught by Jean Vuillemin, "Électronique: du composant au système". There is a great module, directed by Jean-Yves Parey, where student may design and bring to reality whatever they like using FPGA, (a digital clock, a lift controller, a tamagotchi, etc...). The hardware was a Pamette board on the PCI bus of a PC, driven by a development kit from Xilinx, allowing schematics and VHDL design that were compiled into a bitstream fed into the board.
With another friend, Didier Le Botlan , we designed a custom, simple but full featured, fully 16-bit microprocessor, along with an assembler (written in CamL), and a prime number calculation as application. We both knew Z80 and 68000 assemblers, so we took inspiration from those. Our processor had 8 16-bits registers and, or, xor, not, move, add, sub, direct and indirect addressing, an internal stack of eight 16-bit values, and an orthogonal instruction set. It worked at about 12MHz, each instruction usually taking 3 cycles to perform, but one started every two cycle. The day of the demo, the prime numbers didn't work :-( ... but read on.

On top of that we added our home-grown graphic circuit: 320x200, a 256-color programmable palette, an external DAC we soldered with proper power supply. We fed it with an external clock, because the PC clock was too irregular. Thus, the communications between processor and video memory were asynchronous but we did the necessary adaptation for reliable communication.
Finally we did a clone of the old ``Trailblazer'' game (a ball rolling smoothly but very fast on an infinite road with colored squares).

We used the same trick as on the Amstrad CPC version: reprogramming the color palette at each video line to render the perspective, thus minimizing the accesses to video memory.

The whole thing performed 79fps, with beautiful realistic shading thanks to the DAC (the tables and bitmap for the perspective were calculated on my fellow HP48). The demo ran flawlessly.

We were proud of us.

The year after, the teacher used our stuff to present this course to the new students.

Discovering research

During those years at Ecole Polytechnique, I continuously refined my intuition about machines, intelligence, etc... I remember stating that something fundamental had to be the ability to adapt to new situations, and that limitations in what we design seemed to be caused by the design itself. It is kind of self-contradictory, suggesting that the solution is not to design at all, but if you don't do anything, nothing interesting happens. Since I don't feel like having a contemplative life, I continued thinking.

One evening, while looking for some artificial intelligence lab whose ideas would resemble what I felt, I typed "adaptive behavior" in Altavista (what does it answer now ?) I discovered a journal named ... "adaptive behavior", and the AnimatLab. Bingo !

The end of studies at Ecole Polytechnique include a 3-month internship in an industrial or research lab. I did mine programming neural networks at LPPA, a great french lab, part of Collège de France, in cognitive science, neurophysiology, and the like, directed by Alain Berthoz.

I visited the AnimatLab and Jean-Arcady Meyer advised me to go to DEA IARFA (a one-year course in AI at University Paris 6). (A DEA in general is a diploma equivalent of what people from USA call "Master of Science".)

So I started my Ph.D. at the AnimatLab and had my first published paper in 1999.

Now I'm pursuing my Ph.D. as I describe in my lab's homepage.
At a glance:

• use and programming of an experimental visual perception board, the GVPP.
• work (play ?) with real robots.
• read what others have done, imagine variations, design and test some cute ways to help a robot find its way as autonomously as possible in an environment as unprepared as possible.

To be continued...

So (again)...

What is the lesson up to now ? I still like fiddling with machines and experiment new things with them, especially beyond what is considered the ``standard'' use of the machine.

I can now tell that I feel that interoperability between machines is one of the most important thing in computer usage.

For up-to-date information about me, see current home page or current CV of Stéphane Gourichon