Using a Raspberry Pi 4, a PiTFT Display, and Data
It is often difficult for students to find available places to study on large college campuses. In this article, we describe a method by which places to study at Cornell University can be located. We used Internet traffic data collected from wireless access points as a proxy for congestion, and for finding the least congested study spaces and best routes to them.
At most universities, we typically find students texting, calling, or checking upcoming class schedules on campus with their smartphones, which are connected to the campus Internet. Of course, they may also carry a laptop, tablet, and other electronic equipment. When these devices are connected to the Internet through Wireless Access Points (WAPs), the resulting traffic data, when drilled down to the physical location level, can serve as a proxy for the level of campus congestion across campus. Our project, called Campus Congestion, is an embedded-system project that shows a graphical representation of the level of congestion in common areas in Cornell University’s Engineering Quad. It is used to help students find available places to study.
We had four project objectives:
- Access the data from the different APs that are present in a room.
- •Create a graphical representation over a map of the level of campus congestion in common areas.
- • Offer a ranked list of study spaces, prioritizing the ones with the least amount of campus congestion, and offer routes to get there.
- • Allow the user to control the progression through the menus and select options with either mouse clicks on a computer monitor, or by “remote control” buttons on a PiTFT display screen connected to a Raspberry Pi 4.
This project utilizes the public Multi Router Traffic Grapher (MRTG) website, provided by Cornell’s IT department. An example of MRTG graph data is shown in Figure 1. By leveraging the network traffic data of the Local Area Network’s (LAN) switch ports, we are able to look under the hood at the network that services the wireless access on Cornell’s campus. With the MRTG data, our project is able to take the incoming and outgoing traffic data from multiple Access Points (APs), consolidate for total traffic categorized in a given room, and create a graphical representation merged with a map of the Engineering Quad of Cornell’s campus for Red, Yellow, and Green levels of campus congestion (explained later). The project also creates a list of recommended study spaces in the Engineering buildings, ranked from the least to the greatest amount of campus congestion. It can also recommend “routes” through campus that consider the congestion levels of the intervening areas.
Phase 1—Data Acquisition: This project has multiple moving parts. There is the data collection portion, which necessitates a way to pull the website traffic data from the individual WAPs that are scattered through campus, in rooms, and in hallways. At first, we wanted to get a representation of this kind of network data by pinging the individual APs and comparing the ping latency against a calibrated threshold, for an idea of how saturated traffic the AP was. However, we soon found that due to the structure of the campus Wi-Fi network, this nature of sleuthing was prohibitively difficult.
The campus network is organized into clusters called “nodes,” which are intra-building uplinks within each building’s network room. Within each of the nine nodes (which range in geographical location from Clara Dickson Hall, to Goldwin Smith Hall, to Faris), individual buildings such as Phillips or Rhodes are serviced.
In the end, we utilized the MRTG website and information provided to us by Cornell IT. In this way, we were able to find the actual incoming and outgoing data traffic (in kilobytes per second or megabytes per second) in real time from individual access points. Thus, we were able to find the actual network traffic data to correlate to the level of campus congestion in different areas of campus. We imported this data into a pandas DataFrame using a web scraper, and collated it by physical location.
To get network traffic data in specific places, we first gathered the physical location of each AP with its name. The number of APs varied, depending on the size of the space. For example, the Duffield Atrium—the main area of the Cornell Engineering building—had four access points. Since the APs are sometimes named opaquely, we tried to find the pattern in naming such as RHODES-30042-3-AP, that is, an AP in a hallway on the third floor of Rhodes. The Rhodes Hallway access point is shown in Figure 2.
Phase 2—Data Processing: The next part of the project was smooth, because we were able to create a multiple-menu script in Python using Pygame. The script first imports the data from the web scraper. The scraper gathers the traffic data from 17 MRTG websites to cover the ECE lounge, Duffield atrium, Upson lounges, CIS lounge, and Rhodes lounges. From the website, it gets specific information, including system and port names, current and daily average network traffic data, and daily graphs. (More information is explained in the “Web Scraper” section of this article.) Then, it determines the level of campus congestion and draws circles on a map of the Rhodes-Phillips-Duffield-Upson section of the Engineering Quad as a visual representation of the congestion data.
We were able to determine threshold levels by fieldwork and observation, correlating the number of people in individual areas and the amount of Internet traffic through the APs. Utilizing this data, we were also able to successfully create a ranked list of recommended study spaces on campus and recommended a “route” to get there based on the congestion level in the intervening areas, which we programmed using a route flowchart.
Phase 3—User Interface Decisions: We tried to implement a smart mirror (a two-way mirror with an electronic display behind the glass.) However, during the testing process, we found out that this would not have been practical within the constraints, nor necessary for the objective of the project. Therefore, we decided not to use a smart mirror. (There is more information about this design decision in the “Testing” section of this article.)
We briefly considered somehow uploading our map and associated work to a web server, so that any student on the RedRover Wi-Fi would be able to access the data and congestion map. We researched various ways to do this, including setting up an Apache web server on Raspberry Pi to host a website. However, we ran into difficulties doing this, and in the interest of time eventually decided not to utilize web servers. (See the “Testing” section for more information about the testing that occurred before making this design decision.)
The current project design utilizes a PiTFT display and monitor-based user interface. The mouse allows the user to physically click on “buttons” on the monitor to select options on a menu, and offers buttons on the PiTFT to do the same. Six buttons on the monitor allow for this functionality (Table 1). The buttons on the PiTFT are shown in Figure 3.
For example, in the Congestion Map menu, the first button (27) would correspond to Phillips, the second (23) to Duffield, the third (22) to Upson, and the last (17) to Rhodes on the campus map. Buttons 27, 23, 22, and 17 are coordinated with the options from top to bottom on the screen.
Clicking on the buttons on the monitor with the mouse also allows the user to select options. Buttons are denoted by white font text and light blue outlines. There are buttons on the main menu, Congestion Map, Study Space list, and Route Recommendation.
Phase 4—Route Recommendation Logic: For route recommendation, our plan was to have a finite state machine that would be reasonable, given the information about campus congestion available. As noted earlier, we correlated the network traffic data at the AP level with the amount of campus congestion, by physically going into the study space or room and noting both the amount of congestion and the quantified traffic data.
We defined three levels of campus congestion: Green, Yellow, and Red. Green means it is easy to find a table or place to sit. Yellow means you need to search for a table, but there are still a few immediately available. Red indicates that there are no tables or spots available in the space. We set the congestion level based on the current network traffic rate: Green when less than 100Mbps, Yellow when less than 200Mbps, and Red when more than 200Mbps. These congestion level thresholds were set by running an experiment in which we physically examined the congestion in each study space every four hours and aligned it with the traffic data available. More information about how we implemented this can be found under “Route Calculation Logic.” After establishing the overall project design, we proceeded to construct a software design structure, which is illustrated in Figure 4 as a flowchart.
We designed a web scraper that gets daily incoming and outgoing data traffic, port name, hall name, and graph image from the mrtg.cit.cornell.edu. Since Rhodes is the place that supports the networks in all engineering buildings, the information was gathered from traffic data of LANs via Rhodes Node. The program returns the information in a pandas DataFrame and filters to get certain information. Multiple helper functions convert data type into dictionary type, list of graphs, list of hall names, and images downloaded in an img directory. Whenever the main function runs, the whole set of congestion data is updated from the Cornell CIT website.
VISUAL REPRESENTATION AND REMOTE CONTROL
The display file, mirror_display.py, uses data from the web scraper and displays the map, charts, and graphs to the monitor controlled by PiTFT. It sets up Pygame to visualize and interact on the monitor with a mouse click, and GPIO to get inputs from the PiTFT and external buttons. It contains five different menus or displays.
The first menu is the main menu that shows a real-time clock and two options to choose from—showing a congestion map or a list of study spaces. If the Congestion Map button is clicked on (or selected via button), the display moves to the second menu, which shows the map of the halls in the Engineering building, with green, yellow, and red colored circles, each of which indicates the level of congestion in the specific hall. If one of the buttons in those circles is selected, the display moves to show the dashboard menu that contains the MRTG graph, study space name, and network traffic rate of each access point in the study space. Thus, the user can get more specific information by examining the dashboard.
If the “study space” option in the main menu is clicked on, the four study spaces with the lowest traffic rates are shown with the color level of congestion. As explained in the “User Interface Decision” section, the user can also select the four best options on each display with four buttons on PiTFT in order. The user can go back to the main menu or quit the system with two external buttons. If the study space is clicked on or selected in the list, the display changes to the route recommendation for the user to get to the chosen study space through the lowest possible congestion in the building. The specific algorithm is shown in the next section, “Route Calculation Logic.”
ROUTE CALCULATION LOGIC
Before planning out the logic flow, we first considered the entrance locations of the halls. Assuming the user is coming from the dorm or the central campus, if the study space destination is Duffield or Phillips, then we know the user can go straight to the hall through its entrance. (We did not consider Rhodes as “next to an entrance” as part of this assumption.)
If the user is not coming from outside the buildings, we then started considering the congestion in the building. For example, if all the buildings have high congestion levels—meaning the building is full of crowds or has no study space—then the system recommends using the entrance of each hall instead of going through the crowds inside of the Engineering buildings. If not all the buildings are crowded and the user wants to go to either Upson or Rhodes, where it can be routed through other halls, then we consider the congestion in Duffield, Phillips, and Upson, and recommend the route to the Upson or Rhodes based on its congestion level. The flowchart explaining the logic in detail is given in Figure 5.
Testing Smart Mirror Feasibility:
For the Smart Mirror hardware model, we received the model that was designed for the Magic Selfie Mirror project  in the Fall of 2017. The model has 22 IR sensors with four 8-3 encoders to build two 16-4 encoders that output the coordinate on the mirror. Before testing the mirror, we realized that some wires were disconnected from the soldering and started to fall out of the connection. This happened because the stripped wires were flexible, but too thin, and had an unstable connection to the board. After investigating the board and wiring, we soldered the disconnected wires (Power, GND, and Sensor Output) to the board and used a Raspberry Pi and breadboard to see if the sensors were working.
To test the basic functionality, the GPIO pins were used, while avoiding the special function pins such as the I2C, SPI, and UART pins. When we tested the sensors, we found that some of them were not working or were not sensitive enough to detect the motion. The output coordinate did not change as we moved our hand’s position on the mirror. Also, the coordinate in the same position was outputted differently over time. Moreover, the short-length connections of wires and boards blocked the monitor, and the strong reflection of the mirror made it hard to see the result on the monitor through the mirror.
Due to the non-robustness of the connection and sensitivity of the sensor and unclear visualization, we decided not to use a smart mirror as the user interface. We concluded that the mirror was not a good visualization method, and sought other methods to visualize and control our system. Instead, we utilized PiTFT as a remote control for our system.
Testing Web-server Feasibility
When it became clear that utilizing the smart mirror would be unrealistic, given the constraints at the time, we switched gears to examine other avenues of the user interface. One of the things we considered was somehow hosting the PyGame window on a web server, accessible to anyone on the RedRover network by typing in the IP address of the hosting Raspberry Pi in a web browser. However, complications arose.
As shown in Figure 6, when the mirror_display.py program starts to run, the main menu is displayed with a current time in the form of an hour, minute and second, which is updated by each second. It also shows two option choices—a congestion map, and study spaces—that lead to the next display.
If the congestion map text box is clicked on, or the first button in the PiTFT is pushed, the campus map with colored circles showing the congestion level is successfully shown on the monitor (Figure 7). The color of the circles is updated every 5 minutes by loading the congestion data from the CIT website. The user can choose the main menu by clicking on or pushing the fifth button on PiTFT to go back to the main menu.
Clicking on the textbox of the hall on a map (shown in Figure 7) or pushing one of four buttons on PiTFT will lead the user to the network traffic dashboard of the chosen hall. The order of the buttons is the same as the order of the halls from the top of the map: Phillips (#1), Duffield (#2), Upson (#3) and Rhodes (#4). The dashboard contains each access point’s daily MRTG graph with its image name, the name of the study space, and the current total traffic rate (in Mbps) of the study space. Each hall has a different number of study spaces with a number of access points. For example, Phillips Hall has only one access point in the ECE lounge, but Rhodes Hall has study spaces on multiple floors. Also, the CIS lounge in Rhodes has several access points. The dashboards of all four halls are shown in Figure 8.
On the bottom right of the graph, the red dot indicates the current network traffic of each access point. It is observed that the numerical traffic rate of the third floor of Rhodes is much higher than the reading on the graph. It is intentionally coded to get a high traffic rate in Rhodes to show the diverse colors of the circles in the congestion map, because the demo was done at night when the congestion level is low in all the halls.
Figure 9 is the display of the study space list, when the second option has been chosen in the main menu. The list of four study spaces is shown successfully, with the lowest congestion in the building. The color level is shown in the text box. In the figure, the current levels of congestion are the same in all four buildings. Hence, in this case, the list is sorted in alphabetical order.
Recommended list of study spaces with congestion levels.
Figure 10 shows the display of the recommended route, with the black line connected based on the route calculation logic. This is shown when the study space is chosen to be the destination on the study space list. The red text box indicates the destination, and the blue text box indicates the hall to go through. Each screen capture shows the route to Phillips and Rhodes Halls. Based on the map, we considered two entrances in the engineering quad—one in Phillips and another in Duffield. When the destination is set to Phillips Hall, the route uses the entrance in Phillips. The route recommendation also works successfully by indicating use of the entrance for Duffield and use of the Duffield atrium and Upson to get to Rhodes Hall.
The system successfully goes to the main menu, and quits when the fifth and sixth buttons on the PiTFT are clicked on correspondingly. The update of the congestion data by 5 minutes was checked with the quitting time of 20 minutes.
CONCLUSION AND FUTURE WORK
Other than a sticky button on the PiTFT that required extra presses to register, there were no big difficulties, and we successfully achieved all our project objectives, as outlined at the beginning of the project. A demonstration video of the project is available on YouTube , and code for the project is available on GitHub .
In the future, we would like to calibrate congestion level thresholds by examining the congestion for a longer period of time. This would allow us to have more accurate thresholds for traffic, and potentially to calibrate the thresholds to the specific study spaces, since each study space has different square footage and thus a different “maximum capacity.”
Finally, we would like to expand this functionality to the entire campus, including different college buildings, such as the College of Arts & Sciences and the College of Human Ecology. This would require more fieldwork such as finding access points in each building and aligning them with their opaque names in MRTG, as well as an extended logic flow for recommended route calculation. For the remote controller, we will implement a zoom-in/out control feature and a wireless communication chip. The increased number of study spaces will exceed the number of buttons we can use with Raspberry Pi’s4 GPIO pins. It would be better to use the touch screen by zooming in and out of the map instead of using the buttons and controlling it wirelessly.
 Magic Selfie Mirror Project
 Demonstration video of the Campus Congestion project
 GitHub repository with project code
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • JUNE 2023 #395 – Get a PDF of the issueSponsor this Article
Minjung Kwon is a senior at Cornell University, majoring in Electrical & Computer Engineering and minoring in Computer Science. Minjung is interested in software development and low-level security and can be reached at email@example.com.
Esther In is a 2022 graduate from Cornell University. She also majored in ECE and minored in CS, and went on to work at JHU/APL on spacecraft power electronics. She can be reached at firstname.lastname@example.org.