VR Bike – Version 2 – Electrical Documentation

Created by Kevin Carbone

Overview
From January through July of 2019, a group of Drexel University students (primarily members of
Drexel’s Theme Park Engineering and Design Group and Extended Reality Club) created a 2nd iteration of
an original motion platform featuring custom inputs, motion cues, and haptic feedback that ultimately acts
as a controller for virtual reality games. This motion platform, titled the Virtual Reality Bike, allows for a
single patron experience centered around three degrees of freedom: passive, user-controlled roll and yaw
and active, operator-controlled pitch.
This document has been created to preserve the electrical and software design of the Virtual Reality Bike
and can be used as a reference when enhancing or trouble shooting the existing ride1 or similar devices.
Please note that this document does not cover the mechanical, game, or aesthetic design of the bike; other
resources are available to help preserve those components.

Terminology
Below is a collection of relevant terminology, descriptions and tips concerning the electrical and software
design of the Virtual Reality Bike:

Microcontroller – Small electronic device that can control various devices (like our actuator and fans)
by varying voltages on the device. For this project, we used two microcontrollers. These controllers are
Arduino UNOs.

Motor Controller – Although a microcontroller can control the “logic” of a circuit (e.g. turning off and
on something), some circuits require larger amounts of power to be able to turn devices on and off. A
motor controller is a specific type of controller that can harness high power sources (such as our external
battery used to power the actuator) and be able to channel that power into devices.

• In our actuator circuit, we use a motor controller to interface between an Arduino UNO, external
power supply and our actuator. While the Arduino takes care of our “logic” in this circuit, the
motor controller acts as an intermediate device which can accommodate the actuator’s need for a
larger power intake.

Duty Cycle – Since the actuator works via an electric motor, when it’s in use, it produces heat as a
byproduct. The longer the actuator runs, the more heat it produces, increasing its chances of overheating.
A duty cycle is a percentage that informs an end-user about how long a piece of equipment should be
powered relative to the amount of time that the equipment needs to be powered off to ensure proper
behavior.

• The actuator used for the bike has a 25% duty cycle, which means that for every 25% of the time
it is running, it needs to be powered off for 75% of the time: a ratio of 1:3
• The two original games produced for the bike have a duration of 2 minutes (our ride cycle). It
was assumed that the actuator would be powered for this entire 2 minutes, so therefore, the
actuator was required to be powered off for 6 minutes after each ride cycle.

1
 • During the spring of 2019, a conversation was had with an engineer from ServoCity (the
manufacturer of the electric actuator we used for this project) to discuss whether the load
of our rider would affect the rated duty cycle. The engineer was confident that the
actuator could handle the load we presented and suggested that the duty cycle could even
be exceeded without our current use case.

Transducer - a device that converts variations in a physical quantity, such as pressure or brightness,
into an electrical signal, or vice versa.

• In this project, the electric throttle, buttons, and fans can be considered transducers:
o The electric throttle converts rotational motion into an electrical signal.
o The buttons convert achieving a certain pressure threshold into an electrical signal.
o The fans use an electrical power supply to stimulate the rotational of blades which
produce wind.

Relay – a collection of switches that can open and close electromechanically or electrically. If a certain
component needs a higher power supply than a microcontroller can provide, but you would like to still
control the time at which this component is powered, a relay is commonly used.

• In this project, the fans were originally controlled using a relay. The relay design was abandoned
when the VR Bike traveled to SIGGRAPH 2019 because the relays were damaged. The fan
circuit omits the implementation of relays.

Interrupt – an input signal to a processor indicating that a certain event that needs immediate attention.
An interrupt signal stops the currently executing code and executes the event in a timely manner.

Serial (UART) Communication – the process of sending data one bit at a time, sequentially, over a
communication channel. Serial communication is the most common form of communication used by
microcontroller beginners. SparkFun has an article that explores serial communication more closely.

Inter-Integrated Circuit Protocol (𝑰𝟐 𝑪) – a serial protocol for two-wire interface to connect low-
speed devices in communication systems. Because an Arduino UNO is only able to establish one UART
connection at a time, 𝐼 2 𝐶 was investigated and ultimately used in the project in the event a single Arduino
UNO needed to communicate to two controllers at the same time. This functionally was ultimately not
needed, but the 𝐼 2 𝐶 was still used as the serial protocol between the Arduino UNO and motor controller
in the actuator circuit.

Specific Equipment Used

Below is a list of the specific equipment used to create the three VR Bike circuits. Important equipment
has been given in-depth explanations:

Arduino UNO – An open-source microcontroller board developed by Arduino.cc. The board has 14
digital I/O pins, 6 analog I/O pins, and is programmable with the Arduino IDE (Integrated Development
Environment).

Pololu High-Power Simple Motor Controller G2 18v25

https://www.pololu.com/product/1366

2
8" Stroke 560 lb Thrust Super Duty Linear Actuator

Electric Motorcycle Throttle Grip

Bill of Materials
Item Price Quantity Link Total Price
Arduino UNO 22.00 2 Link 44.00
Pololu High-Power
Simple Motor Controller
G2 18v25
KMISS Electric Throttle Link
3.5MM Terminal Block 2.50 2 Link 5.00
Ablenet Spec Switch 65.00 2 Link 130.00
Uphere 3 Pack of 12.99 1 Link 12.99
Computer Fans
2.4 A Wall Charger 6.99 1 Link 6.99
400 W Switching Power 79.99 1 Link 79.99
Supply

3
Wiring Diagrams

Figure 1. Button and Throttle Circuit

4
Figure 2. Fan Circuit

5
 Figure 3. Actuator Circuit

Emergency Stop Button Design

Per ASTM F2291-14 section 10.3.4, which references ANSI T2.25.1M, Section 6.4.2.1, “emergency stop
or return control, or both, where identified by the Failure Analysis of amusement ride and device
equipment, [and therefore it is necessary to] incorporate an emergency stop or return control, whichever
provides more safety.” In an effort to adhere to this standard, an emergency stop button was incorporated
into the design of the VR Bike.
The function of the emergency stop button is to set the actuator speed to 0 m/s instantaneously. To
accomplish such a task, special accommodations must be satisfied from both a hardware and software
perspective. The accommodations needed from the software perspective, and the flow of execution, will
be examined first.
Typically, software executes a program line-by-line or sequentially and can only execute one line at a
time. Since it is imperative for each program that utilizes the actuator to break sequential execution and

6
immediately call a function that stops the actuator when the emergency button is pressed, it is necessary
to implement an “interrupt” within the software of these programs. Interrupt designs for Arduino UNOs
are well documented at: https://www.arduino.cc/reference/en/language/functions/external-
interrupts/attachinterrupt/
The 1st step in implementing an interrupt in software is to create a function known as an Interrupt
Service Routine (ISR) which has the sole purpose of stopping the actuator. Below is the ISR function in
both original actuator scripts:

Figure 4. ISR function present within actuator scripts

After declaring the ISR function, it is necessary to program the digital pin in which the emergency button
is attached. It is suggested that pin declarations be of the type “constant” instead of “variable” to ensure
the value of the pin will never change during execution.
Next, the pin the emergency button is attached to should be declared as an input. Once declared, both the
pin and ISR function should be attached as an interrupt pin and interrupt response, respectively, using the
“attachInterrupt” function. Figure 5 below represents where this interrupt attachment occurs in both
actuator programs. The last input “CHANGE” in the “digitalPinToInterrput” function means that the ISR
function will be called whenever the digital pin changes value (i.e. the emergency button is pressed).

Figure 5. Emergency button pin declaration and interrupt attachment

It is imperative to note that the contents of an ISR function should be kept as small as possible. An ISR
function is meant to be called and executed within only a few clock cycles, so therefore, it is highly
advised that calling functions or executing strenuous operations that require numerous clock cycles
should be avoided. In Figure 4 above, the “setMotorSpeed” function is commented out to demonstrate
that this behavior should be avoided.
Since the actuator cannot be stopped within the ISR function, an alternative approach is to create a
variable which will queue the program in on when to stop the actuator. In both the original actuator script
designs, a variable of type integer titled “breaker” was declared and initialized to a value of 0. When the
ISR function is called, this “breaker” variable is set to 1. Inside the “BeatNPath” and “HiveJive”
functions, the “for and while loops” responsible for adjusting the actuator speed break when the “breaker”
variable equals 1. Upon breaking the loops, the actuator speed is set to 0 using the “setMotorSpeed”
function. Figure 6 and 7 below demonstrate how the BeatNPath and HiveJive scripts set the actuator
speed to zero, respectively. It’s important to note that the HiveJive script always sets the actuator speed

7
back to zero when triggered, so the emergency stop button is purely used to stop future haptic feedback
responses from the actuator.

Figure 6. BeatNPath script with “breaker” variable highlighted

8
 Figure 7. HiveJive script with “breaker” variable highlighted
As was mentioned at the beginning of this section, a hardware accommodation is needed to make use of
interrupts on the Arduino UNO. In order to use interrupts and cater to instantaneous requests, it is
necessary to utilize one of two “interrupt” digital pins on the Arduino UNO when creating the emergency
button circuit. Digital pins 2 and 3 are declared as usable for interrupts according to the Arduino.cc
reference material.

Programming the Linear Actuator

Programming the linear actuator to provide active pitch during a patron’s experience in a virtual reality
game can be broken down into a few categories:
1. Necessary Actuator Functions
a. Discussion of functions that must be present in a script regardless of how the actuator
is programmed.
2. Legacy Approaches
a. Documentation on how the linear actuator in “Beat N Path” and “Hive Jive” was
programmed
3. Recommended Approach
a. Description of recommended approach to programming the actuator for both speed
and ease
4. Next Steps
a. A quick discussion concerning additional methods in which the linear actuator may
be programmed
In the ensuing sections below, these four categories are discussed.

1. Necessary Actuator Functions

9
It’s important to mention that the fundamental goal at hand is to use a linear actuator to enhance the
sensation of pitch created within a virtual environment by physically moving a patron. The critical
component at play is syncing the pitch created by the actuator with the environment in the digital world.
It’s imperative to approach design with the linear actuator from this angle because the actuator can be
used to mimic a limitless number of vertical sensations depending on the speed and timing constraints
provided to the actuator controllers. Therefore, it is crucial to understand that although the methods I’m
about to describe to program the linear actuator are the ones the original SIGGRAPH group settled on,
there are a myriad of other ways to exploit the sensation of pitch in the virtual world.
As was mentioned when discussing the actuator circuit design, a motor controller is needed to handle the
25 amp, 30-volt power supply necessary to power the actuator. Since it was imperative to our design to
incorporate an emergency stop button, it was decided that an Arduino UNO would be implemented
alongside the motor controller to handle the logic associated with the emergency stop button. Therefore, it
was a necessity for both the Arduino UNO and Pololu motor controller to communicate with each other.
A common serial protocol used to communicate between multiple controllers is serial communication.
Although serial communication is

10
Neutral Actuator Function

2. Legacy Programming Approaches

11
12
Explanation of Button and Throttle Scripts
On the VR Bike, there exist six devices which can be separated into two categories:
1. Game Input Devices
2. Haptic Feedback Devices
The “game input devices” allow the patron to directly effect the game enviornment by interacting with
them. On the VR Bike, the “game input devices” include the electric throttle and the two large buttons.
The “haptic feedback devices” are non-user controlled, and are used to provide the patron with both
immersion and spatial awarness. The “haptic feedback devices” include the three computer fans mounted
on the front of the bike.
As was described earlier, there exists three “game input devices” on the VR Bike that can be utilized to
give a patron the ability to change the game enviornment: the electric throttle and the two large buttons on
the handlebar. Since the goal of these devices is to allow the user to alter something within the VR game,
it was necessary to establish a connection between a microcontroller and the Unity game project.
To do this, a C++ script was created and loaded onto an Arduino UNO which categorized the electrical
signals from these devices and stored them into variables. Once stored, these variables can then be
shipped off to a C# Unity script via serial communication for the game developer’s use. Below is a
summary of both the C++ and C# scripts:

Button and Throttle C++ Script

The “Throttle_and_Buttons.ino” script first begins by declaring the pins on the Arduino UNO that the
throttle and two buttons are attached to, initializing them as inputs in “void setup()”, and by declaring and
assigning initial values to variables that will be used to store the values read at the pin locations. Note that
the electric throttle is an analog device, therefore, it is connected to pin “A0,” which is an analog pin,
instead of, for example, pin 8, which is a digital pin. Also note that since the Ardunio UNO’s native serial
(UART) communication will be used in order for the C# script to read these variables, the “void setup()”
function requires a serial port to be intialized. The value “9600” is called the baud rate and represents the
amount of symbols per second the serial port is capable of transmitting. “9600” is typically the lowest

13
transmission rate. If you wish for a game element to respond more instantanouesly to a button press or a
change of the throttle, increase the baud rate. If the baud rate is increased too high, however, transmission
errors will result. Below is a figure of the initial setup:

Figure 11.
The remainder of the C++ script is comprised of three functions which are responsible for sending the two
button and throttle values to the C# Unity script. Figure 12 below features the first two functions:
“SendLeftButtonData()” and “SendRightButtonData().” Both these functions read the value of the
respective digital pins each button is attached to, saves that value as a variable, and then prints the value
on the serial monitor which was initialized earlier.

14
 Figure 12.
The “SendThrottleData()” function in Figure 13 is slightly more complex because the throttle is an analog
device. In this function, the analog pin that the throttle data wire is attached to is read and saved as a
variable. Once saved, this variable is checked against the maximum and minimum most values the throttle
is capable of outputting. Note that these maximum and minimum values were determined through testing.
Once it’s determined that the analog value falls within our expected range, that value is then mapped to a
more Unity friendly range of -360 to 360. Note that is “mapping” function can be altered to fit the needs
of user, but -360 to 360 tended to work for the original project. Finally, simiarly to the button functions,
the mapped throttle value is printed on the serial monitor. If the mapped throttle falls outside of range of -
360 to 360, the last valid mapped throttle value is printed on the serial monitor.

Figure 13.

The last section of the C++ script involves calling the above functions in the “loop()” function featured in
Figure 14. There are two important pieces of information to note within the “loop()” function: Firstly, the

15
order in which these functions are being called is important. Looking back at the top of Figure 11 and
within the “SendLeftButtonData()” function of Figure 12, there exists a constant titled “OUR_VAR”
which is assigned the character ‘R’. Each time the C++ script completes all three functions, a single string
of values is printed on the serial port, starting with this ‘R’ character. This character is used to help the C#
script identify when a new set of button and throttle values arrive. An example of the output of the serial
port after a single “loop()” execution is as follows:

R0:35:1
The second important piece of the “loop()” function is the intentional delay. A delay of 16.6 milliseconds
is needed to ensure that the only 60 unique strings will be printed on the serial monitor per second. The
Unity project for the original VR Bike ran at 60 frames per second, so therefore, if more than 60 strings
were printed, certain lines would be omitted when read by the C# Unity script. I don’t believe it’s the end
of world if more than 60 strings are printed per second, but there’s no use in pursuing faster computation
than necessary.

Figure 14.

Button and Throttle C# Unity Script

16
Regardless of the method used to program the linear actuator, it is important to understand the 1st line of
C++ program includes the syntax “#include <Wire.h>.” This line configures the Arduino UNO to
communicate with 𝐼 2 𝐶 devices. For more information on the Arduino Wire library, please see
https://www.arduino.cc/en/reference/wire.
The next section of the program declares and initializes constants and variables. The 2nd constant,
“smcDeviceNumber,” is a mandatory constant needed to communicate with the motor controller. The
volatile variables pertain to the emergency stop button; the “Emergency Stop Button Design” section
gives further explanation concerning these variables.

Fans:
• Come with a 4-pin and a 3-pin interface
• “Okay” to snip off 4-pin interface
• Only utilize the right two pins on the 3-pin interface

• Understanding equipment, we used

• 3 main circuits
o Picture of the circuit followed by an explanation
o Understanding design choices within each circuit
• Explanation of the pin-to-pin sheet
• Explanation and detailed description of the button and throttle script
• How to program the linear actuator
o BeatNPath specific
o HiveJive specific
• Resources
• Next Steps

Reference Materials
1. For more information on the Arduino “Wire” library:

17