Test setup

Hi, I am Kevin van der Toorn, an EWI (EEMCS) student working in a dream team. This are multidisciplinary student teams at the TU Delft competing at international competitions with their own vehicles. You have heard about them in the news for sure. Think about the car working fully on solar energy, or the fastest human powered bicycle. I am working at Delft Hyperloop. Very briefly, the Hyperloop concept is a new form of transpiration that consists of a near-vacuum tube, with vehicles (“pods”) moving through it close to the speed of sound. Because of the low air drag in near-vacuum, the Hyperloop is way more efficient than traditional forms of transportation.


Delft Hyperloop competes in the SpaceX Hyperloop Pod Competition, which is aimed at proving the feasibility of the Hyperloop concept. Student teams from around the world are competing, and the best ones will be placed in a tube of one mile (1.6 kilometers) trying to get the highest speed. What must not be forgotten, is that the pod also needs to come to a standstill before the end of the tube to avoid a collision.

Contrary to a car or bicycle, you cannot just use the road to test your Hyperloop pod. It is made for traveling on a special track. Making our own one-mile track is financially and practically not possible.

That is why we made a giant spinning wheel with the same shape of the track. On this wheel, we can test our systems, such as stabilization wheels and braking pads. From this tests, we want to gather data that is crucial for our pod. This means we need sensors for measuring things like pressure, speed, vibrations, and temperature. Besides these sensors we also need hardware and software for acquiring the measurements, displaying it during the test, and saving it. The systems also need to control everything, from starting the motor to activating the brakes.

The hardware and software system begins at the sensors, which are connected to a device called a DAQ (standing for data acquisition). In its use, it is similar to a microcontroller like an Arduino. It is specialized in acquiring data and has a much higher sampling frequency. This device is connected to a PC running a Python script we developed. This script logs the data to a file and sends it, over our own wired network, to our office 30 meters away. (It is too dangerous to be nearby when the wheel is spinning.) Here, another application that we developed visualizes the results in real time. It also works the other way around. Someone from the team presses a button on the computer in the office, a message goes via the PC to the DAQ, and the wheel starts spinning.

By making the hardware and software system I learned a lot. From the hardware side, I learned the practicalities of connecting sensors and acquiring the data. I learned how to deal with magnetic interference, which is a huge problem when having high amounts of currents nearby. (These are caused by the power supply of the motor.)  And how to troubleshoot a sensor that does not give the information you expect.

From the software side, I learned how to set up a LAN computer network. It is basically putting the knowledge of the subject Computer Networks (Computer Science) or Telecommunication Networks (Electrical Engineering) in practice. I also learned new ways of programming user interfaces.

All with all, it was really useful and fun to put the knowledge I acquired from the bachelor in a real-world scenario.