Posted on

Team Status Report 2/26

This week, we presented our design review and are currently awaiting feedback. We did not make any changes to the system, only more detailed analyses of the frontend and hardware.

Through our preparation for the design review and report, we did not discover any new significant risks yet. Overall, we are just trying to properly manage costs and size for the hardware in order to support the 55 hour battery life as well as making sure software structure can hold up to the number of tables it has to support. Currently, our biggest power consumption device is the PIR sensor, which will, after 55 hrs, consume 85% of the available power consumption. As a contingency plan in case the battery does not last, we are planning to lower the active time of the PIR sensor, such that the thermal sensor does the initial occupancy sensing and the PIR sensor is then used to confirm occupancy.

Posted on

Jake’s Status Report for 2/26

This week I developed more code to get the esp8266 to connect over wifi. The big question at the moment is what “.ino” authentication library to go with for optimal power savings. Theres several options that are available and I have working, the difficulty however is that to truly determine which one is best for our low power solution we have to run them all on the device and measure power draw.

So far I am on schedule as this week we implemented a working embedded device to software interface that communicated with the cloud. This upcoming week + spring break week I plan to not only conduct the previously mentioned power draw experiments but also to establish an AWS rule (essentially the pipeline that directs incoming data) to push inbound data to an AWS db.

Posted on

Angela’s Status Report 2/26

The beginning of this week was mostly spent on the design review and the design review report. The AWS credits were not rewarded until later in the week, so I used some time to review the hardware aspects of the project, since I am more software focused. I also made very minor changes to the first panel of the UI. This was just to show the baseline statistics of the area of the UC that’s displayed.

Now that I have access to the AWS credits, I should be able to start connecting a Django app to a MySQL database. I also want to finalize the UI and study more on how to make the UI more aesthetically pleasing and accessible. Currently, my progress is on schedule, as I have plenty of time to develop this UI. I hope to show a more refined UI as well as show that I have done AWS work.

Posted on

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!

 

Posted on

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!

Posted on

Team Status Report 2/19

This week we did a lot of prep work for getting started on building. We were able to get some power consumption analysis going as well as further part analysis.  For AWS, we were able to get AWS IOT working and connecting our esp8266 to AWS core. We also spent a good portion of the week planning our design presentation. In terms of front end, we got a simple UI going that displays needed information on the occupancy status in the UC. We have some ongoing conversations for storing information from our sensors and how we should identify each table, but that is not a significant risk.

The biggest risk so far is still regarding the sensors. However, after doing some power consumption analyses, we discovered that we would have to do a bit more design changes to the hardware in order to account for the battery lasting 55 hours. This didn’t necessarily change the costs, but we did have a more in depth conversation of what parts we actually need to support this current load. We also discovered that there need not be a big change on our existing schedule, and we are moving forward at a good pace.

Posted on

Jake’s Status Report 2/21

This week I developed the preliminary code to get the esp8266 to connect to wifi as well as the code to alter esp8266’s mac address as needed. I registered one esp8266 with cmu-device and received a confirmed connection. I then connected our esp8266 to AWS-Core.

Initial Connection of esp8266 to CMI-DEVICE

So far I am ahead of schedule as this week we have the potential to implement a working embedded device to software interface with a deployed sensor communicating to our web server.

In terms of deliverables for the coming week I would like to integrate the AWS-Core page with our deployed AWS website server. This is slightly complicated because I don’t believe we have a deployed website quite yet.

Posted on

Angela’s Status Report 2/19

This week, I was unable to do much as I was lacking AWS access. However, I was able to more carefully plan out the front end as well as design a rough UI on Figma for our web application.

I think a big problem with designing the UI was knowing what information we want to portray to the user and how much information we can gather from the sensors.

Posted on

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.

Posted on

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.