Full Throttle STEM®: Karting Simulation...Paint.net Arduino Development environment Sensors...

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


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.


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.


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


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


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


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

http://software-tips.wonderhowto.com/how-to/fix-z-fighting-sketchup-143329/

http://forums.sketchup.com/t/paint-bucket-glitch-when-overlaying-two-colors/2024

http://forums.sketchup.com/t/paint-bucket-glitch-when-overlaying-two-colors/2024

http://answers.unity3d.com/questions/235802/stopping-overlapping-textures-from-flickering.html

http://answers.unity3d.com/questions/235802/stopping-overlapping-textures-from-flickering.html


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.


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


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.


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()

http://docs.unity3d.com/Manual/GUIScriptingGuide.html

http://docs.unity3d.com/Manual/UISystem.html



{ 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.


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


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.


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


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.


Figure 8: Very high detail on a tire

Figure 9: Extremely high vertex count on a spring


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

http://docs.unity3d.com/Manual/LevelOfDetail.html

http://docs.unity3d.com/Manual/class-LODGroup.html

https://www.youtube.com/watch?v=IzlU_xvTK3Y



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


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



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


Figure 19: After tracking was disabled


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.



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;



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.


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.


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.


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


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/


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(){

https://code.google.com/p/unojoy/

http://www.instructables.com/id/Interfacing-ADXL335-with-ARDUINO/step3/Code/


// 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);


// 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){


// 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;


} 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.


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


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.

Date post:	23-Jul-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Full Throttle STEM®: Karting Simulation...Paint.net Arduino Development environment Sensors...

Documents