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.