Development and Evaluation of an Economical Arduino-Based Uniaxial Shake Table for Earthquake and Wave Simulation

Due to the high mortality [1], and financial losses caused by earthquakes [2], it is essential to study the structural response under seismic loads to minimize catastrophes and rebuilding time, especially in the seismically risky regions, by ensuring that the response tests of structures confirm the expected performance based on the design methods [3]. In this regard, shake table testing has a wide scope and remains one of the most effective seismic model tests that helps examine foundation reactions, dynamic horizontal earth pressure, and soil-structure interaction. Shake tables (also known as earthquake simulators) consist primarily of a base upon which the specimen structure to be tested is installed. The motion of the base is then controlled by varying parameters such as displacement or accelerations in the x, y, or z directions (depending on the degrees of freedom (DOF)) based on the earthquake data [4]. Shake tables are categorized as small (smaller than 3 m × 3 m), medium (from 3 m × 3 m to 9 m × 9 m), and large (greater than 9 m × 9 m), which can include complex hydraulics and control systems and can incorporate motion in up to 6 DOF [5]. Despite its importance and necessity, shake table testing remains an expensive study due to the high cost of the equipment required. Even the smaller, one-axis shake tables cost around 30 thousand USD on average, while the options for open-source shake tables remain scarce [6].

The earliest efforts at constructing shake tables are attributed to the Japanese, followed by several researchers from the US and other parts of the world. The earliest designs incorporated uniaxial motion through purely mechanical means such as balancing wheels, springs, and reciprocating arm mechanisms. Since the 1960s, electric motors have become more widely used in shake table applications. Since the 2000s, most small-scale shake tables have utilized servo motors or hydraulic actuators depending on the required load capacity, while most large-scale shake tables utilize servo hydraulic actuators [7], [8], [9], [10], [11]. Optimizations in existing designs and the development of new designs that could incorporate more DOF continued as the general objectives of shake table design remained to satisfy requirements, performance, system behavior, probabilistic reliability, hazard scenarios, and quality assurance [12].

Today, several different configurations exist depending on usage, and can include uniaxial, biaxial, and triaxial, as well as up to 6 DOF by incorporating pitch, yaw, and roll. Shake tables remain highly nonlinear devices, but with an increasing number of DOF, the complexity and cost rise [13]. Different actuation methods have been used in different kinds of shake tables, including electro-hydraulic, electromagnetic, and servo-hydraulic actuation [14]. Among other studies, a shake table has also been used to examine the behavior of rigid blocks and frames [4]. PID control systems have also been utilized in shake tables [8]. The literature discusses a wide range of applications for shake tables, including earthquake engineering, structural dynamics, and earthquake risk assessment. Shake table testing is also being used in nonstructural component testing, soil-structure interaction studies, and seismic retrofitting investigations [15].

A review of the literature showed that low-cost, open-source options for shake table testing remain scarce. SARSAR [16] is an open-source, low-cost uniaxial shake table based on an Arduino microcontroller. It utilizes a ball screw assembly, linear bearings, and a stepper motor. The SARSAR can reach a maximum speed of 0.35 m/s, an acceleration of 1.5 g, and a maximum payload of 200 kg. At 45,000 USD, CUSHAKE [17] is also an open-source uniaxial shake table that was built and tested in Turkey. The table can support a maximum payload of 1000 kg, utilizing a servo-driven AC motor, a rigid table, two rails, and four bearings. The Shakebot [6] is a simple setup based on Raspberry Pi and ROS. It utilizes 3D-printed components, a closed-loop stepper motor for actuation, and a tooth belt for transmission. The stepper motor enables the bed to reach a maximum horizontal acceleration of 1.2 g and a velocity of 0.5 m/s with a 2 kg specimen. TDG—Atom [18] is the most compact model being sold by TDG at 12,000 USD. It employs a servo motor in conjunction with a ball screw assembly, enabling it to linearly oscillate 50 kg of mass at 1g. Priced at 15,000 USD, the Quakelogic Test Box [19] is a biaxial shake table that utilizes a servo motor coupled with a ball screw assembly, capable of accelerating 100 kg of mass at g. The shake table built at the University of Engineering Technology, Pakistan [4] was custom-made and cost 3000 USD. It has a maximum payload capacity of 1220 kg and an operational frequency of 0–50 Hz. It utilizes a servomechanism that can produce an acceleration value of 1.9 g.

The design of the EMU shake table was mostly inspired by the SARSAR [16], Quakelogic [19], and UET-CIU [4] shake table designs. The CAD isometric view of the prototype with the main components labeled is shown in Figure 1. The actuating mechanism for the EMU Shake Table prototype consisted of a ball screw, linear rails, and the ball screw nut. LiCHUAN-MC860H motor driver and LC86HS2801 stepper motor coupled with SFUR1610 ball screw were utilized for powering the system.

The prototype was to be tested under two operating modes: sinusoidal waves and scaled down earthquake simulation. The scaling down of earthquake data was done using the SeismoMatch 2024 software. Once the assembly was completed and the Arduino UNO controller was programmed, the prototype was ready to run. The schematic in Figure 2 illustrates the process by which the EMU—Shake Table functions. The bill of materials for the prototype has been shown in Table 1.

Initially, the assembly was tested to check for any mismatch between the input and the desired output values. To perform this test, the motor driver (MC860H) was switched to 400 steps/rev and full 6A current by turning on switches 4, 5, 6, 7, & 8, and by turning off switches 1, 2, & 3. The “move stepper” function within the AccelStepper library allows users to control the direction, distance, speed, and acceleration of the motor. Using this library, several acceleration values were fed at different amplitudes into the code (inputs) to check for the maximum output acceleration values, the corresponding output amplitude values, and the maximum achievable frequencies. The acceleration values defined as inputs were in steps/$s^2$, therefore the values in ‘g’ were calculated using this conversion factor:

The desired input amplitude, in mm, was defined as steps in the code and compared to the output amplitude to obtain the error. To measure the output amplitude, two pens with a 0.5-mm-diameter tip were glued to the plate, and a wooden plank was placed perpendicular to the pens such that the pens sketched lines when the table oscillated back and forth. We then used a ruler to measure and record the lines. The acceleration was measured using an MPU6050 accelerometer (acceleration set at full scale range with a sensitivity factor of 16384), which was glued to the shake table surface and connected to a separate Arduino Uno. The experimental setup is shown in Figure 3.

For a desired amplitude of 2mm, 80 steps were supplied to the stepper motor running on 400 steps/rev and full 6A current as set on the motor driver, and the output amplitude was 1mm. It was observed that the output amplitudes were less than expected; therefore, a feedforward gain of 2 was computed to correct the input amplitudes to obtain the desired output amplitudes. Furthermore, a significant overshoot was observed in the output acceleration values for small input acceleration values; however, the overshoot was observed to be significantly lower at higher acceleration input values. This can be observed in the graphs shown in Figure 4 as subgraph (a) of Figure 4 shows a significant overshoot with a ratio of input to output of 0.22; subgraph (b) of Figure 4 has a ratio of 0.49; subgraph (c) of Figure 4 has a ratio of 0.78; and subgraph (d) of Figure 4 has a ratio of 0.88 for an amplitude of 2mm. Figure 5 shows the corrected input amplitudes, input acceleration, and the ratios of input to output acceleration values.

The error between the input and output acceleration values continued to reduce as the input acceleration values went higher. This trend was observed to be true for all input amplitudes. The error was estimated to be 15 percent at high input accelerations. Based on the data from Figure 5, and assuming the magnitude of the acceleration values in positive and negative directions to be equal, a 3D surface was plotted using the Poly23 fit type in MATLAB, which helps visualize the overall performance of the EMU Shake Table in the sinusoidal mode as shown in Figure 6.

To simulate an actual earthquake, it was crucial to obtain maximum performance of the motor with irregular and unpredictable displacement, velocity, and acceleration profiles.

To do this, the following methodology was employed:

1. Earthquake data was obtained from SeismoMatch 2024 software, and scaled to ensure all displacement values were less than the maximum stroke length of the shake table.

2. With the selected earthquake profile, the maximum possible accelerations, and velocities that the motor was able to achieve over the selected overall time duration were checked iteratively:

A. A large number for velocity was fed into the code, and accelerations were altered until the values for the overall time taken were saturated.

B. Keeping the maximum acceleration constant, input velocities were altered until the values for the overall time taken saturated.

3. The smallest possible time step size at which the motor was able to completely perform the scaled earthquake displacements at the scaled earthquake velocities and accelerations was obtained iteratively. However, to account for latency, throughput, and external disturbances, a slightly larger time step size of 0.5 s was used.

4. To ensure some level of robustness, the Earthquake was scaled further down so that it did not exceed the motor’s maximum acceleration and velocity capacities for the selected earthquake profile by a margin.

5. Scaled earthquake displacements were converted from cm to motor steps.

6. Scaled earthquake velocities were converted from $\frac{\mathrm{cm}}{\mathrm{s}}$ to motor $\frac{\text { steps }}{\mathrm{s}}$.

7. Scaled earthquake accelerations were converted from g to$\frac{\text { steps }}{s^2}$.

8. Time, displacement, velocity, and acceleration data were fed into the Arduino Code, and the output acceleration results were recorded using the MPU6050 module. Due to the limited data storage capacity of the Arduino board used, the earthquakes were simulated only for a total of 10 to 12 seconds.

9. The data obtained from the MPU6050 included noise, and the accelerometer could not detect acceleration values between the range of ± 0.01 g. Therefore, each output acceleration value was manually checked at the expected time stamp, after which the accelerogram data was smoothed.

10. RMSE was calculated using the relation:

The flowchart shown in Figure 7 summarizes the process for simulating an earthquake.

The selected earthquake was the Kobe 1995 earthquake at a scale factor of 0.45 and recorded at time intervals of 0.01s. The test initially failed due to the limited storage capacity of the Arduino UNO board. Therefore, the simulation was conducted at time intervals of 0.5s. The earthquake displacement converted to motor steps at different time stamps is presented in Figure 8. The displacements are not absolute, which is why the input steps share the same profile as the expected displacement.

The actual and expected smoothed accelerograms have been shown in Figure 9. The significant mismatch between the expected and actual values at 0.5 s could be attributed to the accelerometer failing to detect accelerations in the range of ± 0.01 g.

The intervals on which there is an undershoot for the actual acceleration values can be fixed by inputting a slightly higher acceleration value into the code until the expected acceleration meets the actual acceleration with an acceptable error margin. With the current results, an RMSE of 0.0091 was computed. The intervals on which there is an overshoot for the actual acceleration values need to be first checked with a more sensitive accelerometer, which would then discern if there is a need to alter the input accelerations to meet the desired values with acceptable error margins.

The data for the Northridge earthquake was also obtained from SeismoMatch 2024, and then scaled down by a factor of 0.3. The raw data was then refined to ensure that the velocities were positive (negative) when the displacement curve was increasing (decreasing). Similarly, it was ensured that the accelerations were positive (negative) when the velocity curve was increasing (decreasing). Due to memory limitations, the data at a time interval of 0.75s was used, and the actual and expected smoothed accelerograms are shown in Figure 10. The RMSE of 0.017 was computed for the expected and actual accelerations.

The data for the Northridge earthquake was also obtained from SeismoMatch 2024, and then scaled down by a factor of 0.3. The raw data was then refined to ensure that the velocities were positive (negative) when the displacement curve was increasing (decreasing). Similarly, it was ensured that the accelerations were positive (negative) when the velocity curve was increasing (decreasing). Due to memory limitations, the data at a time interval of 0.75s was used, and the actual and expected smoothed accelerograms are shown in Figure 10. The RMSE of 0.017 was computed for the expected and actual accelerations.

The same process was used in simulating the Friuli earthquake. The raw data was scaled down by a factor of 0.5. The raw data was then refined to ensure that the velocities were positive (negative) when the displacement curve was increasing (decreasing). Similarly, it was ensured that the accelerations were positive (negative) when the velocity curve was increasing (decreasing). Due to memory limitations again, the data at a time interval of 0.5s was fed into the code to obtain the actual and expected smoothed accelerograms shown in Figure 11. RMSE of 0.0046 was obtained for the expected and actual acceleration.

The project was successful in manufacturing a small-scale Arduino based shake table, proving the simplicity of simulating sinusoidal signals, however, simulating the scaled earthquake data was more complicated. One limitation was the low memory capacity of the Arduino board, which could not incorporate all the scaled earthquake data at smaller time stamps. The future works could be broadly categorized into three categories: design refinement, design optimization, and design modification.

1. Design refinement: different sensors could be added, and the values could be compared for more accuracy. One common problem that remained in the prototype was the misalignment of the motor shaft with the ball screw. This can be solved by incorporating a guiding mechanism for the motor instead of making manual adjustments before and after every operation. Using an Arduino with a higher storage capacity could allow simulating earthquakes with a smaller time step size. A motor with higher specifications should be used to prevent stalling.

2. Design optimization: Factors such as the distance between the linear bearings and its effects on the overall vibration of the plate, as well as the change in maximum stroke length due to the change in the distance between the linear bearings, can be studied to achieve an optimal value for the distance between the linear bearings.

3. Design modification: The prototype has the potential to be modified such that it could be mounted on another model rotated at 90 degrees to make the overall assembly a biaxial shake table. This could be Prototype 2. Upon completion, Prototype 2 could also go through design refinement, optimization, and modification processes until a triaxial shake table could be built.

4. The robustness of the system can be further analyzed.