Ryan’s Status Report for 4/30

This week, I worked on two things. First, I helped finalize the final presentation and watched other groups’ presentations (which were all great)! Second, and more importantly, I did a lot of power testing for the system. Specifically, I tested the power draw of both sensors, as well as the power draw of the system with different code/states running (including no optimizations, delay statements between loops, and deep sleep). Unfortunately, I ran into a big issue in that the processor was consuming far more power than specified by the datasheet. While the datasheet rated the processor in deep sleep consuming only 10uA of current, the measured system current consumption in deep sleep was consistently 14.6mA, a factor of 1000x higher than expected. This included the PIR sensor consuming around 50uA of current (regardless of state) and the thermal sensor consuming around 5mA of current (regardless of state), so the processor is still consuming much more than we had accounted for. With all this being said, our battery should only last about 82/107 hours required by our use case. This creates a clear risk to our design meeting our use case which I will outline more in the team status report.

Next week, I plan on completing a couple of battery tests to confirm that the battery will not last its full duration. In addition, I will finish out the semester by finalizing our poster, doing some fine-tuning on thresholds of the occupancy algorithm for Weigand Gym, and turning in the final report. I am more or less on schedule — I am adding in some confirmation battery tests to tie a bow on the power testing which would have been nice to have done by now, but I shouldn’t have a problem getting those in for the final report.

Team Status Report for 4/23

From a hardware perspective, we were fortunately able to avoid any design changes, as we were able to integrate the thermal sensor into the design both hardware- and software-wise after many tribulations. We began battery tests and will have results for those tests on Sunday before the final presentation is due. Additionally, we will complete power unit testing with different sections of code on Sunday before the final presentation, and we hope to get a much clearer picture of how closely our design is matching our use case. One big risk is either power or battery testing failing, both of which would indicate that our system consumes more power than expected and we won’t be able to meet our battery life use case. However, should that be the case, we have a couple of risk mitigation plans that we hope will solve the problem. We still haven’t introduced specific optimizations to the code which should significantly reduce power draw, including better use of deep sleep and potentially using a light sleep in the few seconds between the processor taking readings from each sensor. Additionally, we should be able to reduce the amount of readings required to determine an occupancy change without any major sacrifices in accuracy, which would allow us to take less readings per minute and further reduce power draw, while still meeting our use case of accurately updating occupancy status within a minute of it changing.

Ryan’s Status Report for 4/23

I made a bunch of progress this week. Most of my work was put into integrating the thermal sensor into the final design, which ended up being much more painful than anticipated. The one thermal sensor we had was broken and I unfortunately didn’t have any good way of verifying that the sensor worked until the rest of them arrived on Wednesday, so I spent a lot of time early in the week writing and running different segments of code in an attempt to debug things. Fortunately, after getting new thermal sensors, I was able to get the system running on an Arduino Uno pretty quickly, and then after a bit more work I was able to transfer everything over to the ESP system, which is now running a functional occupancy detecting algorithm using both sensors! The final hardware design can be seen below (although the design will be on a smaller breadboard for the final demo).

As a very important note to future teams looking to do something similar, we made the design decision early on to use an ESP8266 dev board with both a processor and a wi-fi chip built in as opposed to using an Arduino with an external wi-fi chip to reduce the amount of hardware, since the ESP can still compile Arduino code. Although this was a good idea in theory, it made things much harder for both myself and Jake, as the Arduino is much more user-friendly than the ESP for software development and has much more existing uses and documentation to learn from. If we were to restart this, we would definitely develop things on an Arduino instead.

After finishing all that up, I then assembled the rest of the hardware nodes to work with Jake to kick off battery testing. While we shouldn’t have definitive results until tomorrow (fingers crossed, because it means the batteries will have lasted at least a day), those results will be in on time for the final presentation. I am also planning on working with Jake tomorrow on unit power testing to further verify that our system is within our power consumption use case requirement. We will be measuring power draw out of different components while running different sections and libraries of code in a further attempt to optimize power, and preliminary results for those should also be done by the final presentation. If all ends well, I will spend the rest of next week hearing other presentations and preparing for our demo. If not, which is probably the more likely scenario, I have a risk mitigation plan which I will detail in the team status report. Currently I am pretty well on schedule to finish everything out, and I am hopeful that will stay the same for the rest of the semester!

Ryan’s Status Report for 4/10

These past two weeks, since I missed a weekly update last week, a lot of work was done. I first identified that our thermal sensor, which had been ordered earlier this semester, can only communicate between I2C and has a specific header that needs purchasing, as well as a logic level converter. I talked to Tamal and made a contingency plan of ordering a breakout cable and level converter needed, with the understanding that the thermal sensor will not be a part of our interim demo.

I then soldered male header rows onto both of the regulator boards and built the hardware for the interim demo. A completed picture of the hardware can be seen below!

The battery runs into a 3.7V to 5V boosting regulator (which doubles as a charging board). That 5V powers both the ESP8266 dev board (which powers the processor and wi-fi module) and the PIR sensor. During the demo, the PIR sensor was taped to the bottom of a table, however the idea is to eventually mount the entire system under a table so it is out of the user’s way. After further testing, I determined that we did not need the 5V to 3.3V buck regulator, since the dev board steps down voltage levels internally.

Finally, we completed our interim demo! I think that it went well overall, and we were able to take a reading from the PIR sensor and send it all the way to a mocked up version of the web app. My major next steps involve integrating the thermal sensor into the rest of the design both hardware- and software-wise, now that the parts have come in, and finally doing some battery testing and work on power saving to round out the end of the semester, and I am currently on schedule to finish that out.

Ryan’s Status Report for 3/26

This week, I mostly focused on the ethics side of the project. This involved participating in a very interesting discussion between many groups about the ethics in both our projects and others, and we got some very interesting feedback that I considered and thought of solutions for. Specifically, two main points of concern were addressed:

  1. Anybody can access the data through the web app, and this data can be used for many purposes besides finding a free seat in the UC. To address this, we are going to restrict web app access to those with Andrew logins. While this may restrict access to a minority of the use case members, as some Chartwells employees use the tables as well and the UC is technically open to all people on the weekdays, we believe that this is a necessary step to secure the safety of the data of the remaining users.
  2. If this system is set up in the UC, people do not have the option of not having their occupancy tracked or opting out. Although this is definitely of concern, there are cameras in the UC that can be used to track someone’s location. More importantly, though, we would intentionally spread flyers notifying people of the way the hardware works and that no personally-identifiable data is being gathered as we advertise the app. We believe that the vast majority of the users, once informed, would not have concerns with the system; conversely, there is no easy solution to implement for the edge case of users that still do have concerns.

Unfortunately, since the rest of the hardware arrived very late in the week and due to some personal issues, I was not able to put forth much work on the project design this week, which has pushed me a bit back on schedule. Since I have a lighter schedule this upcoming week, I am hoping to be able to make up for the lost time. This week, I plan to assemble all of the hardware together, and I intend to at least get started on writing code to initialize all systems and get the sensors talking to the processor, in preparation for the interim demo coming up.

Ryan’s Status Report for 3/19

This week, I finalized ordering the rest of the hardware for the project, including picking switching regulators to supply 5V and 3.3V from our 3.7V battery, and figuring out a charging solution for the battery as well. With this, the hardware should all be ordered and in house next week, and once the last of these components arrive, I am excited to put everything together! In addition, I worked on the ethics assignment and thought about various aspects of the ethicality of our project, and started to look at some of the existing hardware code Jake has written to familiarize myself with it.

Next week, I will be looking forward to some interesting ethics discussions, and am hoping that the rest of the parts will be in so I can assemble everything! Although I am slightly behind schedule, as I would have liked to be writing some code to initialize the sensors by now, I am not worried about getting this done by the interim demo, and hope to have everything up and running by then.

Ryan’s Status Report for 2/26

This week was spent mostly on design review. To start off the week, I helped put together the slides for our design review presentation, and then practiced the slides and eventually gave the presentation in class. I also got to listen to a bunch of awesome design reviews from other teams! I then reached out to some previous capstone students about using a similar battery to ours before placing the order for two batteries, one which we will test with and another (smaller) one for our demo. Finally, I got started on our design report which is due at the end of next week.

I am about on schedule, pending the status of our parts being delivered, as I initially planned on having a full design completed and all parts ordered and in hand by Spring Break. The only hardware that has yet to be ordered is a voltage converter stepping up to 5V and stepping down to 3.3V, however I don’t anticipate choosing one to take that long.

Next week, in addition to getting a voltage converter ordered, I will be spending most of my time writing up the design review report, including incorporating any feedback from the presentation which we may receive next week. After a nice break and when everything has arrived, I’m excited to start wiring everything together and playing with the sensors!

 

Ryan’s Status Report for 2/19

This week, I was able to catch up on some work I was behind on. I was able to create a BOM of all the hardware we are going to need to purchase for the project so far, including doing power consumption analysis of all the hardware to determine the approximate specs of a battery that we would need. It turns out that we are either going to need a pretty big battery or (more likely) we are going to need to be smart about how long we leave our sensors powered to detect occupancy! Finally, I helped work on the design presentation that we will be giving at the beginning of next week.

I am a bit behind from where I’d like to be in that ideally all parts on the hardware BOM would have been ordered by the end of the week, and I’m still waiting on approval from a couple people before I go ahead and place the order. But once that comes through, placing the order shouldn’t take much effort, so I’m not worried about this being a long-term setback.

Next week, I plan to finalize a battery to purchase and place an order for the rest of the hardware. While I wait for parts to arrive, I will work on writing up the design review report and incorporating any feedback that we get from the presentation. Finally, I will help finish up the rest of our design proposal slides, and am looking forward to seeing the presentations of other groups!

Team Status Report for 2/12

We had our project proposal on Wednesday, which Jake presented for. Beyond working on the presentation, we also submitted order requests for hardware parts; 2 potential Esp8266s, and a D6T thermal sensor. In addition, we looked into a bunch of different sensor options, and also looked into solar panels as an alternative means of battery charging. Finally, we set up the software portion, including starting up a Github repo and requesting AWS services.

Right now, the main risk we are facing is not being able to detect people with our combination of sensors. Although we are planning on only using a button to indicate occupancy for MVP which is not at risk of failing, we understand that this isn’t an ideal solution for our use case, and that we’d want to be able to update occupancy status without relying on a user to remember to press a button when they sit down and get up to leave. To try to mitigate this risk, we are already ordering sensors to try to give us ample time to set up and test them. Another risk we are facing is that we may not be able to meet the 55-hour battery requirement that we are setting. We would like for the battery to last 55 hours so that it can operate from 9-8pm Monday through Friday (which we identified to be the peak hours on the 2nd floor of the UC) and then charge over the weekend, but we realize that finding a battery with that large of a capacity and then managing it strategically enough to last a week is a tall task. We have looked into alternative methods of charging, such as solar power, although we are skeptical of how practical these methods may be, so we might have to reframe and change our use case to accommodate this.

Since we are fresh off our project proposal and haven’t done too much deeper design thought and testing yet, we have not yet made any major changes to the design of the system or the schedule. But with the design review on the horizon, expect changes to come!

One exciting point of progress has been integrating a PIR sensor with our Arduino! Although we haven’t done too much work with using the sensor to detect occupancy yet, it is definitely exciting to see everything start to come together.

Angela’s Status Report for 2/12

This week I worked on setting up a Github and buying EC2 instances for AWS. We also had our project proposal presentations which I worked on as well.  My current progress is on schedule, as we won’t have to focus on the front end for a while. For the next week, I hope to finish hashing out most of the backend and figuring out the pipeline.