Earthquake Platform

Overview

This platform hardware was purchased as a used, but working system. The Explo folks buying it didn’t really ask enough questions to know if it would actually fill our requirements however. It turned out the software was closed source, and evidently written in Macromedia Director. Ick!

The existing software played a single quake, without control over what the motions were (since it was baked into the code). The duration, motion profile, excursion and etc were all wrong for our application, and the dataset being played back was apparently random noise, rather than actual earthquake data.

There are a couple 750w servos with 60:1 planetary gearboxes. These are attached to linkages that push the stage around on x and y axes. Interestingly, the hardware was built so that the output crank from the gearbox could not make a full 360* rotation for two reasons. Firstly, the moving layer of the stage would contact the prior stage. Secondly, the swing of the crank arm was too long and would impact other hardware in the assembly. There were limit switches on each end of each axis, but they were disconnected. With this much gear reduction, the x and y axes could each output around a ton of force. Pretty terrifying with no ability to have the mechanism protect itself!

There is a 1500w sub-woofer amplifier, and a pair of Butt Kicker transducers to shake the platform in the higher frequency range. These are wired mono, to share the same signal.

Reverse Engineering

The servo drives take either a step/direction signal (as is standard), but also have a motion controller onboard that accepts ASCII commands. The existing code used this ASCII control mechanism, so we did too. It’s a little higher level than sending step and direction pulse trains, and since the PC would be running windows, real time step/direction output would not be viable without additional hardware. Why not just the built in motion controller/pulse generator?

Since some of the ASCII characters used are not-printable, all the ASCII codes needed to be referenced as hexadecimal/binary numbers.

Python Code

I wrote a few custom python programs.

The first one would download and pre-process interesting earthquake data. This pre-processing was needed to filter out the data in frequency ranges that the platform could not reproduce. The x and y axes could tolerate about 23 commands/second without saturating the serial bus (at 19,200 baud, which is a crawl). Some of this limit is to do with my script, and status checking of the servo drives. Faster serial speeds are likely possible if that was really important, but 23hz was good enough for our application. Since the travel is pretty limited, we can’t get impressive quakes through low frequency, large motion, but rather need to use the frequency range that the platform can actually reproduce well. The smaller, higher frequency (4-20hz ish) waves makes the most sense of the x an y axes for this hardware. These result is sharper, jerkier motions.

The ButtKickers respond to a frequency in the 5-200hz range, so the script would also filter the Z channel seismic data to that frequency range, and then up-sample to be a 44khz audio track that regular PC sounds cards can play back.

Video integration

The second program is the main earthquake program.

After playing with the platform, and talking with the client, we settled on replicating (a frequency range of) a Large Earthquake near Kathmandu, Nepal. This was decided on in part because there was high resolution CCTV footage from multiple angles of the quake, and a seismograph station a few blocks away from the location of the footage.

This meant we could play the CCTV video on 3 projectors, and synchronize that with the seismic data on the x, y and z axes of the platform. The python script would play the video, and trigger the quake data based on key frame numbers, to maintain synchronization.

This python code also had to multi-thread, since it needed to fade the video and audio tracks dynamically when a user pressed the stop button.