Guidance to Visualized Park Management Software
UM-SJTU JI SP21 ENGR1510J Project 3 (Group)
This project is completed by pgroup-16, which means all of the files and codes have been scripted by the group members.
Name: Zhou Ziming
Student ID: 521370910142
Name： He Zhongmou
Student ID: 521370910056
Name： Lu Yiming
Student ID: 521021910389
Name： Fu Haotian
Student ID: 520021910012
This project is completed basically in two parts: non-OpenGL part and OpenGL part, related to
pms.cppandipa.cppcorrespondingly.
To run this program you first need to ensure that C++ environment is configured in your machine. You may also refer to ENGR151-2021FA Lab Manual for detailed help.
Clone this repo:
git clone ssh://git@focs.ji.sjtu.edu.cn:2222/ENGR151-21/pgroup-16.git
This program is to animate the parking process in a SPACIAL PARKING SLOT.
To experience our program, you need to
- Clone this repo and open the file folder with proper IDE, like CLion or VS.
- Type following commands to set up two executable files - p3_part1.exe and p3_part2.exe correspondingly. (Here we prepare both the makefile and Cmakelist.txt file to ensure the smooth running of the project, and since the main IDE that we use to run our program is Clion, it is highly recommended that you run the whole project on Clion)
cd cmake-build-debug
Cmake ..
Make
- Run
p3_part1.exeandp3_part2.exedirectly.
This project aims to establish a parking lot management system using both the traditional command-line method as well as the Open-GL graphical monitoring technology. When the size of the parking lot, the identity of cars with their intervals to stay in the parking lot is given, then the program will simulate the whole process according to those data and present ticket to each car after they finally leave the parking lot.
establishing a parking lot management system
-
NON Open_GL mode (aka pure command line mode)
-
Open_GL mode (where Open_GL related setting is configures and graphical interface is presented)
-
Specially Notified the method to switch between those two parts
in order to successfully switch between the OPEN_GL or NON OPEN_GL mode we should not only pay attention which part (p3_part1 or p3_part 2) we are currently compiling but also remember to ADD COMMENT to the macro OPEN_GL in file ”OPEN_GL_ENABLED.h" when we are compiling part to and **DELETE **the comment for part
-
NON OpenGL mode:
Under this mode the whole animation process is presented solely on the command line. The user is required to input the number of slots in each column and each row of the car plot to animate the whole program. Also notified that since the information of vehicles would be too demanding for the user to input each time, here we adopt the file input strategy and directly read the data from file Car.log (which is under the main repo of the program). Therefore, please do remember to move the file at the same repo with the execution program to ensure the smoothness of the whole running process.
-
Open_GL mode:
Under this mode since no parameter could be carried by the display function, the number of slots in each column and row has been set in default. And other setting are the same as those in NON Open_GL mode.
Functions dealing with car_detection fail to function properly sometimes, which means that there are originally car crashes during the running of the program.
-
In general, you need to identify parts of the code you believe to be “too complicated”
After double check, we reach the conclusion that most of the code satisfy the requirement in the file
except the function related to the state machine algorithm (related to status):
- detect_safe
- change_status
And we have already list this part to the BUG section
-
Avoid a very long drawing function that continuously creates (destroys) objects. In the display function (the function where you instantiate and draw figures), will implement all the animations. The code tends to be lengthy, and the logic quite complex. Besides for each frame drawn, the objects are created then destroyed. This represents a waste of time and resources. It there a good workaround?
We solve this problem by introducting static vector container that contain all the vehicles and the graphical widget is harbored into it so it would be destroyed and constructed over and over again.
Specially Notified that the hierarchy of basic class in part A and part B remains mostly the same. However, any class that inherits from the Figure class would not be adopted in part A.
- the introduction of widget class in the program
By referring to our experience in coping with gtk-pack in project 2, we adopt the strategy of establishing a graphic widget affiliated to every item of our project that requires drawing. This tactic renders significant stability to the project in two significant ways:
-
By separating the actual properties of the item with its graph-specific identities, we can easily create two mode with or without Open_GL by choosing whether or not to adopt those graphical widget in our item class.
-
This methodology creates more flexibility for future development. For example, since the visible coordinates for OPEN_GL is always restricted to -1~1, it is very complex to apply to actual usage in our daily life where the magnitude of the value always exceeds that level. By this means, we can easily create a automatic conversion system and introduce a new coordinate system that is more close to our actual needs.
-
the introduction of macro for switching between the OPEN_GL or NON OPEN_GL mode
- the macro is introduced with meticulous concerns in order to lessen the burden to restructure the code for both modes. i.e. We could use #ifdef or #ifndef macro to decide on which part of a single function would be activated and are free from writing two similar functions which would diminish the user-friendliness as well as conciseness of the code.
- Specially Notified Again that in order to successfully switch between the OPEN_GL or NON OPEN_GL mode we should not only pay attention which part (p3_part1 or p3_part 2) we are currently compiling but also remember to ADD COMMENT to the macro OPEN_GL in file ”OPEN_GL_ENABLED.h" when we are compiling part to and **DELETE **the comment for part 1.
-
the introduction of "state machine" methodology to cope with the animation process for each car.]
For example, in function change_status() which integrated most condition judgment and animation related functions, the function is organized by a big switch case structure. Every case means a different status for a car and then we handle every situation for case_change respectively.
The comments in the code below are concrete examples to that methodology which represent the introduction of each case and a rough description to every function that we need to realize during the animation process. By this means we gradually establish the overall animation structure of the whole project.
///if the time reaches
///enter into the plot
case 1:{
///print the enter ticket
/// find the plot for the current car
//specially remember that if the current floor is full, there is also chance that the car would eventually find its plot at othe floors
///begin the self-detect process
//self-detect process for the front car to decide whether to stop
///begin the straight auto-move process
// if the stop signs remains false, do move for constant speed per unit
break;
}
///if reach the turning point --> calculating for the turning point
///then enter into the side road
case 2:{
/// send continuous signal to the following car to **wait behind**
// if their distance to the *branch* is less than the normal car distance
///signal to the following car to stop Anyway! to prevent further trouble
///begin the curving the auto-move process
///begin the auto-rotate process
break;
}
/// if the anchor point totally enter into the side road
case 3:{
///self detect process
///signal to the **possible** car staying in the plot aside the car and prevent them from going out
///begin the straight auto-move process
//change back -> move straight
///end the auto-rotate process
///SPECIAL: once the car move past the parking lot,
// send continuous signal to the following car to **wait behind**
// if their distance to the *plot* is less than the normal car distance
break;
}
///if reach the plotting point --> calculating for the plotting point
///enter into the planned plotting place
case 4:{
/// CONTINUE from case 3
/// send continuous signal to the following car to **wait behind**
// if their distance to the *plot* is less than the normal car distance
///begin the curving auto-move process (reverse version)
///begin the auto-rotate process
break;
}
/// the anchor point of the car is set right in the center of the plot
/// staying the plot (inert state)
case 5:{
///wait for the time to change the status
break;
}
/// after triggered by case 5
/// exit the plot and reach the side road
case 6:{
/// send continuous signal to the following car to **wait behind**
// if their distance to the *plot* is less than the normal car distance
///begin the curving auto-move process
///begin the auto-rotate process
break;
}
/// after reach the plotting point
/// move straight at the side road
case 7:{
///self-detect process
///change the self-detect process
// change -> back the the original one // keep the distance with the front
///signal to the **possible** car staying in the plot aside the car and prevent them from going out
///begin the straight auto-move process
//change back -> move straight
///end the auto-rotate process
break;
}
/// after reach the boundary of the side road
///move from the side road to the main road
case 8:{
/// send continuous signal to the following car to **wait behind**
// if their distance to the *branch* is less than the normal car distance
break;
}
///after reach the turning point
///move straight on the main road
case 9:{
///self-detect process
//self-detect process for the front car to decide whether to stop
///straight auto-move process
// if the stop signs remains false, do move for constant speed per unit
break;
}
///after having reached the exit
/// relevant functions with the exit of a car
case 10:{
///print_ticket
//...
break;
}
default:{
std::cerr<<"Abnormal State! Please check out for the error"<<std::endl;
}Also, based on this method of dividing cars by status, it makes it easier to avoid safety problems including car crash(unless some careless drivers run into a bug). Warnings are given when a car is entering, turning, queuing, parking, and getting out of a slot. Also to make sure its safety, all the warnings are given one frame in advance. That is pretty enough for an electronic driver. But if you see some graphics overlap, believe me, that is not a car crash. No one gets hurt in this program.
-
the introduction of Bezier curve to smooth the vehicles’ trajectory
Bezier curve is often used in industry to "model smooth curves that can be scaled indefinitely". A Bezier curve is defined by a series of points, the first and last one of which are the two endpoints of the curve. Its parameter equation is
$$ B(t)=\sum_{i=0}^n\dbinom{n}{i}t^i(1-t)^{n-i}P_i, t\in[0, 1] $$ In this project, we defined a structure "corner" with three points (Vec) in it. When the vehicles turn left or right at the crossing or reverse into an empty slot, we view them as moving along the Bezier curve defined by the three points in the corresponding "corner".
Moreover, the length of this curve is impossible to calculate with a formula. Thus, in order to ensure that the vehicles move at a constant velocity, we apply the idea of discretization by dividing it into many parts and making the vehicles move by the sum of some of the parts whose total length equals to the velocity in one time unit.
- Sometimes two cars will overlap, however, this is the less frequent scene.
- Sometimes the
zoomfunction does not behave well, however, the deviation can be neglected.
-
NON OPEN_GL mode
In this mode there will be a brief command line interface for the user to input relevant data, for example:
- (Not realized yet) the number of floors for the parking lot
- the number of cars for the row and the column
- Specially Notified that since the data regarding the identities of each car would be too burdened for the user to input respectively. Therefore, information related to cars would be directly achieved through file "Car.log"
-
OPEN_GL mode
Due to the limitation of OPEN_GL in coping with parameters, our group temporarily decide on fixing the numbers of cars for the row and the column. (However, all the related points are all calculated in respect to the length and width of the whole floor, which means that )
However, the information of each car is still acquired from the "Car.log" file.