VISHUN Requirements Document
VISHUN™ – Autonomous Vehicle Simulator
Version: / 1.02Version date: / October 3, 2018
Author(s): / Jeff Moser
Rob Yost
Miguel Nieves
John Bell
John Miller
Synopsis
This document details the requirements for the Autonomous Vehicle Senior Design project codenamed “VISHUN”.
Document Control
Owned By: / Jeff Moser –
Distribution: / VISHUN Team
Jeff Salvage ()
Toban Emmanuel ()
Document History
Version: / Date: / Description: / Who0.5 / January 18, 2005 / First draft containing contributions from each individual member. / Everyone
0.6 / January 24, 2005 / Second draft containing revisions from each individual member based on commentary provided by Jeff Salvage. / Everyone
0.9 / January 31, 2005 / Third draft, revisions discussed in previous week’s group meeting including the addition of interface mockups. / Jeff Moser / Miguel Nieves
0.99 / February 8, 2005 / Final Draft before production copy includes the addition of additional interface mockups. / Jeff Moser /
Miguel Nieves
1.0 / February 15, 2005 / Production Draft / Jeff Moser / John Miller
1.01 / February 21, 2005 / Numbering Scheme Changed, added process flow diagram. / Jeff Moser
1.02 / March 14, 2005 / Made a few small changes to 2.5 and 2.6 to match up with decisions made during the design phase. / Jeff Moser
Table of Contents
1Introduction
1.1Purpose
1.2Project Scope and Features
1.3Terminology
2Functional Requirements
2.1High-Level Requirements
2.2Vehicles
2.2.1Default Vehicles
2.2.2Adding and Modifying Vehicles
2.3Maps
2.3.1Adding and Modifying Maps
2.4Interfaces and User Interaction
2.4.1Before the Simulation
2.4.2During the Simulation
2.4.3After the Simulation
2.5Log File
2.5.1Current Information
2.5.2Historical Information
2.6Major Components
2.6.1GPS
2.6.2LADAR
2.6.3Range-Finding
2.6.4Path-Finding
2.6.5Situation Management
3Non-functional Requirements
3.1Product
3.2System Requirements
3.3External Requirements
4System Evolution
5References
1Introduction
1.1Purpose
This document describes the functional and non-functional requirements for VISHUN, an autonomous vehicle simulator. VISHUN stands for Vehicle Interprets Sensors Hopefully Useful for Navigation.
1.2Project Scope and Features
VISHUN simulates a vehicle driving in a virtual world with user defined start and finish locations. The user selects one of three vehicles and if a path exists, the vehicle autonomously finds a path to the destination, while avoiding obstacles. The autonomous actions of the vehicle are decisions made by its path-finding AI “brain”, and are based on input from many different LADAR and range-finding sensors mounted on the outside of the vehicle. These technologies and their specific details are described in Major Components. For additional reference on the technologies and vehicles in this document, please see the links in References.
1.3Terminology
Autonomous Vehicle
A vehicle that essentially drives itself. No user interaction is required except for (at the very least) the initial specification of a starting point and destination(s).
Havok
The 3d physics engine used to simulate the real world physics and vehicle motion used in this simulation.
HKV
Havok Vehicle input file. Defines all the characteristics of the vehicles.
LADAR
Laser Guided radar sensors that search for objects within their field of view.
Range-Finding
Sensors that determine the distance between themselves and an object in front of them.
Path-Finding
Algorithms that determine the best path to get from a given location to a destination.
Virtual World
The 3D world where a simulation takes place. The virtual world for this project uses realistic gravity, distances, and speeds to best simulate driving in similar real world environment.
Waypoint
A point between major points on a route, a destination.
2Functional Requirements
2.1High-Level Requirements
The general requirements for the Autonomous Vehicle Simulator are as follows (note that all detailed interface descriptions and diagrams are found in Interfaces and User Interaction):
2.1.1.Obtain input from the user for selection of the starting and destination points by presenting the user with a graphical map of the environment, and allowing them to indicate starting and ending points with the mouse.
2.1.2.Obtain input from the user for type of vehicle by presenting the user with a virtual garage showing each vehicle and its basic statistics. Vehicles are displayed one at a time with an option to move to the previous or next vehicle.
2.1.3.Based on the input provided, perform the simulation, and take one of the following 3 actions:
2.1.3.1.Successfully navigate the vehicle to the specified destination.
Figure 1: Shows a vehicle successfully navigating a path while avoiding obstacles.
2.1.3.2.Conclude that reaching this destination is impossible immediately after receiving destination input (this is a failure)
Figure 2: Shows a failure situation, a start point overlapping an object. This will not happen.
2.1.3.3.Conclude that after attempting to reach the destination, no path can be found (this is a “no-solution” situation).
Figure 3: Shows a “no solution” situation where a vehicle cannot reach its destination while avoiding obstacles.
2.1.4.Upon success or failure, display one of several appropriate “finish” windows that provides the user the following:
2.1.4.1.Statistics detailing the time, distance, average speed, maximum speed, and number of autonomous actions.
2.1.4.2.An option to restart the simulator by returning to the main screen.
2.1.4.3.An option to exit.
2.1.4.4.An option to export world data to a file, including a much more detailed statistics summary showing where actions were taken, why they were taken, and the possible choices the path-finding brain had in making the decision.
Figure 4: The process flow diagram above shows a high level view of the progression of a typical application run from start to finish.
2.2Vehicles
This section defines the aspects and properties of vehicles as they relate to the simulation.
2.2.1Default Vehicles
The simulation initially provides three vehicles for the user to choose from. These vehicles are:
2.2.1.1.Jeep Liberty Limited
Rear-wheel drive, with Part-Time 4WD, 3.7L V6, 5600 lbs
2.2.1.2.Hummer H1
Full-time 4WD, V8, 7300 lbs
2.2.1.3.BMW Z4 3.0i Roadster
Rear-wheel drive, 3.0L inline-6, 3000 lbs
2.2.2Adding and Modifying Vehicles
2.2.2.1.Once the program begins, no vehicles can be added, removed, or modified.
2.2.2.2.Upon startup, the application searches a vehicles directory for vehicle files (HKVs) to populate into the simulation.
2.2.2.2.1.Initial vehicles are modified by editing the vehicle files directly using either a text editor or the Havok vehicle tool (user must own a personal copy of Havok to have access to this tool).
2.2.2.2.2.New vehicles are created by either copying or modifying an existing vehicle file and saving that file in the vehicles directory, or by using the Havok Vehicle tool (not supplied).
2.2.2.2.3.Vehicles are removed by deleting the vehicle file from the vehicles directory.
2.3Maps
This section defines the maps in the simulation. At the start of the simulation there will be N maps for the user to choose from (where N is a undetermined number defined at the design stage).
2.3.1Adding and Modifying Maps
2.3.1.1.At startup, the application searches a maps directory for map files to populate into the simulation.
2.3.1.1.1.Initial maps are modified by editing the map files using a personal copy of 3DMax Studio or another compatible application (not supplied).
2.3.1.1.2.New maps are created by either copying or modifying an existing map file and saving that file in the maps directory, by using 3DMax Studio(not supplied), or by using another compatible application.
2.3.1.1.3.Maps are removed by deleting the map file from the maps directory.
2.4Interfaces and User Interaction
This section describes the different ways in which a user interacts with the application.
2.4.1Before the Simulation
Once the application starts, the user is presented with a main screen that allows for the customization of the simulation in the following ways:
2.4.1.1.A map is selected using the previous and nextbuttons.
2.4.1.2.The map displayed on the screen is the map used in the simulation.
2.4.1.3.The user places several waypoints on the map, including one starting location and as many destinations as desired. Waypoints are placed by clicking a waypoint and then clicking the map.
2.4.1.3.1.The order in which the waypoints are selected is the order in which the vehicle will reach each destination.
2.4.1.3.2.Waypoints can define multiple destination locations. Waypoints instruct a vehicle to proceed to each individual “destination” along its path of travel.
2.4.1.3.3.The simulation notifies the user that it cannot start if there are not exactly one start location and at least one destination.
Figure 5,6: Shows two error situations where a start or destination have not been specified.
2.4.1.4.The user selects from one of three vehicles using the previous and nextbuttons. Vehicles are added, removed, or modified using the methods described in Adding and Modifying Vehicles.
2.4.1.5.The vehicle shown on the screen is the vehicle used in the simulation.
2.4.1.6.All options are reset to application defaults using the Reset All button.
2.4.1.7.The user chooses whether to use the GPS in the simulation or not. Turning off the GPS does not affect obstacle avoidance;if it is not selected the vehicle does not know the exact location of the destination waypoints and finds them blindly.
2.4.1.8.The user starts the simulation clicking on the Simulate! button.
Figure 7: Shows the main screen with a start point and two endpoints defined on the default map.
2.4.2During the Simulation
Once the simulation starts, the user does not interact with the vehicle. However, the user does have several options to interact with the simulation:
2.4.2.1.Pressing the V key on the keyboard during the simulation cycles through the camera views in the following order:
2.4.2.1.1.The default view of “chase” where the camera is slightly above and behind the vehicle. This changes to slightly above and in front when the vehicle is in reverse.
Figure 8: Shows a version of the chase camera mode where the camera is above and behind the vehicle.
2.4.2.1.2.Front view while traveling forward.
Figure 9: Shows a version of the front view where the camera is in front of the vehicle.
2.4.2.1.3.Overhead view.
Figure 10: Shows a version of the overhead view of the vehicle.
2.4.2.2.Pressing the Lkey on the keyboard during the simulation outputs a time stamped log file. Details concerning the contents of this file are in Log File.
2.4.2.3.The simulation generates a new time-stamped log file for each press of the L key during the simulation.
2.4.2.4.Pressing the ESC key on the keyboard pauses the simulation and prompts the user to end the simulation.
2.4.3After the Simulation
When the simulation is completed, the user is presented with an appropriate finish window (depending on the outcome) that allows several options:
2.4.3.1.An option to restart the simulator by returning to the main screen.
2.4.3.2.An option to exit.
2.4.3.3.An option to export world data or HKE (Havok Environment) to a log file containing attributes defined below.
2.5Log File
The vehicle’s knowledge of the world and simulation is written to a log-file during the simulation by pressing the L key on the keyboard. This data includes:
2.5.1Current Information
2.5.1.1.The vehicle’s current direction (in degrees from 0-360, with zero designating north).
2.5.1.2.The vehicle’s current position in X, Y coordinates.
2.5.1.3.The vehicle’s current velocity in Km/h.
2.5.1.4.The vehicle’s current view of the world as a set of data structures that return distances and threat levels gathered from all sensors.
2.5.1.5.The simulation running time.
2.5.2Historical Information
2.5.2.1.Includes everything that is in the “Current Information” section as well as sums and averages (historical data) for all values.
2.5.2.2.Actions taken throughout the simulation in the format of “this is the action taken, these were the circumstances”.
2.5.2.2.1.An action is any autonomous decision that causes the vehicle to deviate from a straight course.
2.5.2.3.The number of times each action was taken summarized by action type including: speed up, slow down, turn left, turn right, and stop.
2.6Major Components
There are five major components of the simulation. These components are GPS, LADAR, range-finding, path-finding, and situation management. Individual requirements of these pieces are below.
2.6.1GPS
GPS is the simplest of all the components used in the simulation.
2.6.1.1.GPS is used at the start of the simulation to determine the initial direction of travel
2.6.1.2.GPS is used throughout the simulation to determine the current location.
2.6.1.3.GPS allows the vehicle to know where it is on a map so that it can make path-finding decisions appropriately.
2.6.1.4.The GPS system tells the vehicle:
2.6.1.4.1.Its current location, in the format of an X, Y coordinate.
2.6.1.4.2.Its next location, determined by the current direction, in the format of an X, Y coordinate.
2.6.2LADAR
The vehicle features four LADAR sensors pointing in four different directions. These LADAR sensors are mounted on top of the vehicle in order to eliminate blind spots. The LADAR sensors perform the following functions:
2.6.2.1.Allow the vehicle to “see” larger objects from a distance of up to 1000 meters away.
2.6.2.2.View the “big picture” of the surrounding world by maintaining an awareness of what objects lie on all sides of the vehicle at any given time.
2.6.2.3.Take samples 60 times per second, equivalent to the speed of the simulation.
Figure 11: Shows the positioning of the LADAR and Range Finders on the Z4, one of the three initial vehicles.
2.6.3Range-Finding
The vehicle features 24 range-finding sensors arranged in a way that provide maximum coverage for the range-finding capability around the car. The range finders perform the following functions:
2.6.3.1.Reinforce the LADAR sensors to “see” upcoming objects and determine their distance.
2.6.3.2.Inform the vehicles of upcoming obstacles that the LADAR could have potentially missed, including planar inclines and dramatic terrain changes (i.e. rocks measuring two feet or greater in height).
2.6.3.3.Take samples 60 times per second, equivalent to the speed of the simulation.
Figure 12: Shows the positioning of the range finders on the H2, one of the three initial vehicles.
2.6.3.4.The range finders on all of the vehicles are found in similar locations; however, the angles will vary based on the vehicle’s body design. The angles in the initial vehicles will be determined during the design phase of this project. These locations of the Range Finders are as follows:
2.6.3.4.1.Front/Back Sensors Top Row
2.6.3.4.1.1.Driver - Angled upward to determine top clearance
2.6.3.4.1.2.Middle - Angled upward to determine top clearance
2.6.3.4.1.3. Passenger - Angled upward to determine top clearance
2.6.3.4.2.Front/Back Sensors Middle Row
2.6.3.4.2.1.Driver - Angled outward to determine side clearance
2.6.3.4.2.2.Middle - Determines clearance at bumper level
2.6.3.4.2.3.Passenger - Angled outward to determine side clearance
2.6.3.4.3.Front/Back Sensors Bottom Row
2.6.3.4.3.1.Driver - Angled downward to determine wheel obstacles/pits
2.6.3.4.3.2.Middle - Angled downward to determine wheel obstacles/pits
2.6.3.4.3.3.Passenger - Angled downward to determine wheel obstacles/pits
2.6.3.4.4.Front Wheel Sensors
2.6.3.4.4.1.Determines if anything is behind the front wheels
2.6.3.4.5.Back Wheel Sensors
2.6.3.4.5.1.Determines if anything is in front of the back wheels
2.6.3.4.6.Side Mounted Sensors
2.6.3.4.6.1.Measures Distance from the side of the vehicle to anything incoming on the side, as well as wall contours.
2.6.4Path-Finding
The path-finding portion of the simulation performs the following:
2.6.4.1.At the start of the simulation, the vehicle determines an appropriate initial path given only its location, the coordinates of the destination (obtained from the GPS), and any output from the LADAR and range-finding components.
2.6.4.2.Throughout the simulation, determines if the path the vehicle is currently traveling on is valid (free of obstacles) and is in a direction leading to the destination.
2.6.4.3.Works with the situation management component to ensure that actions taken, place the vehicle in a location that is in closer proximity to the destination that other potential actions. This ensures that the actions taken avoid obstacles and get the vehicle to its destination safely.
2.6.5Situation Management
The situation management component of the application performs the following:
2.6.5.1.Use the input of the LADAR and range finders to determine the size and number of obstacles. Not all obstacles require an action, only those that are directly in the vehicles path of travel. In some cases, the action may be as simple as slowing down or stopping.
2.6.5.2.In cases where an action is required, work with the path-finding component to determine what action should be taken if more than one action is available. In general, the vehicle takes the action that puts it in the best position to reach its destination.
3Non-functional Requirements
3.1Product
3.1.1.The car drives and avoids obstacles at about 80% of the speed a cautious human driver would travel with similar conditions; it is clear that the car is not relying on speed to avoid mishaps while driving, and is processing immediate paths quickly enough to avoid obstacles.
3.1.2.VISHUN is designed to be the primary application running on the computer system, multi-tasking is not recommended.
3.2System Requirements
3.2.1.Windows XP/2000 is required to run VISHUN.
3.2.2.Advanced users perform installation only.
3.2.3.Direct X 8 is required for the simulator to run.
3.2.4.Keyboard and mouse are required.
3.2.5.Hardware requirements
3.2.5.1.Hard Disk space : 1.2 gigabytes free
3.2.5.2.Memory: 512megabytes of Physical Memory
3.2.5.3.Video: Accelerated 64 megabytes Video Memory