Our software goal for this project was to have the board fully controllable just by leaning forward to accelerate and backward to slow down. The longboard trucks we purchased meant the board would mechanically turn in response to tilting left and right. We planned to integrate pressure sensing technology with a carefully designed control system to give the rider a smooth and effortless riding experience.
Our first version of pressure sensing involved pressing sheets of Velostat in between risers placed between the board and the wheel trucks. With a current running through it, the Velostat acts as a resistor with resistance varying based on the amount of pressure applied. With one sensor mounted on the front and one on the back of the board, we thought that the difference between the two would tell us how the rider was shifting their weight and allow us to control the board. In practice, we found that the velostat had a much larger reaction to left-right tilting of the board than to forward and backward pressure. The sensor output did not give us useful information about the rider’s movement.
To address this, we switched to using 4 pressure sensing Velostat pads (2 front, 2 rear) mounted on the top of the board, so that the pressure would be applied directly by the rider’s feet. The pairs of sensors would allow us to cancel out the differential between the left and right sensors in software and ignore pressure changes that were a result of turning.
This system was more responsive and wasn’t affected by turning, but at this point we realized that the velostat was not a perfect sensor. The output from each sensor was noisy, and when pressure was applied to one, the output voltage would spike suddenly and take a long time to return to the baseline. To counteract the noise and the sudden spikes in output, we used a rolling average in the sensor code to average the last 10 samples over 1 second. In an attempt to deal with the slowly stabilizing output, we used a longer rolling average over 5-10 seconds to calculate a baseline. The sensor value used for control was calculated as the short-span average divided by the long-span average. With this algorithm, noise was removed and sudden spikes were smoothed out, and the output depended on recent, relative changes in pressure, so the changing baseline of the velostat didn’t matter as much.
However, when we tested this new system by riding the board and graphing the output velocity, we saw that response to motion was slow and the acceleration and deceleration did not always reflect what the rider was trying to do. Velostat is not a reliable material, and the calculations we were using to try to compensate for its unreliability resulted in an output that was too far removed from the intended movement. We could not get meaningful information with these sensors, so we decided to upgrade.
We purchased a bathroom scale and removed the 4 strain gauges from it, since bathroom scales are generally reliable and sensitive for detecting weight, and the strain gauges in them are designed to measure the weight of something as heavy as a human. We routed spaces in the top of the board to place the strain gauges in and made foot pads for the rider to stand on which would press on the strain gauges.
Despite our efforts to incorporate these into the board, we did not end up using them for control on demo day because 3 of the 4 strain gauges turned out to be defective. Until we purchase new strain gauges, our board is currently being controlled by a remote controller.
Our motors are controlled by ESCs (electronic speed controllers), which connect to the power supply and a signal connection and control the speed of the motors. ESCs are programmable, despite not generally having any sort of interface for doing so. The ones we used only had a single button used for both power cycling and programming, a buzzer with 3 pitches, and a red and green LED light. Using our software intuition and a poorly translated instruction manual, we managed to determine which sequences of long and short button presses correspond to setting high, neutral, and low speed settings.
We had success in connecting the ESCs to a remote control receiver, calibrating them to the RC signal, and driving the motors forward and backward with the RC.
We had trouble finding examples of Arduino code that could control the ESC. We found one example using the Servo library which alternated between driving the motors at high speed, then shutting them off. In order to figure out what range of PWM values corresponded to different speeds, we attached the signal from the remote controller to an oscilloscope and measured the pulse widths. Taking these values and writing them directly to a PWM pin on the Arduino didn’t work; the ESCs needed to be re-calibrated since evidently the Arduino code produced an unfamiliar signal. We wrote a script to set the PWM value from the command line so that we could calibrate the ESC with the Arduino, but for some unknown reason the ESCs would not complete the calibration procedure when we tried this.
Later, we found a code example which started by sending gradually increasing values to a servo object. This successfully controlled the ESCs when they were still calibrated to the RC signal. We believe that this worked better because the ESC expects to gradually increase the motor speed, and does not respond well when it is commanded to immediately jump to a speed. We incorporated the ramping-up method into our control code, and tested the motors with our command-line controller to determine the values for brake, neutral and full speed.
Although we were eventually able to control the ESCs with the Arduino, we could not use the pressure sensor speed control code because our pressure sensors did not work.