Software Design Document Team 18

SOFTWARE DESIGN DOCUMENT

Project:​ Metamorphobot
Task:​ Construct a robot that can decrease in size to fit through a tunnel, widen to go over a
bridge, identify coloured blocks while in a specified search area.

Document Version Number​: ​1.8

Date: ​12/04/18
Author: ​Kiren Rao, Sarah Swanson

Edit History:
Version Date Author Section Summary
Updated
1.0 27/02/18 Kiren Rao, Sarah All Preliminary Document
Swanson

1.1 14/03/18 Kiren Rao 2.0, 6.0 Updated initial stages of

design process, Version
History updates

1.2 15/03/18 Sarah Swanson 2.0, 4.0 Completed sentences and

ideas from given bullet
points. Explained Javadocs

1.3 18/03/18 Kiren Rao, Sarah 5.0, 6.0 Added class hierarchy
Swanson diagram, software flowchart,
updated edit history

1.4 20/03/18 Sarah Swanson 5.0 Description of classes and

code

1.5 28/03/18 Kiren Rao 5.0, 6.9 Added more info to structure
traversal class. Updated
software edit history.

1.6 04/04/18 Sarah Swanson All Reformatting

1.7 04/04/18 Kiren Rao 5.0 Added the descriptions for

the classes

1.8 12/04/18 Sarah Swanson 7.0 Final Demo Report

1
Software Design Document Team 18

1.0 Table of Contents

1.0 Table of Contents 2

2.0 Design Process 3

3.0 Software Flowchart 4

4.0 Javadocs 5

5.0 Class Hierarchy Diagram 5

5.1 Wifi Class 6

5.2 Bridge Traversal and Tunnel Traversal Class: Wheelbase Extension 6

5.3 Dpm Final Class 6

5.4 Ultrasonic Localizer 6

5.5 Odometer 7

5.6 Navigation 7

5.7 Search for Block 7

5.8 Light Localizer 7

6.0 Edit History of the Software Changes 8

7.0 Final Demonstration Report 8

8.0 Glossary of Terms 9

2
Software Design Document Team 18

2.0 Design Process

The first step to be implemented was to create a preliminary flowchart. Based on the
constraints and requirements of the project, the final flowchart was completed and used as a
basis to start our class hierarchy. The flowchart helped with visualization and the process
because it showed how the classes in the code should interact with each other. Our process will
be the most successful if we follow three main steps and procedure: What to think about
throughout the process, how to tackle the tasks on a weekly basis, and the way we are
specifically tackling the project.

There are many points to think about throughout the process. One point is to ensure that
the code is modularized thus ensuring that the code can be easily debugged as well as modified
efficiently. Another point to remember throughout the process is to ensure the style guide is
respected and the version control conventions are followed.

In order to successfully follow the Gantt chart, there are tasks that must be tackled on a
weekly basis. The first task is to outline the tasks required to meet the next milestone. The
second is to pick up and implement the task. Thirdly, after coming to a desirable level, pass on
to testing. Depending on if it meets criteria, a developer will reevaluate and fix the issue or move
onto the next task.

The way we are specifically tackling the project can be broken down in four preliminary
steps. The first step to deal with is the implementation of the ability to receive parameters over
WiFi. This is an integral part of the process when demoing and will ensure that the functions
deliver the expected results. The second step is to implement an adjustment to the wheelbase
for a comfortable traversal over a bridge or into a tunnel. This involves especially high level of
collaboration between software and hardware departments. A class must be created to
determine a way to ensure that the robot is facing right in front of the bridge and the tunnel. This
can be done by using a pair of color sensors on the front of the robot and determining the color
of the structure. We can then correct the position based on which sensor has encounter the
change in color first. The third step in the beginning part of the project is to make sure the
localization is consistently working. This is important because the localization is the basis of how
well the robot will be able to move from point to point on the map. The localization needs to be
consistently tested with the final version of hardware. This also encompasses the travelTo
function as this is primarily based on the capabilities of the odometer. After implementing the
wheelbase and perfecting the localization (to be able to travel over the bridge and through the
tunnel), the fourth step is to evaluate and determine changes that need to made to the search
algorithm. Once the search algorithm is completed, we will be able to successfully find the given
colour block.

3
Software Design Document Team 18

3.0 Software Flowchart

Figure 1: System Flowchart Authors: Kiren Rao, Sarah Swanson

4
Software Design Document Team 18

4.0 Javadocs

Javadocs are an important aspect for the organization of the software. It is a universal
tool used to generate the API documentation. While coding, Javadocs are added to each
method to explain the description of the class and the methods within it. The Javadocs will
explain how the methods work and who implemented them. This way, we will know which team
member implemented each method. It helps an outsider understand how the various methods
work separately and together for the robot to run.

5.0 Class Hierarchy Diagram

Figure 2: The figure above is the class hierarchy diagram that still requires the addition of key
classes in order meet specifications.

Author: Kiren Rao

5
Software Design Document Team 18

5.1 Wifi Class

The wifi class was set up to make sure the server and the client are able to communicate
effectively and transfer information. The wifi class for the robot is created to easily share game
parameters from the professor to the student. The parameters provide the robot important
details on where the starting point is, what team the robot is on (green or red) and the upper and
lower corners of specific objects and zones.

In order to integrate the wifi class into the existing project, the build path inside a new ‘lib’
folder was updated and then the relevant classes from the example code was imported. The
example code was modified to fit our case.

5.2 Bridge Traversal and Tunnel Traversal Class: Wheelbase Extension

One of the most important procedures to implement was the change in wheelbase in the
code. To extend and decrease the wheelbase of the robot, a motor placed in the center of the
robot is used and is turned 180º to extend the base, and back the 180º to make the base small
again. Due to the friction caused by the tires on the surface the robot needs to be moving in
order to complete the transition. Due to this fact, this class also has the robot back up from the
original point and move back while performing the transition. Please refer to the section 6.0 of
the Hardware Document to view the hardware design of the wheelbase.

This method was tried and tested but was unable to be completed. The robot was not
stable enough, therefore even if the motor was locked in the software, the wheelbase would still
change even when it was not desired to. Therefore the robot hardware was changed, which can
be viewed in section 7.0 of the Hardware Document. The new algorithm works similarly to the
previous except after the traversal of the structures we are performing a light localization to
ensure that the bumps encountered do not throw off the odometer.

5.3 Dpm Final Class

This class is used to drive the project. This is where all the hardware components and
values are initialized. This is also where all the threads are intialized. In addition, this this where
the parameters are received from wifi and passes them into their designmated functions.

5.4 Ultrasonic Localizer

This class is performed in the beginning of the run and is used to determine the correct
orientation of the robot. This is done by the falling edge method which is done by rotating first
clockwise then counterclockwise while looking for the wall and orientating accordingly based on
the angle at which a wall is detected while updating the theta value for the odometer.

6
Software Design Document Team 18

5.5 Odometer

This class determines the location of the robot on the 2D plane that is the playing field.
This will be updated based on the tachometer of the two motors and are set based on the
localization preformed. This class is the basis of the majority of the operation performed in this
project and ensures that the robot is cognizant of its position on the playing field even after the
initial localization had been performed.

5.6 Navigation

This class is the one that moves the robot on the 2d space. This is based on current
position and orientation of the robot from the odometer class. While traveling from point to point
if the ultrasonic sensor detects an obstacle the robot performs a predetermined maneuver out of
the way and recalculates the navigation to its original destination.

5.7 Search for Block

Once the robot has navigated to the lower left hand corner of the search area, the robot
starts moving in a serpentine motion throughout the search area ensuring that the greatest
possible area is covered. This is calculated through the use of the upper right hand corner as
well. If an object is detected it is classified and if it is the target block the searching will be
finished. If it is not, then the robot will maneuver around the block and continue the search until
it reaches the upper right hand corner where it will then continue with the other operations.

5.8 Light Localizer

This class is used in order to ensure the odometer is properly updated in an effort to
keep the actual position reflected by the odometer as accurately as possible. This is done by
rotating both clockwise and counterclockwise and determining when a line is crossed by the
rear end of the robot. Then based on these readings the robot then travels to the point closest to
the center of rotation and orientate accordingly.

7
Software Design Document Team 18

6.0 Edit History of the Software Changes

The recorded major changes to the code:

Version Date Author(s) Summary

1.0 28/02/18 Kiren Rao Improved the light localization and navigation

1.1 12/03/18 Kiren Rao Implementation of of search and color detection

1.2 18/03/18 Kiren Rao Completed the skeleton of the change of

wheelbase in the bridge and tunnel classes and
improved light localization

1.3 27/03/18 Kiren Rao Ensure that the parameter passed in from wifi are
correctly handled. Modified the localization
algorithm to better suit the new hardware. Ensure
the that the travelTo function is working based on
the coordinates presented in the project
specifications.

1.4 9/04/18 Kiren Rao Further corrections to the localization and

navigation. Modified the code the work on a
12x12 board instead of the 8x8 board present in
the beta demo.

1.5 12/04/18 Kiren Rao Removed vestigial code and updates the
javadocs.

7.0 Final Demonstration Report

The software for the final demonstration worked well. The reason behind a few failed
runs is either because of a hardware error or a human error. Therefore, the software was
consistent and successful for the final demonstration. The final demonstration results are listed
in section 6.0 of the Testing Document.

8
Software Design Document Team 18

8.0 Glossary of Terms

1. Javadocs:​ A documentation generator that converts java code into API documentation
in the form of HTML

2. API:​ Application Programmer Interface