Batch 33 Report Traffic Signal

VISVESVARAYA TECHNOLOGICAL UNIVERSITY
“JNANA SANGAMA”, BELGAUM - 590018
2020-21
COMPUTER GRAPHICS [18CS62]
Mini Project Report
On
TRAFFIC SIGNAL
SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENT IN 6TH SEMESTER
COMPUTER GRAPHICS PROJECT WORK (18CS62) OF BACHELOR OF ENGINEERING
IN
By
POOJA U S 4VM18CS030
YASHASWINI M S 4VM18CS048
UNDER THE GUIDANCE OF
Prof.AMBIKA
Assistant Professor
Dept. of CSE, VVIET
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
VIDYA VIKAS INSTITUTE OF ENGINEERING & TECHNOLOGY

#127-128, Mysore - Bannur Road, Alanahally, Mysuru, Karnataka 570028
Vidya Vikas Educational Trust ®
VIDYA VIKAS INSTITUTE OF ENGINEERING &
TECHNOLOGY
#127-128, Mysore - Bannur Road, Alanahally, Mysuru, Karnataka 570028
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CERTIFICATE
Certified that the COMPUTER GRAPHICS Mini Project Work entitled “TRAFFIC
SIGNAL” carried out by POOJA US [4VM18CS030] and YASHASWINI MS [4VM18CS048],
bonafide students of VVIET in partial fulfillment for the award of degree Bachelor of
Engineering in COMPUTER SCIENCE and ENGINEERING as prescribed by
VISVESVARAYA TECHNOLOGICAL UNIVERSITY, BELGAUM during the academic
year 2020-21. It is certified that all corrections/suggestions indicated for internal assessment
have been incorporated in the report deposited in the departmental library. The project
report has been approved as it satisfies the academic requirements in respect of mini
project work prescribed for the said degree.
[Mrs.AMBIKA] [Dr. MADHU B K]

Assistant Professor Professor & HOD
Dept. of CSE Dept. of CSE
EXTERNAL VIVA
Name of the examiners Signature with date
1.
2.
ACKNOWLEDGEMENT
We would like to thank and express our heartfelt gratitude to God almighty for the
abundant blessings without which this project would not have been successful.
We would like to express our sincere gratitude to Sri. Vasu, Chairman of VVIET,
Mr. Kaveesh Gowda V, Secretary of VVIET and all management members of VVIET, for their
constant support.
We acknowledge and express our sincere thanks to our beloved Principal
Dr. Ravishankar M, VVIET, Mysuru who is the source of inspiration.
We would like to express our deepest sense of gratitude towards Dr. Madhu B K,
Head of the Department, CSE, VVIET, Mysuru for his valuable suggestions, support and
encouragement.
We would like to extend our heartfelt gratitude to Mrs.Ambika, Assistant Professor,
Dept. of CSE, for the valuable guidance and advice. We would also like to thank him for his
guidance and useful suggestions, which helped us in completing the project work on time.
We would also thank all other teaching and non-teaching staffs of the Computer
Science Department who has directly or indirectly helped us in completion of this project.
Our thanks and appreciation also go to our family and friends who have willingly
helped us out with their abilities.
Regards,
POOJA US
Yashaswini MS
ABSTRACT
• Main aim of this Mini Project is to illustrate the concepts and usage of
pre-built functions in OpenGL.
• Simulation of a traffic signal is being done using computer graphics.
• The car built using cubes can be moved using arrow keys and based
on traffic signal light the user can obey the traffic rules.
• We have used input devices like mouse and key board to interact with
program
TABLE OF CONTENTS
Acknowledgement i
Abstract ii
Table of contents iii
List of Figures 5
1. Introduction
1.1 Aim 1
1.2 Problem statement 2
1.3 Motivation 2
1.4 Application 2
1.5 Advantages 2
2. Literature Survey 3-4
2.1 Related work 3
3. System Analysis 5-10
3.1 Hardware Requirements 5
3.2 Software Requirements 6
3.3 Existing Systems 6
3.4 Proposed System 7
3.5 Feasibility Study 8
3.6 Functional and non-functional requirements 9
4. Design and Analysis 11-22
4.1 System Design 11
4.2 System Architecture 15

4.3 System Modelling and Design 20
4.4 Use case diagram 21
5. Implementation 23-27
5.1 Working of traffic signal 23
6. System Testing 25-30
Conclusion 31
Future Enhancement 32
References 34
LIST OF FIGURES
Fig no Fig description Page no
3.1 Block diagram 7
4.1 Flow diagram of system 13
4.2 Methodology 16
4.6 Activity Diagram-Decision Tree 18
4.11 Use case diagram for USER 21
5.2 Other entity management 24
5.3 Flow Chart-Decision Tree 25

CHAPTER 1
INTRODUCTION
OpenGL Fundamentals
Primitives and Commands

OpenGL draws primitives—points, line segments, or polygons—subject to several selectable
modes.
Primitives are defined by a group of one or more vertices. Data is associated with a vertex, and
each vertex and its associated data are processed independently, in order, and in the same way.
The type of clipping depends on which primitive the group of vertices represents.
Commands are always processed in the order in which they are received, although there may be
an indeterminate delay before a command takes effect. This means that each primitive is drawn
completely before any subsequent command takes effect. It also means that state-querying
commands return data that's consistent with complete execution of all previously issued OpenGL
commands.
Basic OpenGL Operation
The figure shown below gives an abstract, high-level block diagram of how OpenGL processes
data. In the diagram, commands enter from the left and proceed through what can be thought of
as a processing pipeline. Some commands specify geometric objects to be drawn, and others
control how the objects are handled during the various processing stages.
Aim
The aim of developing Traffic Signal is to assign the right-of-way at intersecting streets or
highways where,without such control, a continual flow of vehicles on one road way would
cause excessive delay to vehicles and pedestrians waiting on the other roadway.
1.1 Problem statement
We cannot control the vehicles manually hence we need a device to control it and to avoid
accidents.
1.2 Motivation
Development of quantitative measures of oversaturated condition from traditional detection
systems.
Applications
 Ramp meeting
 Timers
 Fire station or medical emergency entrance
 At the entrance and exit of some car washes
 At the landing stage of a ferry and aboard the ferry
1.5 Advantages
 Provide for orderly movement of traffic;
 Increase traffic-handling capacity of an intersection;
 Reduce frequency and severity of certain types of crashes, especially right-angle
 collisions;
 Provide for continuous movement of traffic at a definite speed along a given route;
 Interrupt heavy traffic at intervals to permit other vehicles or pedestrians to
 cross
CHAPTER 2
LITERATURE SURVEY
A literature review is a written document that presents a logically argued case founded on
a comprehensive understanding of the current state of knowledge about a topic of study. This
literature review discusses about the work on traffic signal applications.
2.1 Related work
1. Traffic lights, traffic signals ,stoplights or robots are signalling devices positioned at
road intersections, pedestrian crossings, and other locations to control flows of
traffic.
2. The world’s first traffic light was a manually operated gas lit signal installed in
London in December 1868. It exploded less than a month after it was implemented,
injuring its policeman operator. Earnest Sirrine from Chicago patented the first
automated traffic control system in1910. It used the words “STOP and “PROCEED”,
although neither word was illuminated.
3. Traffic lights followed a universal color code which alternates the right of way
accorded to users with a sequence of illuminating lamps or LEDs of three standard
colours.
4. GREEN light: allows traffic to proceed in the direction denoted, if it is safe to do so
and there is room on the other side of the intersection.
RED light: prohibits any traffic from proceeding. A flashing red indication requires traffic
to stop and then proceed when safe.
YELLOW light: warns that the signal is about to change to red, with some jurisdiction
requiring drivers to stop if it is safe to do so and others allowing drivers to go through the
intersection if safe to do so.
CHAPTER 3
SYSTEM ANALYSIS
Analysis involves requirement determination and specification. It is basically establishing the
requirements for all system elements and then mapping these requirements to software forms. It
should address issues such as: -
 Profile of people who are operating on the system.

 Software on which the application is going to function.
 Existing system problems.
Analysis encompasses requirements gathering at the system level with small amount of top-level
design. The data obtained from the requirement determination phase are documented in Software
Requirement Specification (SRS) document. During analysis, a great deal of relatively
unstructured data is collected through procedural manuals and through websites. The traditional
approach is to organize and convert the data through system flowcharts, which support future
developments of the system and simplify communication with users. But the system flowcharts
represent the physical system rather than the logical system. Hence, it makes it difficult to
distinguish between what happens and how it happens in the system. Because of this drawback it
is necessary to have something, which is analogous to the architect's blueprint as a starting point
for the design. It is the way of focus on the functions rather than physical implementation.
Unnecessary or excessive traffic signals can create hazards. One of the greatest obstacles to
applying sound principles of traffic engineering is the common belief that simply installing a traffic
signal will solve any traffic problem.
3.1 Hardware Requirements
• GRAPHICS SYSTEM,
• Pentium P4 with 256 of Ram(Min)
3.2 Software Requirements
 MICROSOFT VISUAL C++
 OPENGL
3.3 Existing Systems
The existing system involves detection of vehicles which are breaking traffic
signal. It has central controller that is Arduino at junction which is connected to
sensors are placed at every road of junction which detects the vehicles which
might be inefficient when more than one peoples simultaneously go
Trough that way but single person is allow because of particular arrangement of
sensors. Consider if red signal is on and vehicle break signal then it will detect by
sensors and this signal is sent to Arduino. The Arduino capture image of that
vehicle using camera and save it as time and date format. The cameras are set at
every junction point is equal to the number of road meet at that junction.
3.4 Proposed system
Smart traffic signal device is made of three basic things that are ultrasonic sensor for detecting
the vehicle passing through when signal is on, microcontroller for examining the input coming
from ultrasonic sensor and give instruction to camera to capture image. In STS two sensors are
placed at one side of one road as shown in figure 4.1. That is if there are for road meet at one
traffic signal then four STS should be placed at every road. Generally width of road in India is 20
foot. The ultrasonic sensor covers the maximum area 4 meters (13.1234 foot) means sensors on
both sides are able to cover all area. The number of sensors on the both sides is increased
for more accuracy. If only one sensor detect the obstacle then proposed system STS is not
capture image because it may be human, animals etc. The length of vehicles is nearly about
equal to distance between two sensors on one side. This same system is applied on the opposite
side of road. Range of this two sensors are fixed as width of the road required to block with
respect to signal. This whole process is controlled by Arduino board which get input
from two or more ultrasonic sensors and capture image through camera and then save it as
name and date as the name of the image to make it easier to understand whenever the
vehicle paper size.
Fig:Block diagram of traffic signal
3.5 Feasibility Study

The feasibility study which helps to find solutions to the problems of the project.
The solution which is given that how looks as a new system look like.
Technical Feasibility
Technical requirement for the system is economic and it does not use any other additional
Hardware and software. Technical evaluation must also assess whether the existing systems can
be upgraded to use the new technology and whether the organization has the expertise to use it.
Install all upgrades framework into the .Net package supported windows based application this
application depends on Microsoft office and intranet service ,database. Enter their attendance and
generate report to excel sheet.
Economic Feasibility
Development of this application is highly economically feasible. The only thing to be done is
making an environment with an effective supervision. It is cost effective in the sense that has
eliminated the paper work completely. The system is also time effective because the calculations
are automated which are made at the end of the month or as per the user requirement.
Operational Feasibility
The system working is quite easy to use and learn due to its simple but attractive interface. User
requires no special training for operating the system.
3.6Functional and non-functional requirements

 Functional requirements
In Software engineering and systems engineering, a functional requirement defines a function of

a system or its component. A function is described as a set of inputs, the behaviour, and outputs.
Functional requirements may be calculations, technical details, data manipulation and processing
and other specific functionality that define what a system is supposed to accomplish. Behavioural
requirements describing all the cases where the system uses the functional requirements are
captured in use cases.
The functional requirements of our system are –
 User: General user is anyone who has the application.
 Load Data: There are many cities which are uploaded to the database to generate a result
about traffic.
 Non-functional requirements
In systems engineering and requirements engineering, a non-functional requirement (NFR) is a

requirement that specifies criteria that can be used to judge the operation of a system, rather than
specific behaviours. They are contrasted with functional requirements that define specific
behaviour or functions. The plan for implementing functional requirements is detailed in the
system design. The plan for implementing non-functional requirements is detailed in the system
architecture, because they are usually Architecturally Significant Requirements. Broadly,
functional requirements define what a system is supposed to do and non-functional requirements
define how a system is supposed to be. Non-functional requirements are often called "quality
attributes" of a system. Other terms for non-functional requirements are "qualities", "quality
goals", "quality of service requirements", "constraints" and "non-behavioural requirements”.
The non-functional requirements of our system are:
 Accessibility: It refers to the design of products, devices, services, or environments for

people who experience disabilities. The concept of accessible design and practice of
accessible development ensure both "direct access" (i.e. unassisted) and "indirect access"
meaning compatibility with a person's assistive technology.
 Availability – System will be available all time.
 Maintainability –The system provides a better platform for tracking and monitoring the
vehicles.
 Reliability – The system is scalable as it provides the better and faster results.
 Authentication: Only authorized nodes can communicate with others.
 The proposed system should support the end user requirements.
 The system is capable of processing when the large numbers of images are provided as
input and also it must be interactive and delays involved should be less. So, in every
action-response of the system, there should be no long-term delays.
CHAPTER 4
DESIGN AND ANALYSIS
4.1. System Design

System design is the process of defining the architecture, components, modules, interfaces, and
data for a system to satisfy the specified requirements. Here, the design functions and operations
are described in detail, including screen layouts, business rules, process diagrams and other
documentation. The output of this stage will describe the new system as a collection of modules
or subsystems. Having a design methodology enforces consistency in the work as it helps in
achieving the deadlines timely.
The design stage takes as its initial input the requirements identified in the approved
requirements document. For each requirement, a set of one or more design elements will be
produced that describe the desired software features in detail. They generally include functional
hierarchy diagrams, screen layout diagrams, tables of business rules, business process diagrams,
pseudo code, and a complete entity relationship diagram with a full structure of the database.
Systems design implies a systematic approach to the design of a system. It may take a bottom-up
or top-down approach, but either way the process is systematic wherein it takes into account all
related variables of the system that needs to be created — from the architecture, to the required
hardware and software, right down to the data and how it travels and transforms throughout its
travel through the system. Systems design then overlaps with systems analysis, systems
engineering and systems architecture.
Design begins with requirements model. The team works to transform this model into four level
of design detail and they are,
• The data structure
• The system architecture
• The interface representation
• The component level detail
The data design transforms the information domain model created during analysis into the data
structure that is required for the implementation. The data objects and relationships defined in the
entity relationship diagram and detailed data content depicted provide the basis for the data
design activity. Part of data design may occur in conjunction with the design of software
architecture.
The importance of software design can be stated with a single word - Quality. Design provides
the representations of software that can be assessed for quality. Design is an iterative process
through which requirements are translated into a "blueprint" for constructing the software. The
design represented at a high level of abstraction - a level that can be directly traced to the specific
system objective and more detailed data, functional and behavioural requirements. There are
three characteristics that serve as a guide for the evaluation of a good design. Each of these
characteristics is actually a goal of the design process. They are:
• The design must implement all of the explicit requirements contained in the analysis
model and also accommodate the desired implicit requirements.
• The design must be readable and understandable for coding, testing and subsequently
support the software.
• The design should provide a complete picture for addressing the data, functional and
behavioural domains from an implementation perspective.
The Software design includes different design materials. The designs are Architectural, Work
flow, Use case, Activity, Sequence, Database, Form Design. These designs are used in software
development of a web-application and provides details of how the android - application should be
created.
4.1.1. Product Perspective
Fig4.1:Flow diagram of system

The product consists of a model that functions based on
1.Collecting Data: The data is collected from previous animal records and new data is added to
the database.
2.Then pre-processing the data pre-processing is adding the data to the database
3.Performing data mining algorithms: The data mining algorithms include.
4.Adding new data: The new location data is added to the database.
5.Analysis: Analysis involves finding out the location.
6.Prediction: After prediction, the result is generated displaying the signal report.
7output: outputs weather and other entities.
Product Functions
1. Uploading Data
Uploading data sets to the database.

2. Perform Prediction
Prediction is done by each algorithm based on the constraints.

4.1.2. Design Process
The design process involves developing several models of the system at different levels of
abstraction. As design is decomposed, errors and omissions in earlier stages are discovered. And
their feedbacks help in earlier design models to be improved. The various design activities are:
 Architectural design: The sub-systems making up the systems and their relationships
are identified and documented.
 Abstract Specification: For each sub-system an abstract specification of the services it
provides and the constraint under which it must be operate is produced.
 Interface Design: For each sub-system, its interfaces with other sub-systems is designed
and documented. This interface specification must be unambiguous as it allows the sub-
system to be used without knowledge of the sub-system operation.
 Component Design: Services are allocated to different components and the interfaces of
these components are designed.
 Algorithm Design: The algorithms are used to provide services that are designed in
detail with corresponding specifications.
4.1.3. Design Strategies

The two design strategies are:
 Functional Design: The system is designed from a functional point of view, starting
with high-level view and progressively refining this into a more detailed design. The
system state is centralized and shared between the functions of operating on that state.
 Module Design: The system is viewed as a collection of modules rather than functions.
The different modules are later integrated together into a single unit.
4.2. System Architecture

A system architecture is the conceptual model that defines the structure, behaviour, and more
views of a system. An architecture description is a formal description and representation of a
system, organised in a way that supports reasoning about the structures and behaviours of the
system. A system architecture can comprise system components, the expand systems developed,
that will work together to implement the overall system.
4.2.1Methodology
Fig 4.2 Methodology
The study helps to clearly understand the concept, approach and certain terminology that revolve
around the project. The data from the GPS collar will be uploaded to the database and then the
database will send the last data uploaded to the Android application.
The development of both GPS tag and Android devices are done separately. This is because, both
tasks are connected only to the database. For GPS collar, the task that is required to accomplish is
to link the tag to the database.
As soon as GPS tag and the Android app are working, the system will be tested. This project is
divided into two implemented parts: software and hardware. The software part is programmed
and that works in (Java /other programming language) Environment and the large database
system is designed by (SQLite Database Server version.
 Decision Tree Algorithm: A decision tree is a structure that includes a root node,
branches, and leaf nodes. Each internal node denotes a test on an attribute, each branch
denotes the outcome of a test, and each leaf node holds a class label. The topmost node in
the tree is the root node.
4.2.2Data Flow Diagram: The DFD is also called as bubble chart. It is a simple graphical
formalism that can be used to represent a system in terms of input data to the system, various
processing carried out on this data, and the output data is generated by this system.
Fig4.3: dataflow diagram

Activity diagrams represent the business and operational workflows of a
system. An Activity diagram is a dynamic diagram that shows the activity and the
event that causes the object to be in the particular state. It is a simple and intuitive
illustration of what happens in a workflow, what activities can be done in parallel,
and whether there are alternative paths through the workflow.
 Decision Tree
D ec is io n Tre e
C o un t D a ta s e t
C re at e N od e Tree s
F et c h D a ta s et s
D a ta s et D e t ails
ge ne rat e G ra ph
Fig 4.6: Activity Diagram-Decision Tree

Form Design
The form design is about the web pages created in the system. In simple it is those hyperlink
pages that appear before user logs into the system. The web forms are Home, Load data, Disease
Prediction, Comparison Study. The other pages are Decision Tree.
4.3. System Modelling and Design
This section discusses the design methodology and basic theory of components of the
project with the section further divided into sections for components theory and system
design & analysis.
4.3.1 Component Theory

The theory of the components employed in this work ranging from their basic principles
of operation to their applications in this project work is explained in this sub-section. The
components used in this work includes; GPS module, GSM module, other passive
components.
A GSM module is a device which can be

either a
mobile phone or a modem device
which can be
used to make a computer or any other
processor
communicate over a network. A GSM
module
requires a SIM card to be operated and
operates
over a network range subscribed by the
network
operator. The GSM module has a wide
range of
applications such as in transaction
terminals,
tracking, security applications, weather
stations
and GPRS mode remote data logging.
A GSM module is a device which can be
either a
mobile phone or a modem device
which can be
used to make a computer or any other
processor
communicate over a network. A GSM
module
requires a SIM card to be operated and
operates
over a network range subscribed by the
network
operator. The GSM module has a wide
range of
applications such as in transaction
terminals,
tracking, security applications, weather
stations
and GPRS mode remote data loggin
4.4. Use case diagram
CHAPTER 5
IMPLEMENTATION
A software system test plan is a document that describes the objectives, scope, approach and
focus of software testing effort. The process of preparing a test plan is a usual way to think the
efforts needed to validate the acceptability of a software product. The complete document will
help people outside the test group understand the "WHY" and "HOW" product validation. It
should be through enough to be useful but not so through that no one outside the test group will
read it.
Various functions used in this program.
 glutInit() : interaction between the windowing system and OPENGL is
initiated
 glutInitDisplayMode() : used when double buffering is required and depth

information is required
 glutCreateWindow() : this opens the OPENGL window and displays the

title at top of the window
 glutInitWindowSize() : specifies the size of the window
 glutInitWindowPosition() : specifies the position of the window in screen

co-ordinates
 glutKeyboardFunc() : handles normal ascii symbols
 glutSpecialFunc() : handles special keyboard keys
 glutReshapeFunc() : sets up the callback function for reshaping the

window
 glutIdleFunc() : this handles the processing of the background
 glutDisplayFunc() : this handles redrawing of the window
 glutMainLoop() : this starts the main loop, it never returns
 glViewport() : used to set up the viewport
 glVertex3fv() : used to set up the points or vertices in three dimensions

SOURCE CODE
// #include "stdafx.h"
#include "GL/freeglut.h"
#include "GL/gl.h"
// #include<GL/glut.h>
// #include <stdio.h>
#include <string>
#include <iostream>
#define ESCAPE 27
#define HIGH 1
#define LOW 0.2
#define RED 0
#define YELLOW 1
#define GREEN 2
#define drawOneLine(x1,y1,x2,y2) glBegin(GL_LINES); \
glVertex2f ((x1),(y1)); glVertex2f ((x2),(y2)); glEnd();
using namespace std;
GLint crx = -500, blx = -300;
int view=0;
bool rl1[] = {false, false, true};
bool rl2[] = {false, false, true};
void text(int x, int y, string s, int font) {
int i=0;
glColor3f(0.0,0.0,0.8);
glRasterPos2f(x,y);
for(i=0;i<s.length();i++) {
if(font==1)
glutBitmapCharacter(GLUT_BITMAP_TIMES_ROMAN_24,s[i]);
else if(font==2)
glutBitmapCharacter(GLUT_BITMAP_HELVETICA_18,s[i]);
else if(font==3) {
glColor3f(1.0,0.0,0.0);
glutBitmapCharacter(GLUT_BITMAP_HELVETICA_18,s[i]);
void First_win() {
glClearColor(1.0,1.0,0.6,1.0);
text(290,700,"TRAFFIC LIGHT SIMULATOR",1);
text(390,660,"Using OpenGL",1);
text(430,620,"Made By:",2);
text(300,580,"Yashaswini.M.S & Pooja.U.S",1);
text(400,540,"INSTRUCTIONS::",2);
text(100,500,"For Left Traffic Light",2);

text(100,460,"Q -- Red Light",2);
text(100,420,"W -- Yellow Light",2);
text(100,380,"e -- Green Light",2);
text(560,500,"For Right Traffic Light",2);
text(600,460,"A -- Red Light",2);
text(600,420,"S -- Yellow Light",2);
text(600,380,"D -- Green Light",2);
text(200,100,"!!!!PRESS SPACEBAR TO ENTER INTO THE ARENA!!!!",3);
glutPostRedisplay();
//glutSwapBuffers();
void init() {
glClearColor(0, 0, 0, 0);
glPointSize(5.0);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho(0.0,1000,0.0,800,50.0,-50.0);
glutPostRedisplay();
void car_chalao() {
if(rl1[GREEN] || crx > 0)
crx += 3;
if(!rl1[GREEN] && (crx > -100 && crx < 0)) {
crx -= 3;
if(rl1[RED] && crx < -100)

crx += 3;
if(rl1[YELLOW] && (crx > 0 || crx < -100))
crx += 3;
if(crx > 1200) {
crx = -300;
void bus_chalao() {
// blx -= 2;
if(rl2[GREEN] || blx > 700) {
blx -=2;
if(!rl2[GREEN] && (blx < -650 && blx > -720)) {
blx += 2;
if((rl2[RED] || rl2[YELLOW]) && (blx > -650 || blx < -720)) {
blx -= 2;
if(blx < -1650) {
blx = -300;
void bus() {
glPushMatrix();
glTranslated(blx,-100,0);
glScaled(50.0,50.0,0.0);
glColor3f(0.5,0.0,0.0);
//bus out line
glBegin(GL_POLYGON);
glVertex2f(25,8);
glVertex2f(25,9.5);
glVertex2f(26,11);
glVertex2f(32,11);
glVertex2f(32,8);
glEnd();
//window frame
glColor3f(0,0.1,1);
glVertex2f(26.1,9.5);
glEnd();
//Doors
glColor3f(0,0.8,1);
glVertex2f(26.2,9);
glVertex2f(27.7,9);
glEnd();
glColor3f(1,1,1);
glVertex2f(27,8.4);
glVertex2f(27,10.4);
glEnd();
//small windows
glColor3f(0,1,1);
glVertex2f(29,10.4);
glVertex2f(29,9.6);
glEnd();
glEnd();
glEnd();
//driver window
glColor3f(0,0.8,1);
glVertex2f(25,9.5);
glVertex2f(26,11);
glVertex2f(26,9.5);
glEnd();
glPopMatrix();
//tyre
glPushMatrix();//front tyre
glTranslated(blx+1220,250,0.0);
glScaled(20.0,20.0,0.0);
glColor3f(0.0,0.0,0.0);
glEnd();
glPopMatrix();
glPushMatrix();//back tyre
glTranslated(blx+1460,250,0.0);
glScaled(20.0,20.0,0.0);
glColor3f(0.0,0.0,0.0);
glEnd();
glPopMatrix();
void car() {
glPushMatrix(); //making color for outer line
glLineWidth(1.0);
glTranslated(crx,400.0,0.0);
glScaled(20.0,20.0,0.0);
glColor3f(0.2,0.3,1.0);
glEnd();
glColor3f(1.0,1.0,1.0); //color for outer window
glEnd();
glColor3f(0.0,0.0,0.0);
glBegin(GL_POLYGON); //drawing a back tyre
glEnd();
glBegin(GL_POLYGON); //drawing front tyre
glVertex2f(19.45,2.15);
glVertex2f(17.75,1.35);
glVertex2f(17.45,1.55);
glEnd();
glPopMatrix();
void traffic_light() {
//traffic signal controller
glPushMatrix();
glTranslatef(-190,20,0);
glColor3f(0.0,0.0,0.0);
// glColor3f(0.7,0.3,0.0);
glVertex2d(600,350); //1
glVertex2d(650,350); //2
glVertex2d(650,370); //3
glVertex2d(600,370); //12
glEnd();
glPopMatrix();
glPushMatrix();
// glColor3f(0.6,0.2,0.0);
glVertex2d(630,370); //4
glVertex2d(630,520); //5
glVertex2d(620,520); //10
glVertex2d(620,370); //11
glEnd();
glPopMatrix();
// Left Red Light
glPushMatrix();
// glColor3f(0.7,0.3,0.0);
glVertex2d(600,450); //6
glVertex2d(600,600); //7
glVertex2d(550,600); //8
glVertex2d(550,450); //9
glEnd();
glPopMatrix();
//Right Red Light
glPushMatrix();
// glColor3f(0.7,0.3,0.0);
glVertex2d(700,450); //11
glVertex2d(700,600); //12
glVertex2d(650,600); //13
glVertex2d(650,450); //14
glEnd();
glPopMatrix();
//Connecting Rod
glPushMatrix();
// glColor3f(0.7,0.3,0.0);
glVertex2d(650,520); //15
glVertex2d(650,540); //16
glVertex2d(600,540); //17
glVertex2d(600,520); //18
glEnd();
glPopMatrix();
//Left Lights
//Red 1
glPushMatrix();
glTranslatef(385, 580, 0);
if(rl1[RED])
glColor3f(1.0, 0.0, 0.0);
else
glColor3f(0.2, 0.0, 0.0);
glutSolidSphere(12, 80, 80);
glPopMatrix();
//Yellow 1
glPushMatrix();
if(rl1[YELLOW])
glColor3f(1.0, 1.0, 0.0);
else
glColor3f(0.2, 0.2, 0.0);
glPopMatrix();
//Green 1
glPushMatrix();
if(rl1[GREEN])
glColor3f(0.0, 1.0, 0.0);
else
glColor3f(0.0, 0.2, 0.0);

glPopMatrix();
//Right Lights
//Red 2
glPushMatrix();
if(rl2[RED])
glColor3f(1.0, 0.0, 0.0);
else
glColor3f(0.2, 0.0, 0.0);
glPopMatrix();
//Yellow 2
glPushMatrix();
if(rl2[YELLOW])
glColor3f(1.0, 1.0, 0.0);
else
glColor3f(0.2, 0.2, 0.0);
glPopMatrix();
//Green 2
glPushMatrix();
if(rl2[GREEN])
glColor3f(0.0, 1.0, 0.0);

else
glColor3f(0.0, 0.2, 0.0);
glPopMatrix();
void gra(int x,int y,int p,int q,float r,float g,float b)
glPushMatrix();
glColor3f(r,g,b);
glLineWidth(2.0);
glBegin(GL_LINES);
glVertex2d(x,y);
glVertex2d(p,q);
glEnd();
glPopMatrix();
void grass()
float r=1.0,g=0.0,b=0.8;
for(int k=0;k<300;k+=50) ////left grass
if(r>0)
r-=.2;
else
r=1.0;
if(g<1)
g+=.2;
else
g=0.0;
if(b>0)
b-=.2;
else
b=1.0;
for(int i=0, j=525,c=0;c<5;i+=15,j-=5,c++)
gra(i+k,525,30+k,500,r,g,b);
for(int k=0;k<500;k+=50) //right grass
if(r>0)
r-=.2;
else
r=1.0;
if(g<1)
g+=.2;
else
g=0.0;
if(b>0)
b-=.2;
else
b=1.0;
for(int i=500,c=0;c<5;i+=15,c++)
gra(i+k,525,530+k,500,r,g,b);
}
}
void white_strips() {
//Left
glPushMatrix();
glColor3f(1.0, 1.0, 1.0);
glEnable(GL_LINE_STIPPLE);
glLineWidth(12.0);
glLineStipple (4, 0x0FFF);
drawOneLine (0.0, 365.0, 250.0, 365.0);
glDisable(GL_LINE_STIPPLE);
glPopMatrix();
//Right
glPushMatrix();
glColor3f(1.0, 1.0, 1.0);
glLineWidth(12.0);
glLineStipple (4, 0x0FFF);
drawOneLine (620.0, 365.0, 1500.0, 365.0);
glPopMatrix();
void zebra() {
//Left
glPushMatrix();
glColor3f(1.0, 1.0, 1.0);

glLineWidth(12.0);
glLineStipple (1, 0x00FF);
for(float i=360.0, j=280.0, c=0; c<10; i-=5, j-=5, c++) {
drawOneLine (i, 250.0, j, 500.0);
glPopMatrix();
//Right
glPushMatrix();
glColor3f(1.0, 1.0, 1.0);
glLineWidth(12.0);
// drawOneLine (660, 250.0, 550, 500.0);
drawOneLine (i, 250.0, j, 500.0);
glPopMatrix();
//Top
glPushMatrix();
glColor3f(1.0, 1.0, 1.0);
glLineWidth(12.0);

// drawOneLine (300, 505.0, 500, 505.0);
drawOneLine (300, i, 500, j);
glPopMatrix();
void road_strips() {
//first bottom green strip
glPushMatrix();
glColor3f(0.85,0.64,0.12);
glVertex2d(0,200);
glVertex2d(0,250);
glVertex2d(1000,250);
glEnd();
glPopMatrix();
//second grey strip
glPushMatrix();
glColor3f(0.5,0.5,0.5);
glVertex2d(0,250);
glVertex2d(0,500);
glEnd();
glPopMatrix();
//tilted grey strip
glPushMatrix();
glColor3f(0.5,0.5,0.5);
glEnd();
glPopMatrix();
zebra();
//Grass
grass();
//Dotted strips
white_strips();
car();
traffic_light();
bus();
car_chalao();
bus_chalao();
}
void main_display() {
glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
if(view==0) {
init();
First_win();
else {
//---------CONSTANT PARTS
//ROAD STRIP
road_strips();
glutSwapBuffers();
void traffic_start() {
void keyboard(unsigned char key, int x, int y) {
switch(key) {
case ESCAPE:exit(1);
case ' ':

view=1;
glClearColor(0.6, 0.8, 0.2, 0);
//glColor3f(0.85,0.64,0.12);
traffic_start();
break;
case 'q':
cout<<"Red light 1 to RED"<<endl;
rl1[RED] = true;
rl1[YELLOW] = false;
rl1[GREEN] = false;
break;
case 'w':
cout<<"Red light 1 to YELLOW"<<endl;
rl1[RED] = false;
rl1[YELLOW] = true;
rl1[GREEN] = false;
break;
case 'e':
cout<<"Red light 1 to GREEN"<<endl;
rl1[RED] = false;
rl1[GREEN] = true;
break;
case 'a':
cout<<"Red light 2 to RED"<<endl;
rl2[RED] = true;
rl2[GREEN] = false;
break;
case 's':
cout<<"Red light 2 to YELLOW"<<endl;
rl2[RED] = false;
rl2[YELLOW] = true;
rl2[GREEN] = false;
break;
case 'd':
cout<<"Red light 2 to GREEN"<<endl;
rl2[RED] = false;
rl2[GREEN] = true;
break;
default:
cout<<"You pressed: "<<key;
void reshape(int w,int h) {
glViewport(0,0,w,h);
cout<<"Width="<<w<<" height= "<<h<<endl;
int main(int argc,char** argv) {
glutInit(&argc,argv);
glutInitDisplayMode(GLUT_RGBA|GLUT_DEPTH|GLUT_DOUBLE);
glutInitWindowSize(1000,800);
glutInitWindowPosition(0,0);
glutCreateWindow("Traffic Light Simulation");
//glutFullScreen();
glutDisplayFunc(main_display);
glutReshapeFunc(reshape);
glutKeyboardFunc(keyboard);
glutIdleFunc(main_display);
//glutMouseFunc();
glutMainLoop();
return 0;
}
CHAPTER 6
SYSTEM TESTING
Software testing is a process of executing a program or application with the intent of finding the
software bugs. It can also be stated as the process of validating and verifying that a software
program or application or product meets the business and technical requirements that guided its
design and development. The purpose of testing can be quality assurance, verification and
validation, or reliability estimation. Testing can be used as a generic metric as well. Correctness
testing and reliability testing are two major areas of testing. Software testing is a trade-off
between budget, time and quality.
6.1. What is Verification and Validation?
Verification is the process to make sure the product satisfies the conditions imposed at the start of
the development phase. In other words, to make sure the product behaves the way we want it to.
Validation is the process to make sure the product satisfies the specified requirements at the end
of the development phase. In other words, to make sure the product is built as per customer
requirements.
6.2. Key Benefits of Testing
The key benefits of testing are
 Reduced risk of failures (or incidents) once systems are transferred to live operation
 Demonstrative proof that business requirements have been met
 Assurance that the system will function appropriately with existing legacy systems
where required and will integrate with other systems as necessary
 Assurance that the users for which the solution was designed are able to operate
productively
Acknowledging these benefits requires accepting the reality that testing costs money. Too much
testing could be risky, as it may delay product launch and allow a competitor to steal significant
market share. Unfocused, inefficient approaches to test management often result in poor return
on investment in testing. As a rule of thumb, sufficient testing is where the costs of testing can be
balanced against the potential costs of failures and over run. The risks of failure and business
benefit should be used to determine how much testing is performed.
6.3. Basics of Testing
There are two basics of software testing: Blackbox testing and Whitebox testing.
6.3.1. Behavioural testing:
Behavioural or Black-box testing is a method of software testing that examines the functionality
of an application without peering into its internal structures or workings. This method of test can
be applied to virtually every level of software testing: unit, integration, system and acceptance.
6.3.2. Structural Testing
Structural or White box testing is a testing technique that examines the program structure and
derives test data from the program logic/code. The other names of glass box testing are clear box
testing, open box testing, logic driven testing or path driven testing or structural testing.
6.4. Types of Testing
Testing is the process where we validate and verify if the product meets the user’s requirements
and adheres to the specification. There are several types of testing processes available.
• Unit Testing
• Integration Testing
• Functional Testing
• System Testing
• Stress Testing
• Performance Testing
• Usability Testing
• Acceptance Testing
• Regression Testing
• Beta Testing
6.4.1. Unit Testing

Unit testing is the testing of an individual unit or group of related units. It falls under the class of
white box testing. It is often done by the programmer to test that the unit he/she has implemented
is producing expected output against given input.
6.4.2. Integration Testing
Integration testing is testing in which a group of components are combined to produce output.
Also, the interaction between software and hardware is tested in integration testing if software
and hardware components have any relation. It may fall under both white box testing and black
box testing.
6.4.3. Functional Testing
Functional testing is the testing to ensure that the specified functionality required in the system
requirements works. It falls under the class of black box testing.
6.4.4. System Testing
System testing is the testing to ensure that by putting the software in different environments (e.g.,
Operating Systems) it still works. System testing is done with full system implementation and
environment. It falls under the class of black box testing.
6.4.5. Stress Testing
Stress testing is the testing to evaluate how system behaves under unfavourable conditions.
Testing is conducted at beyond limits of the specifications. It falls under the class of black box
testing.
6.4.6. Performance Testing
Performance testing is the testing to assess the speed and effectiveness of the system and to make
sure it is generating results within a specified time as in performance requirements. It falls under
the class of black box testing.
6.4.7. Usability Testing
Usability testing is performed to the perspective of the client, to evaluate how user-friendly the
GUI is? How easily can the end users learn? After learning how to use, how proficiently can the
users perform? How pleasing is it to use its design? This falls under the class of black box
testing.
6.4.8. Acceptance Testing
Acceptance testing is often done by the customer to ensure that the delivered product meets the
requirements and works as the customer expected. It falls under the class of black box testing.
6.4.9. Regression Testing
Regression testing is the testing after modification of a system, component, or a group of related
units to ensure that the modification is working correctly and is not damaging or imposing other
modules to produce unexpected results. It falls under the class of black box testing.
6.4.10. Beta Testing
Beta testing is the testing which is done by end users, a team outside development, or publicly
releasing full pre-version of the product which is known as beta version. The aim of beta testing
is to cover unexpected errors. It falls under the class of black box testing.
6.5. Manual and Automation Testing
6.5.1. Manual Testing
Manual testing includes testing a software manually, i.e., without using any automated tool or
any script. In this type, the tester takes over the role of an end-user and tests the software to
identify any unexpected behaviour or bug. There are different stages for manual testing such as
unit testing, integration testing, system testing, and user acceptance testing.
Testers use test plans, test cases, or test scenarios to test a software to ensure the completeness of
testing. Manual testing also includes exploratory testing, as testers explore the software to
identify errors in it.
6.5.2. Automation Testing
Automation testing, which is also known as Test Automation, is when the tester writes scripts
and uses another software to test the product. This process involves automation of a manual
process. Automation Testing is used to re-run the test scenarios that were performed manually,
quickly, and repeatedly.
Apart from regression testing, automation testing is also used to test the application from load,
performance, and stress point of view. It increases the test coverage, improves accuracy, and
saves time and money in comparison to manual testing.
6.6. Test Cases
A test case is a set of conditions or variables under which a tester will determine whether a
system under test satisfies requirements or works correctly. The process of developing test cases
can also help find problems in the requirements or design of an application.
Writing good test cases involve the following steps —
• Test cases should be ‘atomic’; they should not overlap or complicate testing. Each test case
should be written such that only one thing should be tested at a time
• All positive and negative scenarios should be considered
• Each test case should be written in a language that is simple and easy to understand, using an
active voice, and using consistent and exact names
The characteristics of a good test case are —
• Accurate
• Economical
• Traceable
• Repeatable
• Reusable
CONCLUSION
The project “Traffic Signal” clearly demonstrates the simulation of traffic signal
using OpenGL.
Finally we conclude that this program clearly illustrate the traffic signal using
openGL and has been completed successfully and is ready to be demonstrated.
FUTURE ENHANCEMENT
 We can increase the efficiency by using microprocessors(8086)

 We can use this as Remote Traffic Controller
REFERENCES
http://jerome.jouvie.free.fr/OpenGl/Lessons/Lesson3.php
http://google.com
http://opengl.org

Batch 33 Report Traffic Signal

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Batch 33 Report Traffic Signal

Uploaded by

Copyright:

Available Formats

VISVESVARAYA TECHNOLOGICAL UNIVERSITY

“JNANA SANGAMA”, BELGAUM - 590018

UNDER THE GUIDANCE OF

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

VIDYA VIKAS INSTITUTE OF ENGINEERING & TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

[Mrs.AMBIKA] [Dr. MADHU B K]

Table of contents iii

1.2 Problem statement 2

2. Literature Survey 3-4

2.1 Related work 3

3. System Analysis 5-10

3.1 Hardware Requirements 5

3.2 Software Requirements 6

3.3 Existing Systems 6

3.4 Proposed System 7

3.5 Feasibility Study 8

3.6 Functional and non-functional requirements 9

4. Design and Analysis 11-22

4.1 System Design 11

4.2 System Architecture 15

Fig no Fig description Page no

3.1 Block diagram 7

4.1 Flow diagram of system 13

4.6 Activity Diagram-Decision Tree 18

4.11 Use case diagram for USER 21

5.2 Other entity management 24

5.3 Flow Chart-Decision Tree 25

Primitives and Commands

Basic OpenGL Operation

1.1 Problem statement

 Profile of people who are operating on the system.

3.1 Hardware Requirements

3.2 Software Requirements

 MICROSOFT VISUAL C++

3.4 Proposed system

3.5 Feasibility Study

3.6Functional and non-functional requirements

In Software engineering and systems engineering, a functional requirement defines a function of

In systems engineering and requirements engineering, a non-functional requirement (NFR) is a

The non-functional requirements of our system are:

 Accessibility: It refers to the design of products, devices, services, or environments for

 Availability – System will be available all time.

 Authentication: Only authorized nodes can communicate with others.

 The proposed system should support the end user requirements.

DESIGN AND ANALYSIS

4.1. System Design

Fig4.1:Flow diagram of system

Uploading data sets to the database.

Prediction is done by each algorithm based on the constraints.

4.1.3. Design Strategies

4.2. System Architecture

Fig 4.2 Methodology

Fig4.3: dataflow diagram

Fig 4.6: Activity Diagram-Decision Tree

4.3.1 Component Theory

A GSM module is a device which can be

 glutInitDisplayMode() : used when double buffering is required and depth

 glutCreateWindow() : this opens the OPENGL window and displays the

 glutInitWindowSize() : specifies the size of the window

 glutInitWindowPosition() : specifies the position of the window in screen

 glutKeyboardFunc() : handles normal ascii symbols

 glutSpecialFunc() : handles special keyboard keys

 glutReshapeFunc() : sets up the callback function for reshaping the