Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- ========================================================================
- 2E3 CONSOLE APPLICATION : Road condition data sourcing
- ========================================================================
- Compile information:
- Program was compiled in Windows 10 using the VS2015 toolset (v140).
- Compatibility was also checked using the VS2012 toolset (v110) to ensure functionality
- accross different versions.
- An executable compiled with the v110 toolset is also included in the event that the new
- toolset is not installed on the target computer
- General usage
- When running, you are requested to enter a time step and threshold value.
- After this, the data begins to be collected and printed to the screen.
- After the EOF has been reached, a new list of the values over the threshold
- are printed in descending order, as well as the average acceleration.
- At any time during the collection process (i.e. after the paramter requests)
- you can stop gathering data and print out the descending list and average
- by pressing the 's' key (as in stop), or you can quit by pressing the
- 'x' key (as in x-it)
- Raw data acquisition
- The data acquisition is simulated in the GPS and Sensor classes. Both have a
- instance of the FileReader class in order to obtain the actual data.
- When the sensor classes are created, they open a filestream to the supplied
- path of the data, which is kept open until the EOF is reached. When the
- getLocation() or readAcceleration() functions are called, they return the
- next set of data in the respective files (Rather than reading all data
- into a list at once at the start of the program).
- Every time data is requested from the FileReader class, it checks itself
- for an EOF condition, and if true, closes the filestream.
- The classes were made with the intention of being indiscernable to the
- wider program of not being an actual GPS coordinate. As such, in order
- to advance the program into using an actual GPS or accelerometer device,
- only these classes would have to be modified, leaving the main code intact.
- Timed data requests
- At the start of the program, the user is requested to enter a time step, after
- which data is retrieved and printed to the screen continously with the
- required pause between. This is done by spawning a data retrieval thread which
- runs concurrently with the main program thread and loops continously while data
- is to be retrieved. At the start of the loop, the "starting time" is recorded. Data
- is then acquired, added to a holding object, added to a list etc. At the end of the
- loop, the "ending time" is recorded, and the time spent during that iteration is
- calculated. The thread then sleeps for the required time (timestep - time doing)
- before repeating for the next set of data.
- Use of data
- The GPS data is stored as an instance of the Coordinate class which contains two
- floats as the latitude and longitude values. The acceleration data is stored as
- a Vector3 from the Vector class whcih contains 3 floats for (x, y, z), as well as
- some operator overloads. The Coordinate and Acceleration data at a particular point
- in time is stored as a collectiveData instance, which contains a Coordinate instance,
- a Vector3 instance and the time the data was acquired (relative to the start of the program)
- The collectiveData class also contains a pointer to an object of the same class as it is
- to be used in a linked list.
- Lists
- 2 singly linked lists are used in this program. One contains all data in the order
- it was acquired, while the other contains only the data over the requested threshold
- in descending order. Both contain individual copies of the collectiveData instances
- as there would be an issue with sharing "next" pointers should the same instances
- be used. The lists are instantiated with the CustomList class, which contains
- add() and add_in_place() functions to add in retrieved order and descending order.
- A binary search tree was considered for the ordered list, however I found that when
- attempting to print the tree I was created a linked list from the tree to simplify
- the process, so forgoing the tree altogether was the most efficient choice.
- Main program flow
- Timestep and threshold requested -> New data printed to screen when available -> Loops checking for key presses -> When gather is finished, print the average and descending lists -> Wait for user request to exit.
- -> Data gathering thread begins executing -> Lists are populated -> Thread ends at EOF or 's' key pressed
- -> Key listening thread begins executing -> When a key is pressed, give its value to global variable -> Thread ends with end of main thread
- Additional features
- -Console formatting
- Console formatting is supplied through the ConsoleControl class which was written
- for the tic tac toe lab of week 2. With this class, you can safely and easily:
- -Change the text and background colour
- -Clear the console window
- -Change the title of the console window
- -Change the size of the window
- -Get and set the cursor position to draw tables/text with precision
- -Threading
- The data gathering and key listening happens in seperate threads to reduce
- interference between the main functions as well as to allow concurrent
- listening, printing and data gathering
- -Key listening
- The key listening is handled in a thread seperate to the main thread.
- As such, the thread can sit waiting for user input while the main
- thread executes as normal, checking once per loop to see if a key
- has been pressed.
- -Adjustable timing
- Using the clock() and sleep() functions, the program runs only when required
- and sleeps for the rest, cutting out uneccesary computations and improving
- efficiency (slightly).
- For example, the main loop need not run more than 60 times per second, and
- is therefore capped at this loop frequency.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement