Risk and Plans
What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?
One risk to our project is the limited compatibility of Python packages with the Raspberry Pi 4 (RPi4) operating system, largely because pip, the package installer, is not available or functional on the RPi4. This limitation impacts our workflow; while we can develop and test code locally, some libraries that work seamlessly on our local machines are incompatible with the RPi4 environment, requiring us to find alternatives or workarounds. For example, we initially used the pyttsx3 library for AI-driven audio generation to create spoken alerts. Although it performed well in local tests, pyttsx3 cannot be installed or used on the RPi4, hindering our ability to generate audio dynamically in real-time on the device.
To manage this risk, we’ve developed a contingency plan to pre-generate multiple audio files on our local machines, categorizing them based on obstacle distance and direction, and then transferring these files to the RPi4. This approach allows us to use pre-recorded audio cues rather than generating audio directly on the RPi4, maintaining essential functionality while bypassing package compatibility issues. On the contingency planning side, we are also proactively researching compatible packages and frequently testing setup code directly on the RPi4 before full implementation. Hope by doing so, we can identify and resolve compatibility issues early in the process, and then minimize disruptions and making smooth integration.
Change in Design
Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?
This week, we focused on a potential adjustment to our system’s design related to GPS integration with the RPi4. Our main goal was to assess the feasibility of connecting the GPS module directly to the RPi4. However, if stable integration cannot be achieved due to protocol limitations, our backup plan is to use the user’s smartphone GPS for location tracking. This change would require minor software updates to process location data from the smartphone, ensuring functionality remains seamless without additional hardware.
No design changes have been implemented at this stage. However, if the smartphone GPS becomes necessary, we will update the block diagram and system specifications to reflect this alternative approach. This contingency plan effectively manages the GPS integration risk while maintaining our project timeline.
Schedule Updates
Provide an updated schedule if changes have occurred.
Our schedule remains on track with no significant changes at this time. In the coming week, we plan to accelerate system integration across all components. With the audio hat integration successfully completed, our next priority is the radar component, which we aim to finish by the end of next week. If the newly ordered accelerometer arrives as expected, we also plan to initiate GPS integration.