Team Vision for System-Level Design Phase
The goal of this phase is to determine what individual systems will be necessary in order to fulfill the customer requirements, and determining how these individual systems will interface. At this point in the design, each individual system should have multiple concepts but the interface between them should be determined and frozen. Additionally, the risks document should become very close to the final document, excluding any unexpected risks encountered in the detailed design, build, and test modules.
During this section, our team began to converge on what we think will be the best combination of systems to meet our goal, and have developed a few test plans to further confirm this. Each system still has several backup concepts should unknown problems be encountered.
Figure 1 shows all of the functions that the system must perform, going from the general to specific functions. The most basic, overarching function is to monitor the driver's vitals and biometrics. That function then breaks down into the steps needed to monitor the driver reliably and the finer details of how that should be done.
The devices we chose for benchmarking against our concept were the Apple Watch, Fitbit, F1 Palm Sensor, and Portable EKG. We felt these devices gave a good range of what combinations are available on the market right now. Right away we find that our concept is the only one to use the complete set of sensors we intend on using. Also, we find that our concept is the only one that transmits to the CAN bus as opposed to real-time monitoring, which is one of the most critical functions in order to meet the customer requirements.
The full document can be viewed here: Benchmarking Matrix
To set up our Morphological Table, we took the functions that the system must perform and came up with some ideas as to how we can perform those functions.
Sensor Power: In order to distribute power to our sensors, power can be sourced directly from a microcontroller/SBC through wires, or have one or more batteries on the driver so that less wires are running between the driver's suit and the board.
Muscle Activity Tracking: Muscle Activity/Force needs to be objectively measured for evaluating fatigue. This can be done with EMG sensors (with or without sensor stickers) or pressure transducers.
EMG Data Collecting: If EMG sensors are used, we need to know how we will use them. EMG sensors can be used on their own however, there are potential benefits in signal quality if the sensors are modified, or if new sensors are designed altogether.
Body Temperature Data Collection Temperature data needs to be gathered using a sensor. This concept is used for figuring out where the sensor should be positioned to get an accurate reading without causing discomfort.
Heart Rate Data Collection: There are many different methods of measuring heart rate, such as pulse oximeters and EKG sensors. We need to choose a way to measure heart rate that's accurate and comfortable for the driver.
Blood O2 Ratio Data Collection: Gathering blood O2 levels is also necessary. If a pulse oximeter is chosen for this function, its data can be used to calculate heart rate on the microcontroller/SBC.
Raw ADC Data Filtering: Filtering the data coming in from the ADC may be necessary if analog filtering built-in or added to the sensors is insufficient to get a clean signal. This concept consists of a variety of digital filters.
Transfer EMG Signal to Processor: This is the connection between the ADC and the microcontroller/SBC. We could send the data to an onboard ADC, or perhaps have the ADC close to the sensor and transmit the digital signal wirelessly.
Quick-Disconnect: These are various kinds of connectors we can use to ensure quick egress. Additionally, there may be no connector at all if the system operates wirelessly.
Board Protection: This consists of various enclosures to protect the microcontroller or SBC from water, heat, or any other hazards that may be encountered.
Data Conversion/Computation: These are the different microcontrollers or SBCs we can use the process the incoming data and ultimately send messages to the CAN bus. Options will vary in terms of computational power, size, and built-in components that we need.
Computer Power: We need to acquire clean power for the SBC/microcontroller. Since the system will be in the vehicle, we could use the vehicle's battery, otherwise we will have to integrate a power source independent of the car.
All concepts and possible components are given a cell in the Morphological Table below. Using the Morphological table, we combined different concepts for performing the functions into concepts for the full system.
Feasibility: Prototyping, Analysis, SimulationA detailed overview of the tests and analyses that have been performed to verify the feasibility of this project can be found in this document: Feasibility Overview
A summary of the results is shown in Figure 3. Red indicated that a corrective action will need to be taken.
The full document can be viewed here: Morphological Table
Above is a screenshot of one of the Pugh chart iterations performed in order to screen our concept options. A second iteration was performed moving the datum to the second concept, and the ranking did not change. Following this, the first concept was chosen to start moving forward with.
The second iteration can be viewed in the full document.
Based on the Pugh chart, we selected concept 1 since it best met our selection criteria. The systems architecture that follows is based on this concept, after going through a concept improvement stage.
Pending testing, the first concept seems to be the best in most aspects. One thing that will change from this concept, based on our feasibility analysis, is that we will be modifying the Myoware EMG sensors for a better signal, since they tend to pick up a significant amount of noise from the power supply. We believe that the benefit of a cleaner signal outweighs the cost in increased complexity and time to implement for this part of the system. Some other aspects of the system are still subject to change. For instance, we may choose to design our own quick-disconnect connector. The choice of the SBC/MCU is also subject to change if we find that the Raspberry Pi is not a suitable board. Some possible alternatives include, but are not limited to, a more powerful SBC such as the ASUS Tinker Board, or a board more specialized for DSP and data acquisition such as an NXP Digital Signal Controller.
This is a high level view of the system we intend on making. Components such as the SBC/MCU are left abstract in this view. The temperature sensor and pulse oximeter will likely go through an I2C interface, while the EMG sensors will each get a channel on the ADC. Filtering and amplification will be done as needed for the EMG signals. The ADC and CAN interface will, with whatever SBC/MCU we choose, connect/mount directly on the SBC/MCU. All the electronics will be contained in a waterproof case mounted on the car, which will also likely include some form of passive heatsink as some SBCs like the Raspberry Pi 3 B+ (which is included in one of our concepts) tend to get hot, especially in a waterproof case that would have no airflow. Our power source will likely be a separate battery and not the car battery, since that would provide cleaner power and less hindrance to the car's operation despite the added weight.
On the software side, all sensor data will come in as a digital signal that has to first be filtered. In the case of the EMGs, the signal will go through a low-pass filter (if the analog filter is insufficient), and then an FFT to see if there are any spikes within the pass band that could be counted out as noise. This will be done for every X number of samples as a moving window. The goal is not necessarily to reconstruct the signal afterward, but rather read the FFT output to determine what the muscle activity is at the moment. We're targeting 100 of these readings per second. Blood oxygen levels and temperature will be sampled at a lower rate, yet will go through a similar filtering process. The blood oxygen levels will be used to compute the driver's heart rate, and all the necessary information will be used to compute a fatigue level for the driver. All metrics are then sent to the CAN bus to be logged. It's important to note that there is a high level of parallelism in the initial conversion and filtering tasks, so the software will likely benefit from the availability of multiple processors.
Other Designs and Flowcharts
Figure 8 shows all inputs to the system and how the system will process or handle those inputs. This mostly consists of what data the system will gather, but also considers how the system must be kept protected in a racing environment. It also shows what outputs we then expect the system to produce, whether they're tied to a requirement or are a byproduct of running the system.
These are the risks we've identified so far for the project. This table has been revised based on the problem definition review. Signal noise still remains the highest risk.
Test PlanA high-level overview of the tests we plan to do as the system is being developed can be found in this document: High Level Test Plan
Design Review Materials
There are no pre-reading materials for this review. Notes and action items will be updated after the review is done.
Plans for next phase
For the detailed design phase, we'd like to work with our selected concept and work through the specifics of its subsystems. Here is a list of some of the work we would like to complete:
- Find or design a suitable quick-disconnect connector.
- Design a waterproof enclosure for the SBC/MCU.
- Create a mounting solution for the case.
- Run a thermal test on the chosen SBC/MCU at peak load and work on a passive cooling solution to avoid throttling.
- Determine optimal placement for all sensors with both accuracy and ergonomics in mind.
- Research and develop methods to analyze fatigue based on the gathered metrics.
- Work on modifications to the MyoWare sensors to improve signal quality.
- Select other sensors.
- Select a suitable ADC that will meet our sampling rate requirement and has enough channels for all the EMG sensors.
- Select a CAN interface.
- Figure out how the wires will be routed from the SBC/MCU to the sensors.
- Select a suitable battery to power all the devices and design a power distribution circuit if necessary.
- First draft of a UML diagram.
- Find libraries for tasks like digital filtering and making CAN messages.
- Set up version control.
- Look into multithreading and possibly using the GPU for parallel tasks.
Our project schedule shows when we plan to do these tasks.