MCD4540 Engineering Smart Systems
Project A: Traffic Light
1 Introduction
“Smart systems” are critical to the future of engineering, as they address economic, environmental, and societal issues. They are utilised across many industries, including energy supply, healthcare, agriculture, manufacturing, security, entertainment, and logistics.
Common examples of smart systems are automatic lighting and climate control in buildings, responsive traffic light controllers, liquid level monitoring in agricultural and industrial settings, intruder alarm systems, driver assistance systems in automotive vehicles, and personal healthcare devices.
In smart systems, sensors and timers are often used to detect certain events. Pre-programmed software is then used to perform. analysis. This analysis can be used to make decisions and perform. actions when combined with historical data.
In this project, you will work with your team to apply your software, electrical, electronic and mechatronics engineering knowledge learned throughout MCD4540 to build a responsive traffic control system. This type of traffic control system will control vehicular and pedestrian traffic and is similar to those found at road intersections and pedestrian crossings to help control and manage traffic flow. These systems can be activated based on timing devices, the detection of vehicles, or the press of a button. Traffic control systems are also used in other contexts such as at airports, in railway signalling, on waterways, or at race courses.
2 Project requirements overview
Your team has been asked to design, build, and demonstrate a traffic control system in this project. Your system will consist of five blocks. The client has broken down each block into a group of required features. These make up the “minimal viable product” - this is an early version of a design that helps to validate the idea. Your team must implement these features. Most blocks also have a group of general features, which your team may choose from for the final submission.
The project will be graded out of 266 points, with your final individual score scaled to 20% of your total mark for MCD4540. The points obtained from implementing the minimum viable product (MVP) do not add to 250 points, so you must attempt some additional features from the general group to reach this figure. If you do not implement some required features, or if you do not attempt to integrate all software and electrical functionality into a single system, your maximum score for the project will be capped at less than 250.
2.1.1 Hardware requirements
You are permitted to use any and all of the hardware components provided in all of your team’s supplied kits (i.e. all 5), plus single core wire and additional breadboards. However, you may use only ONE Arduino to attain points for an integrated system. You may not use any other hardware components.
2.1.2 Software requirements
You may develop your software in any IDE; however, support will only be provided by demonstrators in VSCode. You may only use the following packages within Python 3.10:
● Pymata4
● Time
● Math
● Matplotlib
● The MCD4540 helper package - MonashUE1013
The following packages are permitted, but demonstrators will not provide support:
● NumPy
● CSV
● Random
All other packages are not permitted, and their use will result in a points deduction.
You are also not allowed to use classes in your implementation.
3 System specifications and overview
Your task is to design a traffic control system for a 1-way road that has a pedestrian crossing and car park. The vehicle (road) traffic, the pedestrian traffic, and the car park traffic must all be controlled via sets of traffic lights. The pedestrian lights and the car park lights both have red and green lights, and the vehicular traffic lights have red, amber (yellow), and green lights. The specifications below describe the required system behaviour.
Figure I: Model Road, showing all traffic lights and boom gate
Your prototype system will detect the presence of vehicles using an ultrasonic sensor, and will detect the presence of pedestrians using physical push buttons. You may choose to include additional sensors in your system design, such as a light-dependent resistor (LDR).
In this document, the lights to control the vehicular traffic will be referred to as vehicle traffic lights, the lights to control the pedestrian traffic will be referred to as pedestrian traffic lights, and the lights to control vehicle traffic into the car park will be referred to as car park traffic lights.
3.1 System overview
The traffic control system should have three (3) modes, which should be controlled by the system menu.
● “traffic operation”
● “updating system settings”
● “observing important information via graphs, the console, and a seven segment display.”
Regular input monitoring is required to ensure that traffic lights change according to the current traffic. Sequences of actions are taken depending on if a vehicle or pedestrian is detected. The table below provides a summary of the events and required actions by the traffic control system.
|
Event
|
Vehicle traffic light
|
Pedestrian traffic light
|
Car Park light/Boom Gate
|
|
Initial state
|
Red
|
Green
|
Red/Down
|
|
Vehicle detected (traffic light red, pedestrian light green)
|
1s after pedestrian light turns red: turns green for 10s, then turns yellow for 3s, then turns red
|
1s after vehicle detected: turns flashing red for 3s, then turns red
3s after traffic vehicle light turns red: turns green
|
1s after pedestrian light turns red, boom gate motor turns for 3 seconds to open the boom gate. Once boom gate is open, car park light turns green.
After vehicle traffic light turns red, car park light turns red and boom gate motor turns in the opposite direction for 3 seconds to close the boom gate..
|
|
Pedestrian button pressed (vehicle traffic light green, pedestrian light red)
|
1s after button press: turns yellow for 3s, then turns red
|
3s after vehicle traffic light turns red and/or car park boom gate is lowered: turns green
|
1s after button press, car park light turns red and boom gate motor turns for 3 seconds to lower the boom gate (only if the gate was not already lowered).
|
We have divided the traffic control system’s functionality into five key sections called “blocks”. Information is shared between the blocks to form. a cohesive system. The blocks are:
● Block 1: Polling Loop
● Block 2: System Menu & Data
● Block 3: Inputs
● Block 4: Outputs
● Block 5: Watchdog Reset (Failure Alert System)
The “System Menu & Data” block (Block 2) links the entire system together. It allows the user to switch between the three (3) required modes: traffic operation, system settings and data observation. In addition, this block directly provides for the system settings to be modified by entering the correct personal identification number (PIN). If the PIN is entered incorrectly multiple times in a row, the user will be locked out of the system settings.
The “data observation mode” is also accessed from Block 2. It processes the data stored by the polling loop to provide user-relevant human outputs. These can be supplied on a seven-segment display, console “print” statements, and as graphs of key variables.
The “polling loop” block (Block 1) controls the fundamental traffic control operation mode. It contains the functions of the “inputs”, “outputs”, and “watchdog reset” blocks to manage all physical (real world) signals interacting within the system. The input block (Block 3) monitors the presence of vehicles and pedestrians at an appropriate polling rate. The output block (Block 4) processes this reading and changes the traffic lights accordingly. It also issues any alerts or alarms.
Finally, the watchdog reset block (Block 5) enables the traffic control system to safely perform. a system reset in case of a computer failure. A watchdog function is used to monitor for system failure and initialise a reset of the system in the event the keep-alive signal goes undetected by the system for an extended period of time.
The minimum viable product requires the integration of Blocks 1 and 2, with additional points available for integration with the remaining blocks. You should discuss the necessary functionality and information flows between each block with your manager.
4 Deliverables
Before authorising the final project, your manager needs to see several intermediate design stages: the initial design and two prototypes of the minimum viable product. You will complete these in the form. of several milestones during the semester, before demonstrating the final prototype and answering questions related to its design and operation in week 12. Please be mindful that the milestones do not directly correspond to the blocks; a range of functionality is required for each milestone.
There are five project milestones:
1. Delivery of pseudo-code for software minimum viable product
2. Delivery of software minimum viable product
3. Delivery of complete minimum viable product (electrical and software)
4. Full system prototype demonstration and viva (oral interview)
5. Video presentation on project extensions: reflection, machine learning & data ethics
For more detailed information on the submission of each milestone, please refer to the project guide and submission boxes on Moodle. Please see below for detailed information on each milestone's required and general features.
For Milestones 2, 3, and 4, your prototype must be demonstrated in person during your lab session to achieve the maximum points available (100%). However, suppose some part (or whole) of your prototype is not functional on the day. In this case, you may ask for a video your team submitted as part of your milestone on Moodle to be marked instead for 66% of the points available. If you have not submitted a video, your team may explain how your system should work for 33% of the available points.
4.1 Milestones 1 and 2
The first milestone is the initial design consisting of the pseudo-code for the software minimum viable product, as defined in 4.1.1, 4.1.2 and 4.1.3. You will receive feedback from your manager regarding the feasibility of your design. Please refer to the project guide for more details on how to write pseudo code.
The second milestone is the implementation of this software minimum viable product, based on the pseudo-code submitted in Milestone 1. The minimum viable product requires implementing required features from the menu and data blocks (1 & 2) and integrating the two block’s functions. At this stage, the system menu should include the traffic operation polling loop alongside the system settings and graphing functionality.
4.1.1 Block 1 - Polling Loop
The traffic operation polling loop should include function calls to the initial hardware features from your system’s input and output blocks. You do not need to write any code for these functions; they can return a print statement or null. Refer to section 4.2 for more details about the required input/output features.
|
Category
|
Description
|
SE/EE
|
Points
|
|
System
|
The traffic operation mode consists of a polling loop.
|
SE
|
5
|
|
System
|
The time to complete one ‘traffic operation mode’ polling loop cycle is measured and printed to the console.
|
SE
|
3
|
|
System
|
The time to complete one cycle of the traffic operation mode is between 1 and 5 seconds.
|
SE
|
2
|
|
System
|
The polling loop has functions (returning null or a print statement) for each sensor or output type identified in the input (3) and output (4) blocks. Refer to section 4.2 for more details about these features.
|
SE
|
3
|
|
System
|
A function, called in the polling loop, (a) generates (pseudo)random or (b) looks up semi-random (human-generated) numbers for use in graphing and console outputs.
|
SE
|
2
|
|
|
Block 1: Total Available Points
|
|
15
|
4.1.2 Block 2 - System Menu & Data
The system should boot into the menu. It is up to your team how you wish to re-enter the menu system once you leave it. Restarting the code to return to the system menu is not adequate. Your system must also be able to run on any computer - i.e. not be operating system dependent.
You can select any information to present to the user in the data block. However, you should be able to justify your choices. The minimum requirement is to use a graph to display the last 20 seconds of distance measurements.
|
Category
|
Description
|
SE/EE
|
Points
|
|
System
|
The system menu allows users to select between traffic operation, graphing, and system settings.
|
SE
|
5
|
|
Settings
|
The system settings require the correct pin from the user before viewing or updating the system parameters.
|
SE
|
3
|
|
Settings
|
New user-modified parameters are displayed, stored and used for future operations.
|
SE
|
5
|
|
Settings
|
The user is denied access to modifiable parameters upon entering an incorrect PIN. The user is informed that the PIN is incorrect.
|
SE
|
3
|
|
Graphing
|
The system generates a nicely formatted graph of the distance for the last 20s, using live values from an integrated polling loop.
|
SE
|
4
|
|
|
Block 2: Total Available Points
|
|
20
|
|
Integration
|
Block 1 and 2 operate as a single program from one Arduino
|
|
5
|
|
|
Integration Points Total for Blocks 1 and 2
|
|
5
|
4.1.3 Milestone 2 - Deductions
Console “print” statements are used to present all essential information to the user. Prints are formatted in a manner that makes the meaning of each statement obvious to the user. Statements are generated at a useful and comfortable rate for the user to read. Points will be deducted if the console print statements are insufficient. Similarly, it is important to have appropriately formatted graphs to improve readability. Additional deductions based on the good coding/circuit layout practice requirements (4.6) also apply to this submission.
|
Category
|
Description
|
SE/EE
|
Deduction
|
|
Console
|
The console print statements contain insufficient information, are poorly formatted, or are at an inappropriate rate.
|
SE
|
-2 (each)
|
|
System
|
The code cannot return to the main menu from somewhere in the polling loop.
|
SE
|
-3
|
|
System
|
Code ‘crashes’ - does not exit cleanly or exits with an error message.
|
SE
|
-2
|
|
Graphing
|
The graph does not have appropriate axes, titles, and formatting.
|
SE
|
-1 (each)
|