Category: Group

Earlier in the week, our team worked together to plan our slides for the final presentation.

This included adding in some more test metrics that related back to our design and use case requirements, filming demos of subcomponents working together, and explaining what we had accomplished so far and what we still need to work on by the final demo. As a team, we will be spending the rest of the week on integration, final poster, final demo preparation/video, and the final report as well as further testing of the full pipeline as we keep integrating components.

One of the biggest risks we are facing is the delivery of our PCBs. The PCBs have been designed in a way that allows us to mount all of our circuit components, our sensors, our display, and our battery pack into a finished product, and if these PCBs do not come in time, we will need to find another way to accomplish this goal. Our current backup plan is to utilize the larger protoboards that Quinn has ordered for us as our method of printing the PCBs at Techspark led to some issues when it actually came to soldering the components on.

While our unit tests had to do with testing the pathfinding algorithms and, the testing for our other components like fire detection would result in a success if the temperature and smoke sensor hit their threshold markers which were successful. For our LEDs/Display testing, we wanted to ensure that based on commands and paths given as an output from the pathfinding, we can correctly display the directions for all of the unit tests as well as highlight the correct path on the display for all of the unit tests. For the battery circuit, we have tested at the correct voltage necessary to ensure the batteries are recharging to use for our circuit which we got to be 7V. For our communication testing, we tested to see the range in which packets were able to be successfully sent between two ESP32s. We found that there were 0 dropped packets within a 200 ft hallway. With these testing results, we haven’t had to make any major design changes to our project as a lot of our design choices came from previous preliminary testing of designs that led to our designs. Currently, our design is fixed and we are just focusing on integrating the components for the full pipeline.

In the upcoming week, we will all be busy on integration as well as the final deliverables (demo, video, report, poster). We hope to be able to use our PCBs after going through multiple designs for correctness but we want to be prepared with a backup plan. In terms of our Gantt chart, we are behind in terms of the PCBs which we have moved to this week. Other than that, tasks on the schedule for the week are aligned with the final deliverables that we will be working on as well as building our small scale demo and having our demo correspond to this at a smaller scale and doing an entire test in a regular building.

This week we spent the majority of our time on PCB design finalization. We made some design changes with regards to ordering an MQ-02 sensor with a built-in breakout board as well as a potentiometer to ensure that we wouldn’t have to waste time recreating this circuit on each node. We also added the possibility of powering our board with a barrel jack and ordering a plug to show how when attached to a wall, we would be able to power our nodes when they are not just running on the batteries. We also started working on our final presentation slides and cleared up some concerns with regard to the content of the presentation and we are now working to reformulate it in a manner that we can show off the progress we have made up until this point despite being able to keep working on it after the presentation. 

One of our major risks is ensuring that the PCBs come in time and are wired correctly. We have spent a lot of time this week connecting with Quinn and learning how to use the Voltera to make our own PCBs which we started two versions of but had to edit due to the trace width or spacing between holes/pads as the conductive ink tends to spread when the probe moves. Even then, the machine doesn’t have big enough drill bits for our mounting holes so we had to order that which means we can only clean up and finish our PCB on Monday. Quinn was nice enough to order our PCBs on Friday through JLCPCB in order to have a backup plan using a design that Aidan and Neha spent a lot of time checking for correctness. Though we are hopeful that it will work as intended, we want to be able to anticipate it not working the way it should, in which case we would need to edit the design and send them out to be fabricated once again despite cutting it close in terms of time. We are also considering the possibility of using solderable breadboards to get a slightly more finalized version if all of our PCB fabrication attempts don’t work out. 

One other risk is finding the correct voltage for our wall power supply. We know that we are able to use at least a maximum of 7V on the 5V rail of the ESP32 and we need at least 5V to our batteries after the diode and resistor in our circuit. This means that we should be able to get a high enough voltage to our batteries, but we still need to find what value we will use.

The only change we have to our schedule is that we had to push back some of our deadlines such as the poster, video, and creating the shelf for our demo. In hindsight, it was probably a mistake to schedule these as early as we did because we need to have a working product before some of these tasks. However, we feel that we will be able to finish them soon and before the actual deadlines, so rather than actually changing our schedule, we will just catch up in these areas. We also received notice that we have been invited to present our demo at the general CIT presentation, in addition to the general ECE one, which has moved up some of our deadlines, but we still believe that we will have enough time to get it all done. After this upcoming week ends, most of our schedules clear up, allowing us to dedicate more time to get things finalized.

This week we had our interim demo which we believe went pretty well, and we hope to keep moving forward with integration between more of our individual components. Earlier in the week, we spent a lot of time doing initial integration for the sake of our demo where we were able to create a fixed path and broadcast which node had detected a fire and what that meant for the rest of the nodes in the path. We were able to recalculate a new path based on that fire-detecting node and once the fire was no longer detected, we were able to change back to a different path. We also had integration between the LEDs and the displays, as we were able to display directions and a highlighted path based on a hardcoded set of nodes and edges. We hope to be able to move away from this hardcoded testing to be able to incorporate real smoke and temperature data and have the paths reroute. 

Our risks continue to be integration between separate, individual components as well as the PCB fabrication that we are still trying to finalize the details on. Our current plan of action is to reach out to Brandon Gonzalez, a student of Professor Carley’s, that has worked with this area before to gain some insight and hopefully move forward with the fabrication of our own PCBs. However, we don’t want to get too stuck on this and spend too much time so we want a backup plan of either generic solderable protoboards or just using JLCPCB to send one out in parallel to us trying to figure out how to do it ourselves. One other risk is that our PCB is looking like it might need 2 layers. This would increase the complexity of our PCB and may make it harder to manufacture on our own. This may encourage us to look into shipping.

One small change that we made is that we are no longer planning on having power going from the wall to a jack on our PCB. This was our original plan, but we realized that this was very unnecessary due to the fact that the ESP already has a micro USB port that we can use. This way, we can just allow our PCB to be driven by the 5V pins on the ESP32. Another smallAnother change is the number of batteries we may be using. Originally, it seemed like we were going to use 3 batteries for the LED nodes and 6 for the LCB nodes. However, after testing, it seems that we may be able to use 4 for both of these. It also seems like we may not use the 3.3V pin to power our ESP32 because we were having trouble getting this to work, whereas using the 5V pin worked well.

For our interim demo, we also made some Gantt chart edits that involved pushing the PCB fabrication and design further back as well as adding in some more achievable subtasks by breaking down bigger items to be able to make more progress toward our final demo.

At the moment, we realized that after our weekly meeting with Professor Mukherjee and Kaashvi that we are in a better place than we thought for our interim demo. We, however, don’t want to fall behind so we are aiming to keep the efforts on integration high as we keep progressing toward and beyond our interim demo as we still stand by the fact that it will be difficult to combine each individual demo. Currently, we feel that the most significant risk would be the fact that our batteries have not arrived yet. Our rechargeable battery circuit is a part of each individual node and we need to ensure that our node works as a whole in terms of power draw and designing appropriately fitting PCBs. Regarding the Eagle design, we can just do the rest of the design without the batteries for now and then add it in, but ideally, we could get it all done as soon as possible. 

Another risk could be the making of our own PCBs as we mentioned in our last report. After our weekly meeting, we went to TechSpark to check out the machines that will print them on copper sheets. We have a copy of the manual and we know that we still need to create an Eagle file, but it would be great to get in touch with people who have used it as we are very new to it and will most likely have a lot of questions. We need to figure out very soon whether this approach of making our own PCBs is going to work for us, as the window of time for ordering a PCB from one of the standard manufacturers is running out quickly.

One other risk that we ran into is that our code is written to run on its own, not to be integrated with other code. This will just require some more time on our part to ensure that the code will be written in a way that it can all interact. Once we are able to accommodate this, we can begin integrating our code.

This week we have our interim demo on Wednesday and we plan to spend a lot of time before this working on some more in-depth integration with the displays and the communication/pathfinding to put us in a better position. There have been no changes in our timeline or system layout, so no updating is needed on that front. 

At the moment we anticipate that the most significant risk that could jeopardize the success of the project is integration. While we have all been working on separate sections, for the most part, independently, we realize that combining each individual component will take some time. Given that we have about a week before our interim demo, we have multiple mini demos of how we want our system to work from interfacing with the display using solely the ESP32 to broadcasting between nodes such that they recognize temperature changes and can respond accordingly. But we think that combining them together will take some research and extra time and effort. We need to find a good way to highlight a path on the image of the floor plan and once we can do that, we need it to change real time based on the temperature and smoke data between nodes. 

 

Furthermore, we are still waiting on our new batteries to come in for the backup battery circuit. That is a component that we haven’t worked with yet and one that we need to prioritize as it will be a part of each individual node. The order should’ve gone out last week so ideally they will come in at some point in the next week so we can figure out how we want to test and organize this circuit amongst the other components on the node. This is something that we are a bit behind on in regards to our Gantt chart.

 

One other potential risk is the construction of our PCBs. We recently decided that it may be easier to make our own PCBs rather than order them. However, we have never done this before so it is risky to think that it will go completely smoothly. We will research this as needed to ensure that we are able to complete the construction of these PCBs.

 

This week we will be focusing on integration for our interim demo. We will be doing a lot of work together to combine our individual components. In regards to our schedule, we have been able to catch up some more but we still are behind for ordering PCBs which we also want to make as a priority for the week. We liked the idea that we discussed with Professor Mukherjee about making the PCBs in house, but we would like to know who to contact to get that process started. We will probably be reaching out this week to finalize those details. Currently, we are happy with the individual components that we have working (Communication, sensors reading, display control, etc.), but now we just need to put all of these items together to get ready for our interim demo. For our interim demo we are hoping to be able to read in data from both of our sensors, signal to other nodes if a fire is detected, perform pathfinding while avoiding nodes with fire, and be able to display the directions from this pathfinding on the LEDs and LCD displays.

At the moment, our most significant risk to our project is going to be the integration of all our independent systems. We have been working on the pathfinding, displaying on the LCD, networking, and sensor detection all in isolation. With the demo occurring in two weeks, we will need to really focus on getting each system into a reasonably finalized state so that we can work on integration between all independent parts. This will also require a lot of joint time spent between the owners of each technology so that we can get each of the systems properly meshing. 

To try and mitigate this risk, we are doing our best to have each of our systems in a working state prior to this upcoming weekend to leave ourselves with at least a week to work on integration. This would require all of the sensors arriving quickly and being promptly tested, finalizing the pathfinding code and backup battery circuit, and being able to build graphs based on inputted floor plan examples. Currently, one of our biggest challenges is networking and being able to get our individual ESP32s to communicate with one another and show that we are properly being able to transmit and receive data. As our optimal path depends on smoke and temperature data from each individual node and being able to share this information amongst each other, we need to make this a priority. For the sake of our demo, we are just going to be using breadboards instead of the PCBs as we would want to test that our integration works before finalizing with a PCB. We realize that we have many complicated moving parts and we need to get working on integration as it will be pretty challenging especially with the initial demo coming up quickly. We will be spending a lot of time outside of the mandatory lab to work as a team to get these tasks done especially knowing that this week we don’t have our weekly professor/TA meetings and we are dedicating Wednesday’s mandatory lab to the ethics lecture and discussion section.  

One of the biggest changes that we made to our design this week is that we have scaled down our design from using 10 nodes to using 7. We were running up against our budget and decided to return some of our parts to the ECE store to have some more flexibility in our budget. We feel that 7 nodes will still be enough to be able to demonstrate the path planning and other features that we are working on. Another design change that we are considering is switching from ordering PCBs to making our own. Because our PCBs are going to be fairly simple, we feel that we may be able to make these ourselves. This is something that we will be looking into.

While there are some places that we have fallen behind in our schedule, we have not decided to adjust these in our schedule because we are planning on making this progress up next week. We feel that our schedule is still feasible and that it allows us good pacing for our project.

This week, we spent a lot of time working on our design report as a team. It was a big team effort as it involved a lot of special considerations and thoughtful explanations. We wanted to ensure that we were addressing the concerns from our presentation and working on the feedback provided to us. Beyond working on the design report, we each had individual tasks to complete based on how we divided the work of the project which is provided in detail in our individual updates.

The most significant risk that we are facing right now is making sure that we receive the hardware in time to take into account the integration time. We have not yet received the XBee modules that we are planning to use to enable our ESP32’s to communicate over ZigBee. While this is not going to be the primary mode of communication for our node system, we still need them to provide a proof of concept. Seeing as none of the members on the team are familiar with using XBee modules, or the ZigBee protocol, we are worried that their delayed delivery will make integration an issue for the interim demo that is occurring on April 3rd. To plan around this, we are making sure to work on development for WiFi, as that is already implemented on the board, and is the primary mode of communication we actually plan to use for our demo.

We have not had any design or major gantt chart changes in the last two weeks. We had anticipated extra time dedicated to our design report which might have gotten in the way of tasks necessary for the project building itself. Our gantt chart specifies that we should be focusing on getting nodes to communicate with each other over a network, but the type of network is never specified; initially, we had intended for this to be about ZigBee, but this task is now referring to WiFi. Furthermore, in regards to the design not changing, we do intend to keep smoke sensors as part of our node structure. However, we are now looking into changing our original smoke sensor to a more reliable and well documented MQ2 sensor which we need to place an order for by Monday so it can come quickly in order to get well acquainted with it. While the implementation of the task has changed, the task itself has not been modified, and no updates to the Gantt chart have been made.

One of the new tools we must learn that is necessary for us to complete our tasks, is the software used to create an interface on the displays that we ordered. These displays use their own software to establish a general layout template, and then update with information that is passed into it. We will need to learn how to make a template that will match either a floor plan or a set of instructions, and then update it depending on what information is being passed to the display from the pathfinding calculation done in our software. This software seems relatively simple to use – it claims to be drag and drop – but it is another step that we will need to address during the testing and integration phases. Another tool that we know we will need to become more adept with is Eagle. Right now, we have some experience, but in order to successfully design our own PCB, we will need to become proficient. As our hardware pieces are coming in slowly, we are able to figure out how each individual component will communicate with the ESP32 and from there we can plan our PCB that takes into consideration all of our individual components to work simultaneously.

This week, we began by working on our design review slides. This was a team effort, and we spent much time meeting to ensure that the slides were completed. We met to ensure that we were set up for success in the presentation, and referred to Kaashvi for feedback on our slides before we submitted them. We also referenced feedback from the proposal presentation to ensure that we were not repeating the same mistakes and clarifying information that needed it. After this, most of our time spent together was during the in class presentations, so the majority of our work was completed individually.

One risk that we discovered this week is that our design essentially has 2 MVPs and needs 2 sets of design requirements. By not specifying these separately, we run the risk of having conflicting specs for our varying hardware. As a result, going into our design report we need to ensure that we are specific about what our node structure would look like for the 2 kinds of nodes and why we made the design choices that we did. We can make these changes accordingly so that our report reflects the dual MVP in order to minimize the risk of confusing our audience and users.

This week, we changed our design with respect to the original ESP32-C6s that we wanted which appeared to have the newest standards for WiFi and Bluetooth and is known to support Zigbee. While we filled out this form on a Thursday, we had to wait until the beginning of this week for the request to be sent out at which point there were no more boards left in stock. As a result, we ended up ordering the ESP32-C3s which is also equipped with WiFi and Bluetooth which arrived yesterday. From here, we would need to pivot in the information needed to interface with the boards we currently have instead of what we planned for.

We have had to make a couple changes to our schedule. One task that had to be changed is the testing of our smoke sensors. We did not have our smoke sensors yet this week, so we were unable to begin using them. For now, we have pushed this back to March 1st, as this is their estimated delivery. Additionally, we created a new task for integrating the communication with the distributed pathfinding algorithm. As this algorithm relies on communication, it cannot be tested until our communication is up and working. Furthermore, we hope the displays come in soon but in the event that they take longer than expected we would have to push the integration and testing of getting an output to display from the ESP32-C3s until they arrive.

At the moment, our teams deadlines have not been extremely reliant on each other. This means that when one of our teammates has missed a deadline, the other members have not been strongly influenced. If hardware ends up coming in later than we expect, issues that we could anticipate with overlapping tasks would be regarding the testing of the parts with having the parts integrated with the pathfinding as well as testing on a breadboard conflicting with designing and fabricating the PCBs. We will keep monitoring the tasks often to ensure that we are still able to get our tasks done if unexpected delays occur causing us to push back certain tasks more than others.

One of the significant risks that could jeopardize our project would be finalizing microcontrollers that fit all of our needs. For example, a lot of our time this week was spent picking parts that met different concerns like cost, reliability, compatibility with Zigbee and displays, etc. Unfortunately some of the boards we thought were most ideal haven’t even been introduced for public use yet. Our project would like to take into consideration the possibility of the wifi going out, which is why we knew we wanted to take advantage of a distributed, node based network like ZigBee. However, because some of the ZigBee cards that we have found can be pretty expensive and we have a lot of nodes, we wanted to explore alternatives. In order to make progress we decided to proceed with ESP32s and use a local network. However, because we want to take into account that the network needs to stay up, even if the WiFi goes out, we plan to order a couple Zigbee shields to show that we can make this change if necessary and explain how it would scale up. Additionally, we will explain how our system had to use only a couple Zigbee shields due to availability problems and long lead times, but that if this project was put into production, we would hopefully be able to order these parts and deal with the long lead times. This would give all of our nodes Zigbee capability, while staying under budget. This is the largest change that our design underwent this week.

For pathfinding, we are testing two pathfinding algorithms against each other. The first is a Dijkstra’s search that will work well if each node has access to the status of every other node. In the case that each node is connected to Wifi, this is a realistic scenario. Our second algorithm is a Dijkstra-Schlater search: this is a distributed Dijkstra’s search in which each node infers the shortest path from itself to the exit by receiving the shortest path from its neighbors to the exit. 

Both have pros and cons: Dijkstra-Schlater would probably scale better, but vanilla Dijkstras would probably have better latency. We are planning to implement them both and do real-world testing to figure out what we want to use on our final design. We also plan to test A*, which is nearly identical to Dijkstras, but with an added Heuristic function. 

Jason has pushed back his schedule by a few days to take into account some of the issues he had finalizing what hash map and priority queue implementation he wanted to use. Due to some of the slack time that was built into his deadlines, this shouldn’t impact the rest of the timeline or integration. 

Our project recently has relied on 18-349, 15-210, 18-220 for our knowledge of pathfinding using Djikstra’s algorithm. Beyond these courses, we relied on a lot of external research on datasheets and tutorials of the different displays, sensors, microcontrollers, etc. We also spent a lot of research on distributed nodes and how we can run distributed pathfinding algorithms for each node so we can ensure that if a node went out we can still have an optimal path passed to a neighboring node.

One of the engineering principles that we kept in mind while we were designing our project is Usability. We wanted to make sure that our product was easy to use. When people are escaping from a burning building, the do not want to be spending much time trying to figure out our system. One of the ways that we used this for our design is that we prioritized display size. We wanted to make sure that the displays would be big enough for our user to read quickly and effectively. Many of the displays we saw had around a 1 inch diagonal, but with further research we found one that is over 3 inches. Another engineering principle that we used is redundancy. In distributed systems, it is important that if one node goes down, the others will be able to continue their tasks. For our project, we have ensured that our system will be able to survive a node going offline. This is especially important for us, as our nodes may be subjected to extreme heat. Additionally, we are providing redundancy in our sensor by using both smoke and temperature sensors.

We think that the most significant risks that could jeopardize the project will be one of the following: making sure all the hardware integrates properly, making it clear what direction for users to go after the path is generated, or complying with the battery requirements set by the US fire code.

To try and mitigate risk, we are trying to order the hardware as early as possible to give ourselves as much time as we can to familiarize ourselves with the sensors. We will be meeting tomorrow, 2/12/2023, to come together as a team and settle on the hardware, with the hope that on Monday, 2/13/2023, we can speak with Professor Mukherjee or our TA, Kaashvi Sehgal, and get their opinions prior to submitting a purchase form. As for how we will make it clear what direction to go from a node, we are doing our best to test this functionality early: we want to test it early enough that we can decide if we will need more display nodes or if a mix of display and LED nodes will be sufficient. At the moment, we have the least amount of risk mitigation for the US fire code battery requirements: the power draw will be dependent on the hardware that we order, which has still not been finalized. We, as a team, also don’t have much experience with speccing out battery requirements and have not focused on circuit design classes in our curriculum, and therefore recharging the batteries after a power outage will require a lot of research from the group, and input from the TA’s and professors. We tried to touch on this in our proposal presentation but after presenting, we realized these are not necessarily use case requirements but specs that we need to consider and finalize for our design presentation that is coming up.

We have not had any changes to our overall system/architecture design as of yet. Seeing as we are still in the general testing and research phase, and have not run into any hurdles yet, this part of our project has stayed constant. Ideally, as soon as we order and receive the hardware that makes up the nodes, we can begin breadboarding our initial design and determine and take note of what changes need to be made.

We have pushed back our expected deadline to order our hardware, however. We originally had that scheduled for February 9th, but we wanted to take time to research the sensors more, and consult faculty. Seeing as this is only being pushed back by a few days, we don’t see this impacting the rest of the timeline that we have set up. Additionally, we have started developing the path finding software. This includes both our algorithm and the platform/test suite that we will be using to test our software. We have preliminary path finding running on a laptop, which was our goal for this week and we are planning on getting this path finding up and running on Arduino’s by the end of next week, which is consistent with our schedule.

Seeing as our project is aiming to provide potentially life-saving information to occupants of a building fire, the main consideration for our project is public health and safety: we want to make building evacuation as safe and chaos-free as possible.

We are also trying to take economic concerns into consideration. While our project is mostly focusing on large-scale buildings – residential homes tend to be too small to take serious advantage of the system – we don’t want our project to be inaccessible to construction with lower budgets: ideally, it will be available to everyone. We are taking it into consideration by trying to choose low-budget parts for our node construction; Arduinos are one of the cheapest general compute modules and have a large ecosystem of compatible sensors. The sensors themselves are quite cheap, and if we design custom PCB’s we could order them in bulk for a significantly lower price than breadboards and wire.