Skip to content
Snippets Groups Projects
Commit 9ad74158 authored by fmoy3's avatar fmoy3
Browse files

Notebook update

parent ea5692e6
No related branches found
No related tags found
No related merge requests found
...@@ -13,6 +13,7 @@ ...@@ -13,6 +13,7 @@
- [2022-11-11: Device Enclosure Preparation with Machine Shop](README.md#2022-11-11-device-enclosure-preparation-with-machine-shop) - [2022-11-11: Device Enclosure Preparation with Machine Shop](README.md#2022-11-11-device-enclosure-preparation-with-machine-shop)
- [2022-11-17: Tinkering with the Occupancy Estimation Algorithm](README.md#2022-11-17-tinkering-with-the-occupancy-estimation-algorithm) - [2022-11-17: Tinkering with the Occupancy Estimation Algorithm](README.md#2022-11-17-tinkering-with-the-occupancy-estimation-algorithm)
- [2022-11-25: Fall Break](README.md#2022-11-25-fall-break) - [2022-11-25: Fall Break](README.md#2022-11-25-fall-break)
- [2022-12-02: The Occupancy Contribution/Probability Model](README.md#2022-12-02-the-occupancy-contributionprobability-model)
## 2022-09-13: Post-Meeting Notes ## 2022-09-13: Post-Meeting Notes
We just talked with our mentor TA about our initial block diagram, high-level and subsystem requirements, and about some of the parts that we are planning on using for the project. She had some great suggestions for us that we think would benefit our project, especially since she had a very similar project when she took the course. \ We just talked with our mentor TA about our initial block diagram, high-level and subsystem requirements, and about some of the parts that we are planning on using for the project. She had some great suggestions for us that we think would benefit our project, especially since she had a very similar project when she took the course. \
...@@ -160,3 +161,8 @@ Because of this and the possible overcounting, I decided to rethink what exactly ...@@ -160,3 +161,8 @@ Because of this and the possible overcounting, I decided to rethink what exactly
## 2022-11-25: Fall Break ## 2022-11-25: Fall Break
This week was Fall Break, and since I was more or less done with building the physical MOM device and developing the microcontroller code for it, I was only performing the final verifications and recording our results. All of the requirements for the subsystems I was in charge of have been verified, and so was the high-level requirement of the device running for at least one hour while on battery power. However, because of the scarcity of sent probe requests by devices already connected to the internet, the high-level requirement of estimating sector occupancy with at least 80% accuracy is becoming increasingly more difficult through just measuring probe requests. If we used a much more intrusive method, this would not be too difficult. However, ethical reasons deter the usage of these intrusive methods. This week was Fall Break, and since I was more or less done with building the physical MOM device and developing the microcontroller code for it, I was only performing the final verifications and recording our results. All of the requirements for the subsystems I was in charge of have been verified, and so was the high-level requirement of the device running for at least one hour while on battery power. However, because of the scarcity of sent probe requests by devices already connected to the internet, the high-level requirement of estimating sector occupancy with at least 80% accuracy is becoming increasingly more difficult through just measuring probe requests. If we used a much more intrusive method, this would not be too difficult. However, ethical reasons deter the usage of these intrusive methods.
## 2022-12-02: The Occupancy Contribution/Probability Model
We noticed that after monitoring a space for a long time, the MOM device eventually reads an explosive increase in detected devices when no new people enter the room, which in turn increases the estimated occupancy. To mitigate this, we instead calculate occupancy based off of the probability that the detected device represents an entire person. With this new probability model, we try to take into account factors such as the number of devices per person, the dimensions of the environment where the device is deployed, and extraneous traffic from devices from other areas (such as other floors and other rooms). The probability primarily focuses on the signal strength and timestamps of each captured probe request, where the probability decays over time if the device has not been seen for a while since the previous timestamp. We also tried to implement a way to detect explosive increases in detected devices within a short period of time. While we were able to detect and mitigate these, the algorithm we use would ignore explosive increases if it actually happened. For example, if a class is starting in a classroom, and many students enter the room at the same time, the algorithm currently thinks that mitigation actions are required even though the increase is the ground truth.
In general, the mitigation would not really matter too much for the areas where we would be primarily deploying MOM devices, such as Grainger Library and the ECEB Atrium, since those are large, open spaces with lots of movementand traffic flow. When we tested this algorithm in the Senior Design Lab, we found that it works relatively well. It would be rare to see explosive increases in occupancy in a short period in those spaces. However, the shortcoming of this mitigation approach is losing the accuracy in smaller rooms. Given more time to fine-tune the mitigation algorithm, I believe that we would be able to find an optimal way to identify when mitigation actions should be taken based on these explosive increases.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment