Demos page

Michael Robinson



This page lists details for some demonstrations of my research and teaching projects. I also have an online build log called "Engineering Mathematical Machines". Feel free to contact me about my projects!

(The content on these pages may be freely used for educational, noncommercial purposes provided appropriate references are provided. Commericial users are kindly asked to contact me first. Be aware that in any case, they come with no warantee: use at your own risk!)

Terminal velocity in fluid


This simple machine demonstrates that a viscous suspension (applesauce) suspended in water has a pretty low terminal velocity. After it reaches terminal velocity, it travels at a constant speed. This is well modeled by the transport equation.

The heat equation


Camera surgery Any demonstration involving the heat equation should involve fire. But how to easily measure the temperature of something hot? Simple: make use of the fact that digital cameras are already sensitive to the infrared emissions radiated by hot objects. They usually have a protective lens to filter out infrared, but it's easy to take an inexpensive webcam and remove the filter. Then you have an infrared webcam! Heating a steel rod with a torch

Then, take a metal rod and heat it with a torch so that it's glowing hot, and snap a sequence of pictures of it with the infrared webcam as it cools down. If you take enough pictures, you can compare the temperature as a function of time with the heat equation (you need to account for lateral heat loss, which is an extra loss term). The fit between theory and practice is not too bad!

Shive wave machine


Torsional waves on a wire can have very low propagation speeds -- they're so slow that you can see them moving. John Shive invented a simple machine to demonstrate these waves to his students. It's pretty easy to build a tabletop version yourself with a few parts from a hardware store. Then you can see wave propagation and standing waves quite clearly.

Lissajous figure maker


An excellent example of parametric curves can be found in the example of a Lissajous figure. These can be generated in a variety of ways, perhaps most commonly using the X and Y inputs of an oscilloscope. However, that's kind of high-tech. In the past, they have been generated mechanically, often involving vibrating strings. Most vibrating strings don't move very much, so some old experimental descriptions require looking at the Lissajous figures through a magnifier. A much simpler way to generate them requires two mirrors mounted on rotating axes at right angles to one another. A beam of light can be directed between the mirrors to project a Lissajous figure on a screen.

Lissajous figure maker To make something suitable to show in a classroom setting, I made a frame that held two strings at right angles to one another. The strings are hung from screw eyes with wing nuts so that the tension can be adjusted. (This is inspired by the mirror galvanometer.) To each string, I attached two small mirrors (about 1" x 1" square) back-to-back with a little tape. I tried attaching one mirror to each string, but found that the assembly wasn't very well balanced -- two identical mirrors are much better balanced. The mirrors are aligned so that a laser beam can bounce off both mirrors before being projected onto a screen (usually the wall).

L'Hospital's rule demonstrator


Which function decays faster: an exponential decay or a power law decay? This question is one of the things that L'Hospital's rule makes short work of in class, but can this mathematical question be answered with an experiment? Yes! In acoustics, sounds often decay sharply as energy is dissipated. For instance, the sound pressure of a bell as it rings tends to follow an exponential decay. Exponential decays also can be generated easily with a resistor-capacitor circuit.

Comparison of a bell's sound pressure level and an exponential curve Power law decay is a little more subtle, but it's pretty well-known that sound pressure decays according to an inverse square law. This demonstration pits power-law decay coming from moving away from a sound source against the exponential decay coming from a resistor-capacitor circuit. In order to be easily moved, the circuit has to be small. Here is the circuit diagram. I built mine so that the separate functional components are easy to see and debug, should something go wrong.

Functional components of L'Hospital's rule demonstrator L'Hospital's rule is about limits of ratios, so it's proper to have the circuit manipulate the ratio of the two signals. However, circuits that compute ratios are a bit tricky. It's much easier to compute logarithms and subtract, which is what this circuit does. The input stage to the circuit consists of a resistor-capacitor timer (triggered by a switch, and displayed with an LED) and a microphone audio amplifier. These are fed into a pair of logarithmic amplifiers. These feed into a difference amplifier, working as a comparator. The comparator drives the output LED.

L'Hospital's rule demonstrator in action I found that the circuit was a little tempermental after it was built. This is mostly because of the fact that the logarithmic amplifiers can have pretty large gain because they're nonlinear. Once everything is adjusted correctly, the circuit does a nice job. If you're going to perform the experiment in front of an audience, you should practice until you have the technique mastered. First, you need a constant sound output. There are various ways to get this, for instance playing a sound file on your cell phone or laptop. (I like to use gst-launch utility on Linux to generate a tone.) However, it's also workable to whistle a clear, stable note, although this takes practice. Once you have the sound source working, here's what to do:

  1. Place the circuit on the table,
  2. Start the sound source right near the microphone, (the sound level LED will light)
  3. Push the trigger button, (the sound level LED will extinguish, but the exponential LED will light)
  4. Slowly move the sound source away from the microphone...
  5. Until the sound level LED lights again.

Clepsydra (water clock)


Clepsydra Here's a quick little demonstration that highlights some simple, old ideas. Dripping water happens to be a good timekeeper, and is a good introduction to related rates problems. It's pretty easy to make. Take a plastic funnel and melt the end shut with a candle. Then puncture the now sealed end of the funnel with a nail to make a small hole. Fill the funnel up with water, start a stopwatch, and mark off where the water level is (use a grease pencil) at some fixed time interval. It'll take a little trial and error to figure out what that interval should be. If the funnel drains too fast, seal the end again and make a smaller hole.

What do you do with this once you have it? Hand a student a stopwatch and have another student read off when the water level crosses the markers -- they're usually pretty surprised that the time intervals get farther apart as the water level goes down. Then, derive the rate of change of water level as a function of volume -- it's not a bad match if you use the volume of a cone.

Sound Card Sonar


I realized in preparation for the topological imaging experiments that there is little additional overhead required to apply traditional signal processing chains to the data collected. In this case, both the transmit and receive hardware is simply an off-the-shelf laptop and GNU Octave.

Image formation



It is straightforward to write simple, non-optimized sonar image formation software. I have typically used my smartphone to act as the transmitter, by playing a carefully constructed audio file that contains a number of chirped pulses. I receive the echos through the microphone on my laptop computer, perform some noise equalization using the freely-available program Audacity, and then pass the data over to my processing chain in Octave.

The resulting imagery can sometimes be a bit difficult to interpret, especially since interesting environments are rarely two-dimensional, as typical image formation algorithms expect. The wavelength of sound is also physically quite long, so the effects of diffraction and reflection are quite pronounced, and produce noticeable bright spots at corners of a room. As far as I know, the only other instance of this kind of thing is here, and sadly it seems like it hasn't been updated in a while.

Real-time audio tools


Working with acoustic data is very convenient because the experimenter can hear many problems instantly. In addition, since the rise of powerful multimedia frameworks such as GStreamer and python bindings for them, platform-independent, custom audio test equipment is very easy to construct. So I have availed myself of the opportunity and written a small collection of tools that the typical sonar engineer wants to have.


For instance, I have written an audio spectrum analyzer that can display the log magnitude spectrum, autocorrelation, or other desired functions of the received audio. Since the tool is written in platform-independent python, it runs on my Linux laptop (based on the x86 architecture) and my Nokia n900 smartphone (based on an ARM processor) with no changes to the code.


Sonar engineers are often in need of accurate ranging information, so I wrote a simple channel sounder. It emits a stream of brief clicks and then integrates the result. Typically, targets of high acoustic reflectivity (walls, for instance) appear as spikes on the display. Sadly, the user interface isn't as pretty as the iPhone sounder, but mine is platform-independent and interpreted, so it is extremely easy to modify to fit my needs.

Synthetic aperture sonar


Range-doppler sounder With very little equipment, you can run a real-time sonar system! It requires
  1. A laptop running Linux, with Python GTK and GStreamer libraries
  2. A set of speakers -- the bigger the better, with good high-frequency (tweeter) response
  3. A microphone, again with good high-frequency response
  4. A waveform to transmit, such as squeak.wav (a low-ultrasound chirp), squeaks.wav (a chirp train), or clicks.wav (an audible click train).
  5. And some processing software, such as this bundle. The range-doppler sounder takes a lot more CPU horsepower, so it might have trouble staying real-time.

Opportunistic imaging


System requirements and installation


If you're using an Ubuntu system most of this comes standard, but you'll need the following packages:

Demonstrations using acoustic sounders


This experiment demonstrates the signal space embedding theorem (see "Topological localization via signals of opportunity") for acoustic signals. The basic idea is that a collection of simple transmitters (special hardware used, but it's not crucial) emit signals received by a single receiver (laptop computer sound card). In order to provide some discrimination of which received signal corresponds to which transmitter, the transmitters emit short pulses, one after the other. The transmit sequence is enforced by a simple one-wire handshake. As it happens, the software framework for receiving supplied below loses synchronization frequently, so we can only identify transmitters up to a cyclic permutation. Even in spite of this, the signal embedding theorem guarantees unique signal response for each receiver location if enough transmitters are present. Downloadable items for conducting the experiment: ZIP file here projectPoints screenshot Step-by-step instructions for conducting the experiment:
  1. Apply power to each individual sounder
  2. Connect the signaling wires between each sounder
  3. Start the sounders emitting chirps by briefly grounding one of the signaling wires on one of the sounder. Reattach it before the active transmitter returns to the one you started.
  4. Start the receive thread using the command "rx_tdma_chirp -m level -t number of transmitters"
  5. Start the display thread using the command "projectPoints number of transmitters out.txt"
In order to give you a feel for what you should see, here is a sample output file, and at left is a corresponding screen shot. Be aware that even if you use the sample output file, the display may be different since it depends on a random projection.

Software to work with anything that can play sound files


Instead of using special hardware for transmitting signals, anything that can play a sound file can be used. Matched filters can be used to discriminate between the different choices of signals, though as in the previous experiment, several transmitters can emit the same signal. Rather than conducting the experiment in real time, this experiment collects data on request for offline processing. This can enable more experiments that are more carefully controlled. Matched filter bank Step-by-step instructions for conducting the experiment:
  1. Start up the matched filter program
  2. Load each reference file, either by playing a clip and pressing the Capture button, or by typing in a filename of a WAV file containing the reference. Press Enter after each filename to trigger it to load.
  3. Set up and activate the transmitters
  4. Once everything is in order, press the Store button to take data
  5. Repeat collection of data (pressing the Store button for each datapoint). If you make a mistake, you can delete datapoints.
  6. Once complete, press the Save button to save your datafile.
Here is some sample data, and at right is a screenshot of the program in action.

Imaging with wireless access points


Thanks goes out to Daniel Muellner and Mikael Vejdemo-Johansson for the scripts used in this demo!
Instead of acoustic sounders, you can use wireless access points to generate the ambient signals for localization. Here are a few scripts that read data (under Linux or Mac OS) from a wireless card and format it appropriately for projectPoints.py.
Step-by-step instructions for conducting the experiment:
  1. Connect your computer to a wireless network (may be optional depending on your wireless drivers)
  2. Make sure the collection works: "ssidcollect_os.py". You may have to use "sudo" to run this depending on your system. Press Control-C or equivalent to stop the collection.
  3. Acquire data "ssidcollect_os.py > data.log"
  4. Reformat it into a CSV file for later useage "ssidaccumulate.py < data.log > data.csv"

Asynchronous circuits


Asynchronous circuit Asynchronous circuits are very easy to see when the logic gates aren't very fast. Although one could use delay circuits to show this with transistorized electronics, it is trivial to make slow asynchronous circuits using relays. Here are the schematics for two example circuits: a Glitch generator and an RS flip-flop.

Clock escapements


I have been fascinated with mechanical devices, in part because they're tricky to build. (I grew up with carpentry and building circuits, neither usually has much motion.) Mechanical clocks just seem magical. The nexus of the magic (so to speak) is the escapement, which converts a nearly constant force into a constant motion. Once you have constant motion, it's possible to time other motions. In high school, I tried to build an anchor escapement, which is probably the most common kind. However, I failed miserably: the device didn't move well and bound frequently.

I figured that the reason for my failure was basically a lack of manufacturing tools -- if you look around at others (for instance Gary Mahony, Brian Law, Ron Walters, Don Corson, or Clayton Boyer) who have built clocks in their workshops, you usually find a high degree of workmanship. I just assumed that was necessary! But, then I saw Brian Law's verge and foliot escapement, in which the crown wheel didn't involve cutting teeth. Instead the teeth were metal studs -- that's something I could build!

Verge and foliot


The verge and foliot is the oldest form of escapement. It also seems to be the least tempermental, if somewhat inaccurate. I just wanted to construct the escapement, and so laid out some plans. In order to keep the friction low, the verge (the rod) is hung on between two strings. (This is inspired by the mirror galvanometer and by the Lissajous figure maker I already had working.

The crown wheel is just a thin wooden plate with nails hammered in at opportune locations. The locations are critical, and depend on how the verge and pallets are placed, and so are the last things to be installed. So to begin, I cut out the main pieces of the frame and crown wheel, and drilled the holes.

Main parts of the verge and foliot escapement cut out Crown wheel mounted in the frame The crown wheel was attached (press fit) to a metal rod that threads through the frame. It should spin freely. Then, the verge is attached. I made pallets from a folded piece of cardboard, stapled onto the verge. Once these were assembled, I hammered the first nail into the crown wheel, and cut it to what appeared to be the right length. This length is actually kind of critical: you want the pallets to easily engage and disengage from the nail. Now to add the other nails! Turn the crown wheel so that the pallet just disengages from the first nail. Place the next nail so that it just engages the other pallet. Once there are multiple nails, you want exactly one tooth (nail) to be engaged by the pallets at all times. It might take a bit of trial and error, but I did a bit of computations to figure out how tooth length, verge position, and pallet length need to be chosen. Some variability is acceptable.

Completed verge and foliot escapement I was delighted, and admittedly a bit surprised when it worked! Here is a video of the escapement running, after a little bit of tuning.

Anchor escapement


The parts of the anchor escapement The anchor and pendulum The crown wheel mounted in the frame Side view of the assembled escapement Front view of the assembled escapement Emboldened by my success with the verge escapement, I decided to try to build an anchor escapement. Again, I used nails as the teeth of the escapement wheel and essentially the same frame as before. To simplify the construction, I made the anchor teeth out of nails as well. After constructing the anchor and placing the first tooth in the crown wheel, I followed the principle that one tooth must be engaged at all times. Unlike the verge escapement, balance of the pendulum is critical. If it's out of balance, one of the anchor teeth will never disengage and the escapement stops. On the other hand, this escapement "wants" to run with lower torque than the verge escapement. I'm pretty sure that the pendulum is currently overdriven.

Amant escapement


Since the Amant escapement looked tractible to build, I drew up some plans. I cut the larger wheels from 1/4" plywood and cut the pinions and pallets from 1/2" pine. I had a bit of trouble getting it to run smoothly, because of two factors: friction of the pins against the pallets and issues with gear meshing. The friction issue was improved by adding additional weight to the pendulum (a heavy pair of vice grips) and also substantially more drive weight than I expected. The pallets needed a bit of tuning -- I mounted them with hot glue to allow them to be adjusted. To help the gears mesh, I filed the teeth on the larger wheel to allow more room for the pinion teeth. It's not completely reliable, but will run for half a minute or so!