I.

Introduction

In our design, one major concern was having a functional gate that opens and closes at
the appropriate times. Many programming errors did occur before we perfected the open-close
system of the model gate. We had to make the programming functional enough for our series of
tests. Many errors occurred such as format errors in the ROBOTC program language. We had to
correct many bugs in order to start our first quantitative or qualitative test. We created seven total
prototypes and the same testing procedures were done on all of them. The main objective of each
prototype was to physically count the number of matchbox cars that enter the built model of the
parking deck and make sure the force plate and light sensors work to the standard that we wish to
present.
One test that we performed involved us closing and opening the gate 50 times through
our ROBOTC program. The results are below:

Table 1.1
Gate Opening Test (Trials 1-50) Opened Every Time

Gate Closing Test (Trials 1-50) Closed Every Time

Another test we conducted was making sure that the parking space availabilities in our
prototype model were properly detected. We needed an accurate count of available parking lots
from a given set. To test this, we made sure that our computer program properly counted the
number of cars in the parking lot. Since this is a quantitative measurement, we decided that
testing 10 different scenarios of car parking would suffice for our project requirements.

Many qualitative tests were also observed. Qualitative tests are done on products such as
user interfaces or when there are general needs to attend to such as functionality or operations.
The prototype and the program worked together in an efficient and effective manner whenever
we did test runs.

II. Prototypes and User Interfaces

We had seven prototypes and user interfaces that needed to be tested. The user interfaces
were only tested for functionality and processing speed. It is imperative to have as little lag as
possible because many phone users do complain about lag in phones. There was no way that we
could test these qualitative properties in a quantitative manner.
Figure 1: User Interface Final Prototype
The diagram below properly shows how the input and output data in the computer program
displays the results. Since the image properly shows up, the program passes the test of
functionality. When the program was running, little to no lag was present in all test trials.

Input: (Image of parking lot) Output: (Image of parking lot)

Figure 2: Projections of Prototype 4 without Cars

Figure 3: Prototype 6 Shown with Die-Cast Car

Figures 2 and 3 show the prototype of our technology. We used VEX robotics in order to create a
program that replicates the functionality of our technology in the parking decks of
UNC-Charlotte. We tested whether or not the physical prototype works with the software
program. This long process was composed of many trial and error processes in order to
effectively create a proper prototype of our technology.

III. Expert Feedback

Mr. Ramchandra Pendyala, our expert mentor, worked with us and gave us feedback throughout
the project. He is currently a software engineer working at Bank of America. His understanding
and expertise of mechanical engineering and robot design comes from his masters degree at
UNC Charlotte. Throughout this project, Mr. Pendyala focused on creating a working prototype
that can be physically observed by people at the expo. He decided this because people get more
interested when they get to touch the technology that is being demonstrated. During the
beginning of this project, Mr. Pendyala emphasized researching various technologies that are
similar to ours. He advised us to “not reinvent the wheel.”

During the building phase, Mr. Pendyala gave us independence to explore various techniques in
software programming and engineering design. After the product was done, he gave us insightful
feedback. Mr. Pendyala complimented the immaculate documentation for this project. He
believes that organized documentation is essential to organize our data and present it for legal
guidelines or for business inquiries. Mr. Pendyala had great input in our project as a mentor. He
highly emphasized independent learning, yet he still made us understand the importance of
asking for help when needed.

Overall, he believed that this project is “well organized and well documented.” “Building a
working prototype in a short amount of time with no money spent is a great achievement. This
helps you learn to work under tight deadlines and budget and this is a challenge faced by many
professionals and corporations.”

He also explained that our testing procedures are excellent overall. He liked the fact that we
documented all seven prototypes and how we proved that Prototype 7 is indeed the best one.
However, he believes that we should add a few more quantitative measures for future reference.
“Qualitative measures may work in some instances, but quantitative measures are easier to
prove.” He goes on to explain that opinions should always be explained through data as much as
possible.

We asked him one major aspect of this project that we could have done better on. He emphasized
the we should “take input from employees of the Parking and Transportation Services
throughout the project because they are close to these challenges and deal with them on a day to
day basis.” He believed this because he feels like our progress would have been faster if we
contacted them more frequently. “Work closely with the people who are associated with the
problem and this includes the PATS employees in this case.”

For presentations, he believes that it would be best to create brochures. “Brochures leave the
audience with a good impression.” He also believes that candy bars do grab interest from people.
Bringing phones to show the application will show the legitimacy of this project.

In the future, Mr. Pendyala wants us to engage with Parking Services every step of the way.
“Validate all your assumptions and designs with them.” He wants us to build a pilot program that
works in a deck that is not used as often. “It is imperative to learn from the mistakes of the pilot
program and fix bugs accordingly before campus wide roll out.” Fundraise for this project
because the costs would be more than they are now. “Have a marketing plan. UNCC magazine,
homepage, social media, email, buses, flyers, elevators, and other apps.” He believes that we
should stick to a non profit model even though we will market the app extensively.
IV. Testing Results

Through trial and error, we successfully created a functional parking system that met our
needs and ran smoothly. In order for our parking system to not contain any errors, we ran a total
of one hundred trials, adding modifications each time. Testing had to be done on all seven
prototypes in order for the prototypes to work as intended.

The tests for the user interfaces (Prototypes 1-3) were purely qualitative. Prototype 1 was
functional in theory, but it lacked the appeal to the future users of this application. The overall
structure was sound, but the aesthetic design required some work. For Prototype 2, we included a
better background for the application and decided to add a map of UNC Charlotte. Our last user
interface or Prototype 3 included the application features of Prototype 2, but with a diagram that
labels the exact parking spaces that are available or unavailable.

Our first test for each prototype was to test the ability to count the parking space availability and
have outputs that convey relevant parking space data.

Chart 1.1

The above chart shows that Prototypes 6 and 7 accurately counted the inflow and outflow in the
parking deck prototype out of the four prototypes. The correct number of parking spaces counted
is indeed 25. We ran this test for each prototype ten times.
The only reason the program did not work with the prototype was syntax errors and we fixed
them as soon as they proved to be a problem.

Another set of tests involved checking whether the entire system worked autonomously. We
checked this 20 times in order to ensure that the system works as a whole. This is not a specific
measurement because this is qualitative to some extent. All the prototypes properly ran.

Table 1.2
Prototype Does the prototype notice a black car?

4 Yes

5 Yes

6 No

7 Yes

As shown in the Table 1.2, the only prototype that did not notice a black car was prototype 6. If
we plan on continuing this project in the future, we will need for the prototype to identify cars of
various colors. The prototypes noticed all other colored matchbox cars accurately.

Chart 1.2
Out of 10 matchbox cars, only 5 were accurately recorded in Prototype 4. That means that no
lights flashed for the other 5 matchbox cars. In Prototype 7, the program and the prototype work
together excellently because there is an accurate notification for all 10 matchbox cars. This is one
reason why we felt like Prototype 7 would be the best one to present.

Our other tests are conducted and recorded as videos:

Click ​here​ to view our video-graphic demonstration of Prototype 4.

Click ​here​ to view our video-graphic demonstration of Prototype 5.
Click ​here​ to view our video-graphic demonstration of Prototype 6.
Click ​here​ to view our video-graphic demonstration of Prototype 7.