Team Autono-Mo. Jacobia. Department of Computer Science and Engineering The University of Texas at Arlington

Transcription

1 Department of Computer Science and Engineering The University of Texas at Arlington Team Autono-Mo Jacobia Architecture Design Specification Team Members: Bill Butts Darius Salemizadeh Lance Storey Yunesh Shakya Late Updated: 20 June 9:08:00 PM Team AUTONO-MO 1

2 Table of Contents 1.1 General Introduction Meta Architecture Guiding Principles Guiding Assumptions Layer Definition Section Sensory Layer Navigation Layer Movement Layer Application Layer Requirements Mapping Inter-Subsystem Data flows Section Subsystem Descriptions Section Sensory Layer Navigation Layer Application Layer Movement Layer Testing Considerations General Testing Approach Appendix Acronyms Definitions Team AUTONO-MO 2

3 List of Figures Figure High-Level Diagram of the System Architecture... 5 Figure Inter-Subsystem Data Flows... 8 Figure GPS Locator Subsystem Figure Visual Sensing Subsystem Figure Heading Detection Subsystem Figure Signal Conditioning Subsystem Figure Path Processing Subsystem Figure Obstacle Avoidance Subsystem Figure Navigation Communication Subsystem Figure Localization Subsystem Figure GUI Subsystem Figure App Processing Subsystem Figure Application Communication Subsystem Figure Database Subsystem Figure PPM Signal Generator Subsystem Figure Encoder Processing Subsystem List of Tables Table Requirements Mapping Table... 7 Table Inter-Subsystem Data Element Description... 9 Table 1.3 Producer-Consumer Interactions Table Table Producer-Consumer Interactions Table Table Producer-Consumer Interactions Table Team AUTONO-MO 3

4 1.1 General This Architectural Design Specification will serve as the basis for the implementation decisions for Project Jacobia. It will serve as an abstraction of the physical make-up of the product. This abstraction will consist of layers, which will be decomposed into subsystems. Each layer, and subsequently each subsystem, will have a list of responsibilities and functions that it must undertake. This document will employ the use of diagrams, flow diagrams, tables, and other methods in order to clearly define those responsibilities and functions in order to create a coherent design to the system. 1.2 Introduction The purpose of the Architecture Design Specification is to provide a high-level implementation approach to the Jacobia project described in Team Autono-Mo s System Requirements Specification as well as in Team Autono-Mo s Project Charter. The ADS will serve as an abstract definition of the solution that Team Autono-Mo will employ in order to create a working product. The methodology for the ADS includes the formulation of layers and subsystems that, in conjunction with one another, will compose a system built on the theory of modularity. The product concept encompasses replacing the RC unit on an RC vehicle with the Jacobia module. The Jacobia module will provide autonomous capabilities to the vehicle which will allow the vehicle to travel from one GPS coordinate to another while avoiding local obstacles. The vehicle will be able to receive GPS destination coordinates from a user through a GUI via a host application that will communicate with the control module wirelessly. The control module will be equipped with sensors to allow Jacobia to determine its current GPS location as well as the locations of obstacles along its path. The scope of the project includes the System Requirements Specification which outlines the requirements and the importance level of each requirement, the Architecture Design Specification (this document) which will describe the high level layer architecture for the system, and the Detailed Design Specification which will outline the subsystems and interactions within the architecture s layers. After a detailed design is completed, Team Autono-Mo will then implement the product using this design. 1.3 Meta Architecture The design outlined in this document was made with extensibility, modularity, and the theory of separation of concerns in mind. Additionally, the system is designed in such a way as to easily facilitate the implementation of additional system requirements in the future. These guiding principles are apparent throughout the document Guiding Principles The architecture of the system shall allow for staged delivery Team AUTONO-MO 4

5 The architecture of the system shall allow for layers and subsystems with clear, welldefined logical roles The architecture shall be designed in an extensible way as to easily facilitate the implementation of additional future requirements The architecture shall be designed in a way as to facilitate modularity in order to ease maintenance and testing Guiding Assumptions The quality of hardware obtained will limit the precision of the overall system Jacobia will not be used to navigate through unfavorable terrain, or up/down stairs or ramps The RC vehicle that Jacobia is mounted on is of 1/12 th scale The GUI for Jacobia will be designed for Microsoft Windows 7 only 1.4 Layer Definition Section Figure High-Level Diagram of the System Architecture Team AUTONO-MO 5

6 1.4.1 Sensory Layer This layer is responsible for acquiring external sensory data.that external sensory data includes visual sensor data, heading data, and GPS data. Once this layer has acquired the aforementioned data, it is then responsible for transmitting this data to the Navigation Layer Navigation Layer This layer is responsible for determining the navigation of the RC vehicle that the system is housed on. This layer receives sensory information from the Sensory Layer and uses it to determine the make-up of its immediate surroundings, positioning, and a path towards its final destination. After determining those things, this layer then controls the movement of the RC vehicle by creating PPM signals. This layer then sends information about the RC vehicle s journey to the Application Layer Movement Layer This layer is responsible for directing the movement of the RC vehicle. It receives instructions from the Navigation Layer and then translates those instructions into PPM signals which, in turn, move the car according to the Navigation Layer s instructions Application Layer This layer is responsible for facilitating interactions with the user. Specifically, this layer is responsible for displaying all necessary information to the user. It also prompts the user for the needed input and passes this input to the Navigation Layer. This layer also houses the configuration files that the Navigation Layer needs in order to configure the system to the specific RC vehicle that the user chooses to use the product on. Team AUTONO-MO 6

7 1.5 Requirements Mapping Requirements Sensory Layer Navigation Layer Movement Layer Application Layer Replacement of RC Vehicle Receiver Interface with standard RC car PPM Signals System Scale System Power Obstacle Avoidance Input GPS Destination RC Vehicle Trajectory RC Vehicle Trajectory Corrections Object Detection Sensors Path-finding Algorithm System Navigation Wireless Communication Location Information Transmission Local Object Information transmission Live Video Feed Transmission Location Information Reporting and Display Configuration File Table Requirements Mapping Table Team AUTONO-MO 7

8 1.6 Inter-Subsystem Data flows Section This section shall insert another level of abstraction into the architectural design. It will highlight the existence of the subsystems that are contained within all the layers of the architectural system. These subsystems will then be defined in regards to the data that they produce and process in order to facilitate the operation of the system. Each data element passed in between subsystems will be enumerated and expanded upon in greater detail. 28 Figure Inter-Subsystem Data Flows Team AUTONO-MO 8

9 Data Element Descriptions 1. GPS Feedback Feedback from the GPS location system. 2. Distance Feedback Feedback from obstacle location detection. 3. Heading Feedback Feedback from heading sensor. 4. GPS Sensor Signal The unconditioned signal from the GPS sensor. 5. Distance Sensor Signal The unconditioned signal from the obstacle distance sensor. 6. Heading Sensor Signal The unconditioned signal from the heading sensor. 7. Conditioned Location Information The GPS location information conditioned for the location subsystem. 8. Conditioned Heading Information The heading information conditioned for the navigation system. 9. Conditioned Visual Information The obstacle information conditioned for the obstacle avoidance subsystem. 10. Calculated Location Information The calculated location for the system. 11. Calculated Obstacle Information The calculated instance of obstacles. 12. Vehicle Status Information The calculated instance of information about the vehicle. 13. GPS Destination Input Input from the user about the current GPS destination. 14. Current Calculated Trajectory Information The calculated trajectory that the vehicle should currently follow. 15. Processed Encoder Information The processed encoder information from the vehicle s servos. 16. Servo Encoder Reading Encoder readings from the servos. 17. Created PPM Signal The PPM signal sent to the correct servo. 18. Vehicle Status Information The calculated instance information about the vehicle. 19. GPS Destination Input GPS input from the user. 20. GPS Destination Input GPS input from the user. 21. Vehicle Status Information The calculated instance information about the vehicle. 22. Vehicle Status Information The calculated instance information about the vehicle. 23. User Input Forwarded input from the user. 24. User Input Input from the user. 25. Vehicle Status Information The calculated instance information about the vehicle. 26. User Input About Configuration File Information about vehicle type from the user. 27. Information About Configuration File Information about vehicle type that the user chose. 28. Emergency Stop Signal Input from the user. Table Inter-Subsystem Data Element Description Team AUTONO-MO 9

10 The producer/consumer relationships can be seen in the following three tables. This outlines the way that the data flows through the system. Each subsystem consumes, produces or does both. It is important to understand the production and consumption of the data flows. Table 1.3 defines the first six data flows. As you can see each sensor subsystem produces and consumes data for each specific purpose. Data flow number 1 is the GPS signal coming in from the GPS system outside of our project, and is interpreted by the GPS Locator subsystem. Visual Sensing is reading feedback from its created signal, whether ultrasound or infrared, to determine obstacle location. Heading Detection is interpreting its own data to determine vehicle heading. The Signal Conditioner is then consuming the signals produced from each sensor subsystem. Consumer Subsystem Producer Subsystem GPS Locator Visual Sensing Heading Detection Signal Conditioner GPS Locator 1 4 Visual Sensing 2 5 Heading Detection 3 6 Signal Conditioner Table 1.3 Producer-Consumer Interactions Table 1 Table 1.4 defines data flows The Signal Conditioner subsystem produces data for the Localization, Path Processing and Obstacle Avoidance subsystems. Localization and Obstacle Avoidance produce data for the Path Processing, then Path Processing produces data for Navigation Communication and PPM Generator. Navigation Communication produces data for Path Processing and App Communication. Encoder Processing produces data involving encoder counts for Localization. Encoder Processing receives encoder counts from the servos on the vehicle. PPM Signal Generator produces a PPM signal for the servos. Consumer Subsystem Producer Subsystem Localization Path Processing Obstacle Avoidance Navigation Communication Encoder Processing PPM Signal Generator Servo App Communication Signal Conditioner Localization 10 Path Processing Obstacle Avoidance 11 Navigation Communication Encoder Processing Servo 16 PPM Signal Generator 17 Team AUTONO-MO 10

11 Table Producer-Consumer Interactions Table 2 Table 1.5 defines the data flows App Communication produces data for Navigation Communication and App Processing. App Processing produces data for App Communication, GUI and the Database. The GUI produces data for App Processing and the User. The database produces data for the App Processing. Consumer Subsystem Producer Subsystem Navigation Communication App Communication App Processing GUI Database User App Communication App Processing GUI Database 27 User 24 Table Producer-Consumer Interactions Table Subsystem Descriptions Section This section shall serve as an expansion upon the definitions given to the subsystems in the previous section. This section shall strive to further the definition of each subsystem by explaining the operational logic and functions of each subsystem Sensory Layer GPS Locator Subsystem This subsystem must acquire GPS readings from a GPS instrument. Team AUTONO-MO 11

12 Figure GPS Locator Subsystem Assumptions This subsystem assumes that there is some kind of GPS location capturing device that will feed it GPS signals Responsibilities 1. This subsystem is responsible for acquiring GPS readings from an external source, most likely a GPS signaling device. 2. This subsystem is responsible for sending the acquired GPS readings to the Signal Conditioning subsystem Subsystem Inter-layer Interfaces: None Subsystem Public Interfaces: Method Description Information Required Information Returned requestdata Receives GPS reading from GPS source. senddata Sends GPS data to a recipient Unconditioned GPS data Unconditioned GPS reading Team AUTONO-MO 12

13 Visual Sensing: This subsystem must acquire visual sensory data from an external sensor Assumptions: Figure Visual Sensing Subsystem This subsystem assumes that there is some kind of external sensor present that will feed it sensory information Responsibility: 1. This subsystem is responsible for acquiring visual sensory data from an external source, most likely ultrasonic sensors. 2. This subsystem is responsible for sending acquired visual sensory readings to the Signal Conditioning subsystem Subsystem Inter-Layer Interfaces: None Subsystem Public Interfaces: Method Description Information Required Information Returned requestdata Receives GPS reading from GPS source. senddata Sends GPS data to a recipient Unconditioned sensory data Unconditioned sensory data Team AUTONO-MO 13

14 Heading Detection: This subsystem must acquire heading data regarding the direction of the RC vehicle using some kind of hardware device that can calculate headings Assumptions: Figure Heading Detection Subsystem This subsystem assumes that there is some kind of external device present that will feed it heading information Responsibilities: 1. This subsystem is responsible for acquiring heading reading from an external source, most likely a tilt-compensating compass. 2. This subsystem is responsible for forwarding acquired heading readings to the Signal Conditioning subsystem Subsystem Inter-Layer Interfaces: None Subsystem Public Interfaces: Method Description Information Required Information Returned requestdata Receives heading data from a device senddata Sends heading data to a recipient Unconditioned heading data Unconditioned heading data Team AUTONO-MO 14

15 Signal Conditioning: This subsystem must condition signals acquired from other subsystems in the Sensory Layer in order for them to be usable by the Navigation Layer Assumptions: Figure Signal Conditioning Subsystem This subsystem assumes that the Heading Detection subsystem, Visual Sensing subsystem, and the GPS Locator subsystem send it data in an unconditioned, raw format Responsibilities: 1. This subsystem is responsible for converting analog signals to digital signals. 2. This subsystem is responsible for delivering the converted digital signals to their appropriate recipients Subsystem Inter-Layer Interfaces: Team AUTONO-MO 15

16 Method Description Information Required receivesensor Request Sensor Data Information Returned Unconditioned sensor data receiveheading Request Heading data Unconditioned heading data receivegps Request GPS data Unconditioned GPS data sendsensor send Sensor data Conditioned sensor data sendheading send Heading Conditioned data sensor data sendgps send GPS data Conditioned sensor data Subsystem Public Interfaces: None Navigation Layer Path Processing: This subsystem must determine the navigation of the RC vehicle using data it receives from the Obstacle Avoidance, Localization, and Signal Conditioning subsystem. Team AUTONO-MO 16

17 Figure Path Processing Subsystem Assumptions: 1. This subsystem assumes that it will receive conditioned data from the Sensory Layer s Signal Conditioner subsystem. 2. This subsystem assumes that it will receive accurate information from the Localization subsystem. 3. This subsystem assumes that it will receive accurate information from the Obstacle Avoidance subsystem Responsibilities: 1. This subsystem is responsible for processing digital information regarding visual sensory information detailing the system s surroundings from the Sensory Layer s Signal Conditioner subsystem in order to determine navigation. 2. This subsystem is responsible for processing digital information regarding obstacle information in the RC vehicle s path in order to determine navigation. 3. This subsystem is responsible for processing digital information regarding the RC vehicle s location in order to determine navigation Subsystem Inter-Layer Interfaces: Team AUTONO-MO 17

18 Method Description Information Required Information Returned receiveheading Receive digital condition data receiveobstacleinfo Receive information about obstacles receivecommand Receive Command receivelocation Receive location information sendjourneyinfo Send trip related information receiveinitialization Receive initialization info Conditioned heading data Obstacle data Command Name Location data Information code Initialization Configs Success Code Success Code Success Code Success Code Success Code Subsystem Public Interfaces: None Obstacle Avoidance: This subsystem must determine the threat of nearby obstacles using sensory readings that it will receive from the Signal Conditioner. Team AUTONO-MO 18

19 Assumptions: Figure Obstacle Avoidance Subsystem This subsystem assumes that it will receive conditioned data from the Sensory Layer s Signal Conditioning subsystem Responsibilities: 1. This subsystem is responsible for receiving conditioned data detailing the surroundings of the RC vehicle. 2. This subsystem is responsible for determining if there are nearby objects which pose a threat as a potential roadblock or obstacle in the RC vehicle s path using the conditioned data detailing the surroundings of the vehicle Subsystem Inter-Layer Interfaces: Team AUTONO-MO 19

20 Method Description Information Required Information Returned receivereading Receive digital environmental data Some kind of digital sensory reading Success Code sendreading Send digital threat description Processing of digital sensory readings Subsystem Public Interfaces: None Navigation Communication: This subsystem must facilitate communication between the Navigation Layer and the Application Layer through a wireless medium. Figure Navigation Communication Subsystem Assumptions: 1. This subsystem assumes that there is some wireless networking technology available to facilitate the communication between this layer and the Application Layer s App Communication subsystem. Team AUTONO-MO 20

21 2. This subsystem assumes that there is an operating system available to the Application Layer that can host the drivers needed for the networking technology Responsibilities: 1. This subsystem is responsible for sending journey information to the application layer 2. This subsystem is responsible for receiving instructions from the application layer s App Communication subsystem Subsystem Inter-Layer Interfaces: Method Description Information Required Information Returned Initialize Send config file info receivejourneyinfo Receive trip information sendjourneyinfo Send trip related information receiveconfig Receive config file info ReceiveCommand Receive command Configuration data Trip information code Information code Configuration data Command Success code Success code Success code Subsystem Public Interfaces: None Localization: This subsystem must determine the system s location using a weighted algorithm that will take into account GPS readings received from the Signal Conditioning subsystem as well as servo encoder counts that it will receive from the Direction Layer s Encoder Processing subsystem. These servo encoder counts will be used to employ the use of dead reckoning algorithms. Team AUTONO-MO 21

22 28 Figure Localization Subsystem Assumptions: 1. This subsystem assumes that it will receive information about servo rotation from the Movement Layer s Encoder Processing subsystem. 2. This subsystem assumes that it will receive information about GPS location from the Sensory Layer s GPS Locator subsystem Responsibilities: 1. This subsystem is responsible for determining the location of the RC vehicle at any given time using a combination of Dead Reckoning and GPS data. 2. This subsystem is responsible for relaying the vehicle location to the Path Processing subsystem. Team AUTONO-MO 22

23 Subsystem Inter-Layer Interfaces: Method Description Information Required Information Returned receivegps Receive digital GPS data receiveencoding Receive digital servo data sendlocation Send location data GPS data Servo rotation information Location data Success Code Success Code Subsystem Public Interfaces: None Application Layer GUI: This subsystem must facilitate interactions with the user through a series of different screens and prompting the user for input. Figure GUI Subsystem Assumptions: 1. This subsystem assumes that the user speaks English. 2. This subsystem assumes that there is an operating system present on the computer that the host application is installed on in order to facilitate input and output of data Responsibilities: Team AUTONO-MO 23

24 1. This subsystem is responsible for intercepting commands from the user. 2. This subsystem is responsible for sending information to the user Subsystem Inter-Layer Interfaces: None Subsystem Public Interfaces: Method Description Information Required Information Returned captureinput Capture Screen input sendcommand Send User s command displayjourneyinfo Displays the cars actions User Input Command Journey information string Success code Application Processing: This subsystem must process information acquired from GUI and from that information make appropriate decisions ranging from querying the database, changing screens on the GUI, or sending information to the Application Communication subsystem in order for it to be sent to the Navigation Layer Assumptions: Responsibilities: Figure App Processing Subsystem Team AUTONO-MO 24

25 1. This subsystem is responsible for sending commands to the Navigation Layer s Navigation Communication subsystem based on input from the user. 2. This subsystem is responsible for extracting configuration files from the Database subsystem. 3. This subsystem is responsible for sending configuration files to the Navigation Layer s Navigation Communication subsystem based on input from the user Subsystem Inter-Layer Interfaces: None Subsystem Public Interfaces: None Application Communication: This subsystem must facilitate communication between Navigation and Application layer through the use of a wireless medium. Figure Application Communication Subsystem Assumptions: 1. This subsystem assumes that there is some wireless networking technology present. 2. This subsystem assumes that there is an operating system present that will have the drivers needed to work with the wireless networking technology Responsibilities: Team AUTONO-MO 25

26 1. This subsystem is responsible for sending configuration files to the Navigation Layer s Navigation Communication subsystem 2. This subsystem is responsible for sending commands to the Navigation Layer s Navigation Communication such as Stop and Go commands Subsystem Inter-Layer Interfaces: Method Description Information Required Information Returned sendcommand Issue a command Command receivejourneyinfo Receive a trip information code sendintializeinfo Send initialization info Initialization info Success Code Subsystem Public Interfaces: None Database: This subsystem must store the necessary configuration files needed for the system s operation Assumptions: Figure Database Subsystem This subsystem assumes that the data being inserted into it is valid Responsibilities: 1. This subsystem is responsible for housing configuration files. Team AUTONO-MO 26

27 2. This subsystem is responsible for facilitating the extraction of configuration files Subsystem Inter-Layer Interfaces: None Subsystem Public Interfaces: None Movement Layer PPM Signal Generator: This subsystem must generate PPM signals Assumptions: Figure PPM Signal Generator Subsystem This subsystem assumes that the Navigation Layer s Path Processing will give concise descriptions on the type of PPM signals to generate Responsibilities: 1. This subsystem is responsible for generating PPM signals which will direct the vehicle that the product is being used on. 2. This subsystem is responsible for receiving instructions from the Navigation Layer s Path Processing subsystem. Team AUTONO-MO 27

28 Subsystem Inter-Layer Interfaces: Method Description Information Required Information Returned receiveinstruction Receive PPM signal instruction Instruction Success Code Subsystem Public Interfaces: Method Description Information Required Information Returned generatesignal Generate a PPM signal instruction Encoder Processing: This subsystem must record servo rotation information from devices that are native to the existing architecture of the RC vehicle. 28 Figure Encoder Processing Subsystem Assumptions: 1. This subsystem assumes that the servos will send data to it. 2. This subsystem assumes that the device needed to record encoder counts is native to the architecture of the RC vehicle. Team AUTONO-MO 28

29 Responsibilities: 1. This subsystem is responsible for capturing information from the RC vehicle s servos about rotation movement. 2. This subsystem is responsible for conditioning and relaying this information to the Navigation Layer s Localization Subsystem Subsystem Inter-Layer Interfaces: Method Description Information Required Information Returned senddata Sends conditioned servo rotation data Encoder data Subsystem Public Interfaces: Method Description Information Required Information Returned receivedata Receive data from servos Servo Data Subsystem Public Interfaces: Each of the functions or methods exposed to the external world by the subsystem should be briefly identified, in a manner similar to Error! Reference source not found., above. 1.8 Testing Considerations General Testing considerations will provide a guide for determining if the architectural design specified herein adheres to the Four I s: independence, integrity, interfaces/interactions, and implementation. The testing considerations will also provide a metric for determining if the layers, subsystems, and components of the system meet the requirements as defined in the Customer Requirements section of the System Requirements Specification Testing Approach The testing approach will include component testing, subsystem testing, layer testing, and system testing. In addition, ensuring correct data flows between layers, ensuring the system meets project requirements, verifying correct communication paths between components, and the validation of inputs and outputs will also be tested during the system and subsystem testing phases Component Testing Each component required of a subsystem will be tested individually before it is integrated with other components of the subsystem. These components will be tested for completeness and Team AUTONO-MO 29

30 quality, as well as whether or not accomplishes the task required. Once the component has passed component testing, it will then be eligible to be integrated with other components of the layer and will then undergo subsystem testing Subsystem Testing Once each component has been verified through component testing, the components will then be integrated to create a subsystem by whatever means necessary as specified herein and, later, as specified in the Detailed Design Specifications document. Once components are integrated together, the subsystem will be tested for completeness and correctness of the task that is required of it. Once the subsystem is tested for completeness, it will then undergo integration testing with the rest of the subsystems that are present in its respective layer. After which, this subsystem will then be eligible for insertion into a layer of the system Layer Testing Sensory Layer Testing The Sensory Layer of Jacobia includes four subsystems: GPS Location Acquisition, Visual Sensing, Heading Detection, and Signal Conditioning. These four subsystems will each first be tested through subsystem testing, and will then be integrated to create the Sensory Layer. The Sensory Layer of Jacobia is the layer which handles all environmental inputs and allows the module to account for things outside of the vehicle that could hinder the operation of the car. This is done through the four subsystems of this layer and will allow the module to correctly determine the navigation required of the RC vehicle. The Sensory Layer receives inputs from the outside world through the various sensors contained within the module, and sends outputs of conditioned sensory signals to the Navigation Layer. Once it has been determined that the sensors contained within this layer are able to accurately and correctly send data to the Navigation Layer, it will pass the sensory layer testing and will be eligible to be integrated with other layers, and the system will then be tested as a whole Navigation Layer Testing The Navigation Layer of Jacobia includes four subsystems: Path Processing, Obstacle Avoidance, Navigation Communication, and Localization. These four subsystems will each first be tested through subsystem testing and will then be integrated to create the Navigation Layer. The Navigation Layer of Jacobia is the layer which handles all decisions about how the module will direct the RC vehicle based on the environmental data present at the time, as well as avoiding obstacles and keeping track of where the RC vehicle is in respect to the world. In addition, this layer will allow the module to correctly determine what signals to send to the servos of the RC vehicle motors as well as providing the user with RC vehicle positioning and travel information. All of the aforementioned tasks are accomplished through the use of the 4 subsystems of this layer. The Navigation Layer receives navigation-altering inputs from the sensory layer, the Application Layer, and the Movement Layer to determine the output of the Navigation Layer. The output of the Navigation Layer is the navigation commands that will be sent to the Movement Layer and the RC vehicle positioning and travel information that is sent to the Application Layer. Once it has been determined that the Navigation Layer is capable of facilitating all of these inputs and outputs in a correct manner through the use of our test plan, it will then be integrated into the system. At that time, the system will then be tested as a whole in order to validate behavior. Team AUTONO-MO 30

31 Application Layer Testing The Application Layer of Jacobia includes four subsystems: GUI, Application Processing, Application Communication, and Database. These four subsystems will each first be tested through subsystem testing, and will then be integrated to create the Application Layer. The Application Layer of Jacobia is the layer which shows the user RC vehicle positioning and travel information. This layer is also responsible for allowing the user to interact with the module, allowing the module to correctly receive and send RC vehicle information, accept commands, and store information. The Application Layer receives inputs from the Navigation Layer as well as from the user in the form of travel information and RC Vehicle commands. The output of the Application Layer is commands that are sent to the Navigation Layer from the users input. Once it has been determined that the Application Layer can correctly and accurately facilitate these inputs and outputs through the use of our test plan, it will then be integrated into the system. At that time, the system will then be tested as a whole Movement Layer Testing The Movement Layer of Jacobia includes two subsystems: PPM Signal Generator and Encoder Processing. These two subsystems will each first be tested through subsystem testing, and will then be integrated to create the Movement Layer. The Movement Layer of Jacobia is the layer which communicates navigation commands to the RC vehicle through the use of PPM signals sent to its servos, as well as interpreting encoder data from the wheels. This is done through the two subsystems of this layer, and will allow the RC vehicle to correctly send PPM signals to the servos and send back accurate encoder information. The Movement Layer receives inputs from the Navigation Layer in the form of PPM signal instructions as well as external encoder data from the encoders of the wheels. The outputs of the Movement Layer include PPM signals that are sent to the servos of the motors as well as encoder data that is sent back to the Navigation Layer. Once it has been determined that the Movement Layer is capable of fulfilling all of these needs, it will pass the Movement Layer testing and will be eligible to be integrated with other layers and the system will then be tested as a whole System Testing Once each layer has been tested, they will be combined into a single system, which is the final, complete project. This system will then be tested to ensure that it is correct, complete, and meets all of the requirements as specified in the System Requirements Specifications document. The system will be tested with all of the requirements in mind, but the system will only be considered acceptable once the acceptance criteria, as dictated in the SRS, has been satisfied. After this point, the system will be considered complete and any non-completed requirements will be addressed, as well as future requirements. The system will undergo the entire testing process once again if additional features are added. 1.9 Appendix Acronyms ADS Architectural Design Specification DDS Detailed Design Specification Team AUTONO-MO 31

32 SRS System Requirements Specification RC Remote Control GPS Global Positioning System GUI Graphical User Interface Definitions PPM Signals Pulse Position Modulation Autonomous - Acting independently or having the freedom to do so Encoder - An electro-mechanical device that converts the angular position or motion of a shaft or axle to an analog or digital code Signal Conditioning Converting signals from Analog to Digital and filtering out any unwanted noise Path processing Calculating the path that the RC vehicle must take based on all sensory information Path planning Planning out the path that the RC vehicle must take in order to make it to the goal Servo - A small, cheap, mass-produced actuator used for radio control and small robotics Dead Reckoning The process of calculating one's current position by using a previously determined position, or fix, and advancing that position based upon known or estimated speeds over elapsed time, and course Team AUTONO-MO 32