Post on 23-Jul-2020
transcript
DISTRIBUTION A: Approved for public release; distribution is unlimited. Approval given by 88ABW/PA, 88ABW-2015-4073, 26 Aug 2015
Developed by:
The teachers, students, and mentors in the
Gaming Research Integration for Learning Laboratory® (GRILL®) Summer 2015
Full Throttle STEM®: Karting Simulation
Challenge Problems and Resources
Full Throttle STEM®: Karting Simulation 2 Distribution A.
TABLE OF CONTENTS
1. The Challenge ................................................................................................................................................ 3
1.1. Key Questions .............................................................................................................................................. 3
1.2. Background and Application ........................................................................................................................ 3
1.3. Potential Tools ............................................................................................................................................. 4
2. Aspects of a Solution ..................................................................................................................................... 4
2.1. Technology Resources .................................................................................................................................. 4
2.1.1. Hardware ............................................................................................................................................. 5
2.1.2. Software .............................................................................................................................................. 5
2.2. Potential Issues ............................................................................................................................................ 5
2.2.1. Z-fighting ............................................................................................................................................. 5
2.2.2. Creating a User Interface ..................................................................................................................... 9
2.2.3. Low Framerate .................................................................................................................................. 13
2.2.4. Oculus Head Tracking Movement ..................................................................................................... 18
2.2.5. Creating a Game Controller from a Microcontroller ......................................................................... 20
2.3. Problem Solving Timeline ........................................................................................................................... 26
Full Throttle STEM®: Karting Simulation 3 Distribution A.
1. THE CHALLENGE
Full Throttle Indoor Karting is a high-speed and competitive indoor go-kart racing facility.
Students are challenged to develop a driving simulation by closely mirroring the development
pipeline used by commercial game studios with an emphasis on free tools and technologies.
Challenge students to outfit a go-kart frame with a steering wheel and pedals turning it into a
virtual joystick such that drivers will interact directly with the real-world go-kart control inputs
while piloting the simulator. The purpose of the challenge is to increase customer interest,
enhance safety, and improve driver performance by developing an immersive simulator of the
track.
1.1. KEY QUESTIONS
What commercial off-the-shelf (COTS) game engine is most appropriate for this task?
What supporting software is required to develop a racing game (3D modeling, texturing,
rigging, etc.)?
What aspects of fidelity are important to the development of a racing simulation
(physics, graphics, sound, etc.)?
Is multiplayer a key element for this application?
Are there examples of commercial racing software/simulations that can be used to
gather example data such as the feel of driving a particular vehicle?
What is the intended platform for development (pc, mobile, etc.)? What are the
specifications required (speed, ram, etc.)?
What hardware sensors are best suited for use in controlling the virtual vehicle?
What drivers/software are needed to use a microcontroller to control in-game actions?
What budget is available, if any?
1.2. BACKGROUND AND APPLICATION
The Gaming Research Integration for Learning Laboratory® (GRILL®), under the Air Force
Research Laboratory 711th Human Performance Wing, Human Effectiveness Directorate
Warfighter Readiness division, leverages commercial off-the-shelf (COTS) game-based
technologies to increase the operational efficiency and effectiveness of the United State Air
Force Airmen. Continuing to utilize new technologies to provide more efficient and more
effective training is vital to the success of the laboratory and airmen training. We are seeking
to leverage the rapid prototyping ability of modern COTS game engines to generate an easily
modifiable virtual environment. The primary goal of this effort is to evaluate the feasibility of
testing safety, signage, and potentially the interaction with other human or computer agents in
a virtual environment while utilizing operationally accurate control systems.
Full Throttle STEM®: Karting Simulation 4 Distribution A.
1.3. POTENTIAL TOOLS
Game Engines
Unity 5
Unreal
iRacing
XFactor
3D modeling
Sketchup
Meshlab
Blender
3ds Max Student
Texture Editing
Photoshop
Paint.net
Arduino
Development environment
Sensors (potentiometers, accelerometers, etc.)
2. ASPECTS OF A SOLUTION
A solution was created during the summer of 2015 by participants in the Wright Scholar
program in collaboration with the Gaming Research Integration Learning Laboratory® (GRILL®).
The solution that follows was arrived at by the program participants during their nine week
experience, so this is not the only way, nor is it intended to be the best way to solve the
problem. The solution is given to provide guidance for future use. This section details the
technology used in the solution and some of the issues encountered on the way to a solution,
accompanied by documentation on how each issue was resolved.
2.1. TECHNOLOGY RESOURCES
Your students will likely choose different hardware and software to complete this Challenge
Problem. Better hardware at a cheaper price, a newer version of the software, or free open-
source technology may be available when your students tackle this problem. Detailed below
are the tools used in the construction of this solution at the GRILL® during the summer of 2015.
Do not limit your students to the specific technology mentioned in this document. Encourage
students to search for a resource that allows them to continue making progress toward their
solution.
Full Throttle STEM®: Karting Simulation 5 Distribution A.
2.1.1. HARDWARE
Racing Peripherals
The solution used Logitech Driving Force GT steering wheel and pedal system.
Virtual Reality Headset
The solution used the Oculus Rift Development Kit 2.
Microcontroller and sensors
The solution used an Arduino Uno microcontroller, Funduino Joystick Shield, and an
accelerometer.
Go-kart facility
The solution used Full Throttle Karting.
Go-kart
The solution used a SodiKart.
Racing flag
The solution used the flags at Full Throttle Karting.
3D model racecar
The solution used the NASCAR racing car.
2.1.2. SOFTWARE
Game engine
The solution used Unity 5.0.
3D modeling software
The solution used Blender.
3D modeling software
The solution used SketchUp 2015.
2.2. POTENTIAL ISSUES
While working on the solution for this Challenge Problem at the GRILL® summer 2015 program,
participating students encountered a number of different issues along the way. Included in this
document are those issues that teachers or students who tackle this problem in the future
would also likely encounter. If your students approached the Challenge Problem using different
tools, they may not experience these exact issues. Issues are ordered based on when they
arose in the process. Participating students did not document every single issue they
encountered; this document includes issues that could be potential hurdles others might need
to be able to resolve.
2.2.1. Z-FIGHTING
Full Throttle STEM®: Karting Simulation 6 Distribution A.
Z-fighting is an issue where two or more objects or faces are overlapping, or are fighting over
the same position. In SketchUp, the issue is most likely position, while in Unity it is usually
overlapping faces. Z-fighting can cause a flickering or flashing effect (Figure 1 and 3) when
viewed from different angles. To make the image have a single graphic, the number of surfaces
occupying the exact same position needs to be identified (Figure 2 and 4).
Figure 1: SketchUp 2015 model of Z-fighting
Figure 2: SketchUp 2015 model no Z-fighting
Full Throttle STEM®: Karting Simulation 7 Distribution A.
Figure 3: Unity 5.0 model of Z-fighting
Figure 4: Unity 5.0 model no Z-fighting
2.2.1.1. RESEARCH CONDUCTED
When the image was viewed on SketchUp 2015 flickering, it was a confusing and presented a
new issue. A senior computer scientist was consulted to see if the problem could be identified.
The query “why are images flickering in sketchup” was used to search the problem. The first
and second websites provided in 2.2.1.2. were used to find a solution. The flickering had a
technical name, Z-fighting. The video on this website was very informative; the same video was
found on several different websites. It explains different situations that can be encountered
while working in SketchUp 2015.
Flickering was encountered in Unity 5.0 as well. The senior computer scientist was consulted
again to see if the problem was identified as Z-fighting as well. Then Z-fighting was searched to
see if there were alternate solutions for Unity 5.0. Google was used to search “why are objects
Full Throttle STEM®: Karting Simulation 8 Distribution A.
shimmering in unity.” The given solution on the third website provided in 2.2.1.2 was very
obvious to the reader, to delete the faces that are overlapping.
2.2.1.2. RESOURCES
WonderHow To: How to Fix Z-fighting in SketchUp, explains Z-fighting in detail
http://software-tips.wonderhowto.com/how-to/fix-z-fighting-sketchup-143329/
SketchUp Community: Paint bucket glitch when overlaying two colors, contains a useful
video
http://forums.sketchup.com/t/paint-bucket-glitch-when-overlaying-two-
colors/2024
Unity Answers: Stopping overlapping textures from flickering, explained Z-fighting with
overlapping faces
http://answers.unity3d.com/questions/235802/stopping-overlapping-textures-
from-flickering.html
2.2.1.3. IMPORTANT CODE
N/A
2.2.1.4. RESOLUTION
After determining the cause of the issue of the flickering objects, as well as its technical name
(Z-fighting), the solutions were applied easily and quickly to the project. When the technical
name of the issue was searched it brought up more technical answers. In the SketchUp 2015
software, the different faces were removed so that they weren’t occupying the same position.
After the objects were close but not exactly the same positions, the object stopped flickering. In
Unity 5.0, the faces were deleted from the garage doors as seen in Figure 1. For this object, it
worked great; however, with the flags, more problems arose. In order to keep the wanted
texture, faces were overlapped. To resolve this problem, Blender was used to create a plane as
well as a racing flag texture. The plane was able to render a texture which accomplished the
expected result, while avoiding Z-fighting.
2.2.1.5. STUDENT REFLECTION
I was a first-time user of SketchUp 2015, Blender, as well as Unity 5.0; however, my team
members were more acquainted with the software. With this came many challenges, especially
with Z-fighting. I encountered Z-fighting in SketchUp 2015 first, then in Unity 5.0 there were
many objects that had Z-fighting faces. With the racecar in SketchUp, the most difficult part was
Full Throttle STEM®: Karting Simulation 9 Distribution A.
trying to get the numbers close enough to the car without having the two faces intersect. The
image without Z-fighting can be seen in Figure 2. In Unity 5.0 on the other hand, with so many
objects that were Z-fighting I had to compare different solutions. Instead of trying to delete the
faces on the flags like I had done with the garage doors, I had to delete all the faces and create
new flags. The new flags also had texture on both sides whereas the previous flags only had
texture on one side. The last object that I thought was also experiencing Z-fighting was the
NASCAR racecar in Unity 5.0. However, the coloring problem with this object was due to the
transparent coloring. In other words, pieces of the car would shine through the opposite side of
the car to create a strange image. To fix this, I used standard coloring to fill in the transparent
pieces. Finally, all the shimmering was gone and each texture was visible, as seen in Figure 4.
2.2.2. CREATING A USER INTERFACE
The Challenge Problem consisted of creating a fully-immersive simulator for Full Throttle Indoor
Karting. One aspect of the project was developing menus to access different areas of the
simulation. An issue occurred because the user would not have access to a mouse or keyboard.
Because of that, all control needed to be done with a steering wheel, gas and brake pedals.
The team decided that the menus needed to have a few different buttons. There would be a
“Play” button, “Briefing” button, “High Scores” button, and an “Exit” button. The user needed
to be able to select these buttons by some alternate means of input.
2.2.2.1. RESEARCH CONDUCTED
In order to figure out how to create a user interface (UI), research was done on the two
different methods by which a UI can be created in Unity. In previous versions of Unity (4 and
lower), all graphical user interface (GUI) was instantiated and handled through scripting. While
this was effective, it also required prior programming experience. With the release of Unity 5,
the engine was packaged with a built-in UI system to make the process faster and accessible for
more users. The group followed tutorials online to become familiar with the new system. The
Unity documentation, listed in the resources section below, was also referenced. The
documentation laid out the different UI objects that could be created.
Four buttons were successfully instantiated into the main menu scene. Soon after, a major
issue with this system was discovered. Since the user wouldn’t have access to a mouse and
keyboard, an alternate way to select the buttons needed to be researched: How could the
simulator collect input from the user without having to implement any extra hardware? A forum
post outlined how to use the concept of “look-based input” with Unity UI and Oculus VR. With
the script provided by the post, the center of the user’s view could act as an “invisible” mouse
pointer. When the view was centered on a button, the button highlighted (Figure 5). The user
Full Throttle STEM®: Karting Simulation 10 Distribution A.
could then simply press the gas pedal to select. This technique made it possible to receive input
without the use of any extra hardware.
Figure 5: An example of being able to look at a button to highlight it
2.2.2.2. RESOURCES
The Unity website has expansive documentation on all aspects of their engine online.
For information on the old (Legacy) UI system:
http://docs.unity3d.com/Manual/GUIScriptingGuide.html
For information on the new Unity UI system:
http://docs.unity3d.com/Manual/UISystem.html
Link with script for the Oculus “look select”:
https://forums.oculus.com/viewtopic.php?t=16710
The mentors who had prior experience and knowledge with Unity were also helpful in
overcoming this obstacle.
2.2.2.3. IMPORTANT CODE
Below is the code applied to the empty GameObject that runs when the button’s OnClick() function is called.
Table 1: Code for loading a level
using UnityEngine; using System.Collections; public class StartPlay : MonoBehaviour { public void PlayButton()
Full Throttle STEM®: Karting Simulation 11 Distribution A.
{ Application.LoadLevel ("KartSim"); } }
This code was used for modifying the buttons the user interacts with in the game.
Table 2: Creating and customizing a button with the old UI system
using UnityEngine; using System.Collections; public class oldSystemUI : MonoBehaviour { void OnGUI() { // Make a background box GUI.Box (new Rect (10, 10, 100, 90), "Loader Menu"); // Make the first button. If it is pressed, Application.LoadLevel(1) will be executed if (GUI.Buttn (new Rect (20, 40, 80, 20), "Level 1")) { Application.LoadLevel(1); } // Make the second button if (GUI.Button (new Rect (20, 70, 80, 20), "Level 2")) { Application.LoadLevel(2); } } }
2.2.2.4. RESOLUTION
To accomplish the task, the team first had to determine what the end result was supposed to
look like. The menu system would have to be easy for a wide range of people to use. Since
standard means of input wouldn’t be available, research was conducted on other options. After
reading about the “look select” concept, it was agreed upon as a team that it would be the
most suitable option for the simulator. It was easy to follow the information provided in the
post and the implemented code worked right away.
Full Throttle STEM®: Karting Simulation 12 Distribution A.
The look input functioned as the invisible “mouse cursor,” and the user would be able to select,
or click, that button by pressing the gas pedal. In the project, buttons were created that, when
clicked, would load a new scene. For example, the “Play” button in the main menu would load
the racing track scene. The Inspector interface for a UI button is shown in Figure 6 below. After
the button was in the scene, the user needed to be able to interact with it, and then load the
next menu. The button possessed a built-in OnClick() function. There was a simple process to
load the following scene. A new GameObject was created and a script was attached to it. The
script had one basic function named “PlayButton()” that had a call to Application.LoadLevel().
The GameObject was placed in the OnClick() section of the button’s Inspector window. When
the button was clicked, the new level was loaded. The new Unity UI system allowed for quick
creation of user interfaces as well as a broad customization of those interfaces.
Figure 6: Creating and customizing a button with the new UI system
2.2.2.5. STUDENT REFLECTION
Although I am very familiar with the Unity engine, I have never worked with the new UI system.
In order to overcome this obstacle, I needed to consult outside resources. In many cases, asking
one of my team members for assistance resulted in another issue arising. When we came to a
point where we were seriously stuck, one of the mentors would offer their knowledge. Using
web searches and the game engine documentation were also extremely helpful resources.
Through this experience, I was able to work closely with my colleagues and mentors and use
our combined knowledge to complete the task.
Full Throttle STEM®: Karting Simulation 13 Distribution A.
2.2.3. LOW FRAMERATE
While the racetrack was looking great, the aesthetics came at the expense of framerate. The
issue was not necessarily that the framerate was consistently low; instead, it stemmed from the
rapid change in framerate. The optimal framerate for any PC game is a consistent frames per
second (FPS) of 60 or above because most modern monitors have a refresh rate of 60 Hz.
Matching the FPS and the refresh rate gives the smoothest performance with the least screen
tearing. The FPS ranged from as high as 300 to as low as 7 (see Figure 7). When FPS spikes too
low it causes a noticeable stutter in the game, commonly referred to as “lag.” The drops in FPS
that were experienced caused the drivers to crash and raised the average lap time. Also, low
FPS caused the Oculus Rift virtual reality headset to lag behind slightly when looking around,
causing considerable motion sickness for some people. Smoothing out the FPS was necessary
in order to make the game feel more fluid and natural to the drivers.
Figure 7: Example of low FPS
2.2.3.1. RESEARCH CONDUCTED
Research was conducted primarily through online search engines. After a few minutes a
tutorial for using level of detail (LOD) was discovered. The tutorial explained that without using
LOD, all of the 3D models in the game are rendered at all times, even when they cannot be
seen. By using LOD, the model changed to a lower quality version when it was far away or out
of sight, thus saving computing power. The next step was to identify the models in the project
that had too high detail. Five or six models were found that were rendered with extremely high
detail and had no real significance to the project (see Figure 9-11). The tire, for example, had
over 2,000 polygons and there are nearly 1,400 tires in the game (see Figure 8). Finally, a
mentor was consulted and an explanation was provided that by baking the light map, and
tweaking the shadows settings on our lights the FPS could drastically increase.
Full Throttle STEM®: Karting Simulation 14 Distribution A.
Figure 8: Very high detail on a tire
Figure 9: Extremely high vertex count on a spring
Full Throttle STEM®: Karting Simulation 15 Distribution A.
Figure 10: Example of the large number of spring coils
Figure 11: Showing the number of spring coils
2.2.3.2. RESOURCES
This link provides a basic overview of what LOD is and what it does in the Unity engine.
http://docs.unity3d.com/Manual/LevelOfDetail.html
This link shows how to manipulate the LOD group in order to make the changes
between the different levels of detail as smooth as possible.
http://docs.unity3d.com/Manual/class-LODGroup.html
This link shows LOD in action in the unity engine and shows how to implement it.
https://www.youtube.com/watch?v=IzlU_xvTK3Y
Full Throttle STEM®: Karting Simulation 16 Distribution A.
2.2.3.3. IMPORTANT CODE
N/A
2.2.3.4. RESOLUTION
Four separate tires were created in Google SketchUp (see Figure 12-15). The highest detail tire
model was placed into the game engine. LOD was applied to the tires. Adding LOD is as simple
as adding it as a component. The LOD group and the LOD bias were changed to display the
correct level of detail at each distance. The exact settings of the LOD group and bias are based
on personal preference. Once the LOD was set on one tire, it was saved as a prefab so that it
could be easily dragged and dropped and the LOD would stay the same. The rest of the models
that were too detailed were either deleted or remodeled to have a lower poly count. For
example, the springs added no real value to the game, and were hardly visible at all, so the
springs were deleted in their entirety. Finally, the light map was baked, which improved the
performance of the lighting and made the track look slightly better too. The last step taken to
ensure that the maximum framerate was achieved was to completely disable shadows. This
provided the second largest performance increase (after the removal/remodeling of the 3D
models). After all of these changes were applied, a drastic increase in FPS as well as a 97%
decrease in vertex count was observed (see Figure 16-17).
Figure 12: Highest level of detail
Figure 13: Second level of detail
Full Throttle STEM®: Karting Simulation 17 Distribution A.
Figure 14: Third level of detail
Figure 15: Fourth level of detail
Figure 16: Example of average FPS and vertices count after the solution was applied
Figure 17: Example of FPS drop and high vertices count before solution was applied
Full Throttle STEM®: Karting Simulation 18 Distribution A.
2.2.3.5. STUDENT REFLECTION
Resolving the issue of low framerate was definitely a team effort. All of our team members
were scouring the map looking for models with high vertex counts. Each of our team members
made a tire to contribute to the LOD that we created. We all knew that without a decent FPS,
the game would be practically unplayable. I think that is why we were so determined to find a
solution to this problem. Personally, I found that resolving this issue was frustrating at times,
but rewarding in the end. Configuring the LOD group and bias took a lot of tweaking to get
right, and required us to manually replace all of the previous placed tires (all 1,400 of them).
We took turns placing the tires, and completed around 350 per person before switching.
Placing the tires was grueling work, and it took all day. However, the performance increase we
observed the next day made it all worthwhile. Actually being able to play the game without any
stuttering was rewarding, and it meant that we could finally start with the next phase of our
project.
2.2.4. OCULUS HEAD TRACKING MOVEMENT
The Oculus Rift DK2 tracks head movement of the wearer. This function allows for an
immersive experience with applications, but needs to be disabled for menu screens and
watching videos in the simulation (see Figure 18).
Figure 18: High Score screen before tracking was disabled
Full Throttle STEM®: Karting Simulation 19 Distribution A.
Figure 19: After tracking was disabled
2.2.4.1. RESEARCH CONDUCTED
Options inside Unity Editor and the online Unity Documentation were consulted. Options
including “Use Position Tracking” and “Time Warp” on the OVRCameraRig (Oculus Camera)
game object were tested, but neither had an effect. A more extensive Internet search was
suggested by a mentor. The solution was found from using a search engine with the query
“disable oculus tracking unity.”
2.2.4.2. RESOURCES
Oculus forums and Unity documentation were searched. This link ultimately solved the
problem.
https://forums.oculus.com/viewtopic.php?t=19863
2.2.4.3. IMPORTANT CODE
The first line is added near the top of the class definition of OVRCameraRig.cs.
The second line is added at the beginning of the UpdateAnchors() function in the script OVRCameraRig.cs.
Table 3: Code to disable tracking
Public bool disableTracking;
Full Throttle STEM®: Karting Simulation 20 Distribution A.
if(disableTracking) {return;}
2.2.4.4. RESOLUTION
Adding the public Boolean to the OVRCameraRig script enables a “disabletracking” toggle to
appear in the Unity Editor. The “if” statement in the very beginning of the UpdateAnchors
function will stop the function from running if the disableTracking Boolean is true, and this is
what stops the Oculus from tracking movement. The option can now be changed from the
editor. Also, the “Time Warp” toggle must be disabled on the OVRManager in the editor. Both
of these scripts are found on the OVRCamerRig Game Object.
2.2.4.5. STUDENT REFLECTION
The original idea to fix the Oculus head tracking was to use GUI objects to always display images
in front of the camera. We also tried to use the new Unity User Interface to display images in
front of the camera. We tried these methods for a few days but neither worked, and we gave
up on it for a while. The solution ended up being relatively simple, but was implemented in a
way we did not think was possible, by editing the Oculus scripts. Often when we do not think
we can solve an issue we revisit it days later and are able to find a solution.
2.2.5. CREATING A GAME CONTROLLER FROM A MICROCONTROLLER
For the final Kart Simulator the actual frame of a Sodi RX7 will be used as the game controller,
and the brake, gas, and steering wheel will be monitored to act as the game controller. These
parts of the kart will be monitored with sensors such as a potentiometer, rotary encoder, or
optic sensors. These sensors need to be connected to the analog or digital reads of a
microcontroller, in the case of the Arduino Uno. After the appropriate wiring and code is
written for the microcontroller, the device is not useable in the game. In order to achieve the
end simulator goal the microcontroller must be recognized as a game controller in the devices
of a computer.
Full Throttle STEM®: Karting Simulation 21 Distribution A.
Figure 20: The two microcontroller test setups Funduino (top) Accelerometer (bottom)
The two boards that were used to test the microcontroller – an Arduino Uno with a Funduino
joystick shield attached – are shown in the top of Figure 20. This could be programmed to
mimic a PlayStation controller. The second board is an accelerometer which could mimic the
pedal movements and a steering wheel.
2.2.5.1. RESEARCH CONDUCTED
What makes a game controller a game controller?
A game controller is recognized as a Human Interface Device (HID). A HID is a type of
computer device that interacts directly with, and most often takes input from, humans and may
deliver output to humans. The Arduino is recognized as a programmable microcontroller and
needs to be changed to an HID to become a game controller.
How can the Arduino become a game controller?
A search was made for ‘how to turn an Arduino into a game controller’. This resulted in finding
the Unojoy software. It was a free driver and software package that allowed this conversion of
this microcontroller. The process consisted of “shocking” the board by connecting two of the
resetting pins. What this accomplished was a default for the board into an unrecognized
processor chip. The Unojoy program had two programs, TurnIntoArduino and TurnIntoJoystick
and these determine the function ability of the processor after they are run.
Why is there so much noise in the controller?
Noise is the static of a connection. It causes random values to be scattered into the true data
which causes the controller to act in an unexpected manner. The static could be the fault of
bad hardware or an issue in the code. The first solution attempt was to switch the Arduino in
the hardware. After replacing the board the static still persisted which indicated it was a
Full Throttle STEM®: Karting Simulation 22 Distribution A.
programming issue. After “commenting out” different sections of the code to find the issue, it
was discovered that the serial monitor was interfering with the controller performance. The
constant attempt to transfer the data to a nonexistent outlet was causing the static.
Why does the accelerometer read no change in the game controller?
The Funduino was working fine but the accelerometer gave no readings as a game controller.
The first step was to unbitshift the data because the spec sheet for the accelerometer stated
that it started as 8-bit data instead of the 10 like the Funduino. This change did nothing to the
controllers’ performance. What was really the problem was the raw data range of 0/1023 did
not fit correctly to the joystick controller range of 0/255. The values of the accelerometer were
then measured at neutral positions then were remapped to correctly fit the 0/255 range.
When the values were completed, the controller worked to the correct standards.
2.2.5.2. RESOURCES
Unojoy software and drivers which allows the computer to change the microcontroller
to a game controller.
https://code.google.com/p/unojoy/
This link provided the interface between the accelerometer and Arduino with the raw
values being used to display the data in the serial monitor.
http://www.instructables.com/id/Interfacing-ADXL335-with-ARDUINO/step3/Code/
2.2.5.3. IMPORTANT CODE
These two sections of code take the data from the inputs and read them through to the micro controller.
This code operates the Funduino shield using the Unojoy library to transfer the data from the digital and analog pins to be used as a controller.
Table 4: Code for Funduino shield
#include "UnoJoy.h" void setup(){ setupPins(); setupUnoJoy(); } void loop(){
Full Throttle STEM®: Karting Simulation 23 Distribution A.
// Always be getting fresh data dataForController_t controllerData = getControllerData(); setControllerData(controllerData); } void setupPins(void){ // Set all the digital pins as inputs // with the pull-up enabled, except for the // two serial line pins for (int i = 2; i <= 12; i++){ pinMode(i, INPUT); digitalWrite(i, HIGH); } pinMode(A4, INPUT); digitalWrite(A4, HIGH); pinMode(A5, INPUT); digitalWrite(A5, HIGH); } dataForController_t getControllerData(void){ // Set up a place for the controller data // Use the getBlankDataForController() function, since // just declaring a fresh dataForController_t tends // to get you one filled with junk from other, random // values that were in those memory locations before dataForController_t controllerData = getBlankDataForController(); // Since the buttons are all held high and // pulled low when pressed, use the "!" // operator to invert the readings from the pins controllerData.triangleOn = !digitalRead(2); controllerData.circleOn = !digitalRead(3); controllerData.squareOn = !digitalRead(4); controllerData.crossOn = !digitalRead(5); controllerData.dpadUpOn = !digitalRead(6); controllerData.dpadDownOn = !digitalRead(7); controllerData.dpadLeftOn = !digitalRead(8); controllerData.dpadRightOn = !digitalRead(9); controllerData.l1On = !digitalRead(10); controllerData.r1On = !digitalRead(11); controllerData.selectOn = !digitalRead(12); controllerData.startOn = !digitalRead(A4); controllerData.homeOn = !digitalRead(A5);
Full Throttle STEM®: Karting Simulation 24 Distribution A.
// Set the analog sticks // Since analogRead(pin) returns a 10 bit value, // a bit shift operation needs to be performed // lose the 2 least significant bits and get an // 8 bit number that can be used controllerData.leftStickX = analogRead(A0) >> 2; controllerData.leftStickY = analogRead(A1) >> 2; controllerData.rightStickX = analogRead(A2) >> 2; controllerData.rightStickY = analogRead(A3) >> 2; // And return the data! return controllerData; }
This code reads the raw accelerometer and then remaps the maximum and minimum values to about 45 degrees which allows controller movement to read through as appropriate game controller data for the Unojoy controller.
Table 5: Code for mapping steering control
#include "UnoJoy.h" int max = 0; int min = 9999; int MAX_AXIS = 255; int X_LOW_RANGE = 204; int X_HIGH_RANGE = 50; float xFactor = MAX_AXIS / (float)(X_HIGH_RANGE - X_LOW_RANGE); int Z_LOW_RANGE = 225; int Z_HIGH_RANGE = 75; float zFactor = MAX_AXIS / (float)(Z_HIGH_RANGE - Z_LOW_RANGE); void setup(){ setupPins(); setupUnoJoy(); } void loop(){ // Always be getting fresh data dataForController_t controllerData = getControllerData(); setControllerData(controllerData); } void setupPins(void){
Full Throttle STEM®: Karting Simulation 25 Distribution A.
// Set all the digital pins as inputs // with the pull-up enabled, except for the // two serial line pins for (int i = 2; i <= 12; i++){ pinMode(i, INPUT); digitalWrite(i, HIGH); } pinMode(A4, INPUT); digitalWrite(A4, HIGH); pinMode(A5, INPUT); digitalWrite(A5, HIGH); } dataForController_t getControllerData(void){ static int xMax = 0; static int xMin = 999999; xMin = min( analogRead(A2), xMin ); xMax = max( analogRead(A2), xMax); int x = map(analogRead(A2), 264, 412, 0, 255); //-45 deg is 50 +45 deg is 204 int y = map(analogRead(A1), 264, 412, 0, 255); int z = map(analogRead(A0), 264, 412, 0, 255); // For rotation around the X-axis x-=X_LOW_RANGE; x *= xFactor; if (x > 255) { x = 255; } if (x < 0) { x = 0; } // For rotation around the Y-axis z-=Z_LOW_RANGE; z *= zFactor; if (z > 255) { z = 255; } if (z < 0) { z = 0;
Full Throttle STEM®: Karting Simulation 26 Distribution A.
} controllerData.leftStickX = x; //>> 2; controllerData.leftStickY = z; //>> 2; // And return the data! return controllerData; }
2.2.5.4. RESOLUTION
The solution to creating a game controller from a microcontroller was a balance of
programming work and software work. The wiring was the first step. The hardware work
wasn’t too much of an issue because the wiring was simple with only a few sensors and wires.
The software was the difficult part. After many searches the Unojoy software was discovered.
The library and drivers allowed the user to create a HID from the Arduino and peripherals. The
code was not exactly designed for the two set ups that were created so the code was adjusted
to fit the new controllers. For the Funduino some of the button inputs needed to be eliminated
and for the Accelerometer the values need to be unbitshifted and remapped to the standard
scale. All the controllers needed to be calibrated after setup to ensure maximum performance.
When the computer recognized the device as a joystick controller it immediately took the
controller data and made it acceptable for the Unity project. The controllers were tested for
the game. The Funduino system worked well in the game which was a positive, but its one
downfall was the unsuitability of the joystick as a control method. The joystick, similar to a
video game controller, did not have a practical use for the kart. The accelerometer was also
tested but proved to be very sensitive and inaccurate. It was tested because it would work well
as a noncontact sensor and would allow for a longer lifetime of the part. The practice of these
test devices will make the final kart wiring and programming easier and more familiar.
2.2.5.5. STUDENT REFLECTION
The issue was a challenge for sure. It took a few hours of work to solve an issue that seemed
like very little work. It takes hard work and time to overcome tough challenges like the ones
our team has faced. The things you learn from a challenge help you personally learn and grow.
This growth is the positive part of a challenge. It gives you a better grasp on problem solving in
the future.
2.3. PROBLEM SOLVING TIMELINE
Full Throttle STEM®: Karting Simulation 27 Distribution A.
Week 1 Week 7 Week 5 Week 3 Week 2 Week 4 Week 6 Week 8
Full Throttle STEM® Game Development Timeline
Z-fighting
In this issue there was some difficulty with objects overlapping or occupying the same position. Additionally, issues with creating a realistic texture for these objects were faced. Lastly, there was difficulty identifying the areas of Z-fighting and using the suggested solutions within the game.
Creating a User Interface
The problem consisted of developing menus to access different areas of the simulation. In the process of solving this problem, it was discovered that the end user would not have access to a mouse or keyboard. Therefore the controller had to use a steering wheel, gas pedal and brake pedal.
Low Framerate
One issue was that the aesthetics came at the expense of the framerate. The problem dealt with the demand for a rapid change in framerate. At low FPS, the Oculus Rift virtual reality headset would make the image stutter, referred to as “lag,” which could cause some motion sickness for the player.
Oculus Head Tracking Movement
The main issue with the Oculus Head Tracking was the calibration. Furthermore, the Oculus was needed as an immersive game controller as well as disable the movement while using it for menu screens and watching videos within the simulation.
Creating a Game Controller from Microcontroller
An issue found in this task was using sensors on the steering wheel, gas pedal, and brake pedal. The problem arose when converting a microcontroller into a game controller. The sensor used with the wheel and pedals was an accelerometer.
The Challenge
In this Challenge Problem students will be expected to use a variety of technology skills in order to create a realistic 3D game that will be used to examine go-kart performance in a specific track design.
Week 1
Learned modeling skills
on Sketchup
Received Challenge
Problem assignment
Group discussions about
roles
Week 2
Discovered the cause of
the lag with the Oculus
Rift
Fixed the low framerate
problem making the
image with the Oculus
rift clearer
Week 3
Created Sketchup model
of racecar
Experimented with
removing the flickering
from objects
Found simple solutions to
diminish flickering
Week 4
Improved main menu
screens
Had trouble with
understanding the UI
system
Identified the most
suitable option for
simulator
Week 5
UI continued
Researched “look select”
concept for buttons
Implemented the code
and the ideal solution
was reached for UI
Week 6
Learned how to properly
wire Arduino Board
Discovered the Unojoy
software
Properly programmed
Arduino Board
Week 7
Needed to unbitshift the
accelerometer values
Remapped the values to
the standard scale
The joystick was
inapplicable to the game
because the directions
were inverted
Week 8
Discovered disable
Tracking code
Used disableTracking
code on menu screens to
lock the player's view
Disabled “Time Warp” as
well on OVRCameraRig
Ch
alle
nge
Pro
ble
m R
ecei
ved
Solu
tio
n A
chie
ved
This timeline does not depict all of the issues students encountered as they developed the solution during the GRILL®
summer program 2015. Other issues arose during the problem solving process and were resolved within the given
timeline.