Monitoring Pod Movement

By: Ruth Zachariah

05 Jan 2021

The Electronics system within Hyperloop is used to command and control the pod. Sensors are by far one of the most important elements for monitoring the needs of the pod, and will be the focus in this blog. 

The primary function of sensors is to detect pod movements throughout the launch such as displacement, velocity and acceleration. How can we accurately measure the pod movements throughout its journey? For example, in UC Santa Barbara's Hyperloop from 2018, thin detective strips were placed every 100 ft, within the tube, to measure these parameters [1]. Roll, Pitch and Yaw are specific types of movements over a three dimensional axis in which a Hyperloop pod travels which are also taken into account. Roll is meant by moving left or right within the tube; pitch allows an object to travel upwards or downwards; yaw enables an object to spin about its axis [2]. Hence, monitoring the pod’s movement is paramount to safe and steady travel.

In addition, sensors play a vital role in communicating the status of the pod. While the Electronics system is connected to its Software system, sensor data is being collected and updated instantly.

Figure 1: Sensor locations around UC Santa Barbara Hyperloop Model [2]

In Figure 1, you can see various types of sensors spread across the pod. To allow for fast communication between all on-board sensors, a local network known as Controller Area Network (CAN-BUS) is typically used.

If the pod operates in unfavourable conditions such as large deviations in velocity or using frictional brakes at lower speeds, the control system overrides the commands of the individual pod element like drive wheel, friction drive brakes, liquid cooling etc. This is carried out by sending an emergency state command from the Master Unit which filters down to all of the Control Hub Units, taking control of the pod element(s) [3]. The purpose of having an emergency state command is to allow for immediate response to real-time vehicle conditions.

Given that the pod runs by on-board sensors off a wireless network, how do we ensure that there are little to no network interruptions? Based on Waterloop's Hyperloop model, redundancy measures prevented unexpected pod stoppage in the event of any Hub Unit or Master Unit malfunction. Using their algorithm, Deterministic Finite Automata (DFA) they were able to connect all the Master Units in parallel [3]. At any given point in time, there will be one ACTIVE MU while the remainder of MUs operate in IDLE state. If the ACTIVE MU fails, a signal (heartbeat) is sent to the next MU to enter the ACTIVE state, while the FAILED MU reboots itself. Once rebooted, the FAILED MU switches to IDLE state after the machine is restarted [3]. Throughout this process, the Watcher Unit will be monitoring the heartbeats of all Master Units. Overall, this iterative method ensures that the system runs without any interruption and will always have an ACTIVE MU running.

As we have covered how sensor data is collected and shared between pod elements, Controller Hub Units and Master Units, Hyperloop operators may need to view this information. The control panel receives data via the control system and displays the information through dashboards [3]. It goes to show how small elements such as sensors play a huge role in effectively relaying the pod conditions while in operation.

References

[1] UCSB Hyperloop Controller. California: UC Santa Barbara. 

[2] "Roll, Pitch & Yaw Explained for Beginners", Dronesvilla, 2020. [Online]. Available: https://dronesvilla.com/roll-pitch-yaw/. [Accessed: 28- Dec- 2020].

[3] R. Nikolaev, R. Idiatuallin and D. Nikolaeva, "Software system in Hyperloop Pod", Procedia Computer Science, Waterloo, 2021.

Back to all blogs