P20225: Doc B Racing Real Time Telemetry
/public/

Detailed Design

Table of Contents

Team Vision for Detailed Design Phase

What did your team plan to do during this phase?

During the Detailed Design Phase, the team planned on focusing primarily on the data transfer to the SD card. The team planned to break up into two groups, one for hardware and one for software, and go over the previous teams work to see what the possible problems could be that are causing bottlenecking during the data collection transfer. The software team planned to make new code for an inverting buffer setup, while the hardware team looked over the PCB and see exactly how the data was being transferred from the microcontroller to the SD card. The team as a whole also worked on updating all necessary documents weekly, along with meeting with a Professor to help with the data transfer testing, as described in more detail below.

The first part of the Detailed Design Phase was planned for making and completing a progress report. The progress report was to tell what the team plans to accomplish during this phase, what tasks have been accomplished in the previous phases, what are the remaining task and what team member is responsible for it, what decision on the product have been made final by the team, and what questions still remain for the customer to continue moving forward with the completion of the design. In the progress report the team planned to go over the previous teams work as well, to show what will stay the same and what designs will be modified or added. Once the progress report was completed the team planned to send the document to our guide and our customer.

Once the progress report was completed the team moved on to creating a meeting with Professor Barrios to get help with the SD card data transfer. The team worked together to make questions to ask Pr. Barrios about what would be the optimal method for writing to an SD card, along with questions on how to calculate the appropriate buffer size to send data via the SD card used. Once the meeting was made the team planned to go as a group and take notes on what was discussed, and to move forward with testing based on what Professor Barrios suggests.

As the team was waiting for the meeting with Pr. Barrios, the team planned to go to the lab and go over the previous teams code in more detail for data transfer to the SD card. From the testing done in the previous phase, the team agreed on choosing not to focus on fixing the Imagine RIT user interface, and to focus on getting meaningful data from each sensor instead, as the data being useful is a higher priority than having a functional user interface. Once the previous teams code was understood, the team planned to write new code and test the inverting buffer code if the meeting with Pr. Barrios agreed with the steps of testing the team planned on. If the meeting led the team in a different direction the team agreed to go in different direction so that they could go back and get additional help from Pr. Barrios if needed.

Lastly, the team planned to check the schematics, drawings , and flowcharts from the previous phase and see if anything needed to be updated or changed. The team planned to keep the schematics for the hardware the same as the previous phase, and add the additional hardware of the accelerometer and the USB port to the PCB during MSD II. The sub-system flow charts for the system architecture planned to stay the same as well, unless changed based off of what Pr. Barrios guides the team to do. The team also planned to update the Bill of Materials and order parts so that they are ready to use at the start of MSD II. The Test Plans and Risk Assessments planned to stay the same unless more testing was completed. Once all documents were updated the team planned to update the Gantt Chart to show everything completed in MSD I, and to make weekly plans for what is to be completed in MSD II.

What did your team actually accomplish during this phase?

During the Detailed Design phase, the team completed all of the steps planned by working together during senior design class and at home on Google drive. The progress report was completed by the team working together on saying what has been accomplished and what will be completed during the detailed design review, and working separately on what tasks remain and what decisions have been made so far. Once the report was completed, it was sent to the team's customer and guide, and was posted on the EDGE page. Along with working on the progress report, the team worked on the Gantt chart to set completed date goals for the individual and team goals remaining.

Once the progress report was completed the team met with Professor Barrios and discussed the SD card functionality and how the team could test if meaningful data was being sent correctly from the microcontroller. Pr. Barrios suggested to first test and see if the microcontroller is collecting meaningful data from the sensors using a logic analyzer, and then move on to working on the buffer size code functionality for the SD card. From the meeting the team agreed to changed test the PCB with a logic analyzer during the beginning of MSD II, along with adjusting the code of the data transfer. From the software team looking into more detail of the code, they noticed some areas where the code could be faulty, and started rewriting new lines that will be tested during early stages of MSD II.

From the meeting with Pr. Barrios, the team did not do any testing during the detailed design phase, as they focused on writing new code and doing research on choosing where to test the sensors data with the logic analyzer. From not doing any testing, the Test Plans. The Risk Assessment was updated to add Not having demo ready for Imagine RIT, and not being able to fix the bottle necking in the code. The Bill of Materials also stayed the same, and the materials were purchased at the end of the phase so that they will be delivered during winter break, and be ready to use at the beginning of MSD II. The schematics, drawings, and flowcharts stayed the same as the previous phase, as the team agreed to continue with the subsystems and hardware additions chosen.

Lastly, plans for MSD II were made, for both the team as a whole, and for the hardware and software team. The hardware team agreed to work on looking into the Bluetooth and Wi-FI capability with the current PCB, and to see what would be needed to purchase to make the wireless data transfer available. The software team agreed to look into more detail of all the previous code written by the last team, and to test the inverted buffer code and the modified data transfer code. The team as a whole planned what will be worked on weekly, and chose who is the lead for each goal, which were placed in the individual three week plans and the Gantt Chart. The team also planned to get some of the testing done during winter break, as most of the team will be back early and can spend time testing the sensors and data collection.

Progress Report

What does the team plan to accomplish by the Detailed Design Review?

What tasks have been accomplished so far?

What tasks remain, and who is the owner of each?

What decisions have been made so far?

What questions does the team have for the customer and/or guide in order to continue moving forward?

Prototyping, Engineering Analysis, Simulation

Old SD Write Function

public/OldSD.png

New SD Write Function

public/newSD.png

Upon further examination of where the system actually attempts to write data to the SD card it was found that the system functions did not have proper usage compared to the FreeRTOS documentation. Updated and fixed issues with the function to conform to the FreeRTOS usage. Moving forward we will have to examine how all system functions are used in the code base to ensure they are conforming. This may have been due to an update in the current FreeRTOS version, or was always incorrect.

An updated and more detailed sketch of the new enclosure. Though it looks rougher, it is a much smaller overall footprint and the simplicity of design should make for lower manufacturing costs.

Feasibility: Prototyping, Analysis, Simulation

Feasibility Questions

  1. How can we efficiently capture data and write to the SD card in the correct rate?
  2. How can we learn from the source code and build upon it?
  3. How can we make the design of the box better, able to withstand higher temperature and more portable?

Assumptions

  1. The data can be captured and seen on a console; however, the rate at which it is capturing it is faster than at which the SD card can take it in.
  2. Testing out various components and questions have been created to ensure that we have the correct answers for what we are analyzing.
  3. Making a smaller design would allow easy-to-fit spaces and placing the box in a low temperature spot would help it not damage any of the internals. Either a stronger plastic or different, but cost-effective material would help.

Approaches

  1. The SD card problem lies within how fast data is read from the vehicle and when it starts to write to the actual SD card. A delay mechanism needs to be implemented in which the the data can be read and then a delay is applied in which the data will be stored; after this, data will be written in big chunks to the SD card. New data will then be stored in an array while the data written to the SD card will be in another array. Emptying the array which is written to the SD card will allow for the other array to populate into the new one. This process of using two arrays will add a delay factor by populating and emptying each array. This will be called an inverted buffer. An example of this method is provided below.

https://edge.rit.edu/edge/P20225/public/Photo%20Gallery/SD_Part1.PNG https://edge.rit.edu/edge/P20225/public/Photo%20Gallery/SD_Part2.PNG

  1. Currently, source code is available to be viewed for the SD card data processing. The source code has been analyzed and questions about the source code have been written. Continual division of labor within the group is required to assist within reading the code. This will aid within speeding up the process taken to understand the code-base
  2. New materials need to analyzed to ensure that the box can withstand high temperatures and fit easily in any compartment. Ceramic Polymer and other sorts of plastics have been looked into in regards to the temperature process; furthermore, new sizing of the box has been taken ensure a better fitting for the future.

Inputs and Source

Outputs and Destination

Bill of Material (BOM)

Completed BoM and Budget Link to live document below:

Test Plans

Purpose

The purpose of the testing plan this phase was to implement and test viable SD Card Read/Write methods as well as debug logical analyzer ports on the microcontroller.

Instructions

Throughout this phase:
  1. Initially began via reading over current code-base implementation
  2. A discussion with the previous team was held to understand and come up with possible SD Card Read/Write methods.
  3. The previous team guided us on moving forward into the data acquisition portion. Furthermore, a meeting Dr. Carlos Barrios from the Electrical Engineering Department assisted us in coming up with more ways of implementing the SD Card Read/Write method via analyzing logical analyzers on the board.
  4. Hardware schematics were analyzed to discover where the logical analyzers were

Inputs and Source

Outputs and Destination

Subsystem Flow Charts

System Architecture (From Last Phase as Reference)

public/sysarch.png

Input Control Processing

public/IOProc.png

Configuration Conditioning

public/ConfigCondit.png

Output Data Processing

public/OData_Proc.png

Output Data Conditioning and Write Back

public/ODataWB.png

The subsystem flow charts illustrate, in detail, the logic which will be used to implement each major components of the system architecture through software processing on the micro-controller.

Risk Assessment

Design Review Materials

Link to PowerPoint Presentation below:

Plans for next phase

As a team, what do you need to accomplish between now and the end of the semester?

In between now and the end of the semester, the teams’ goal is to come up with a feasible method of SD Card Read/Write method for data acquisition purposes. During the break, the team will split into various groups: software, hardware, and mechanical. The software team will continue to analyze the code-base and come up with novel ways of writing/reading the SD card; furthermore, this team will test intensively to ensure that the SD card read/write works over the break. The hardware team will continue to focus on purchasing and installing more sensors onto the board as well as gain a greater understanding of the PCB layout to assist with debugging in the future. The mechanical team will continue to push further in creating a enclosure that is not only smaller, but stronger; it will be able to withstand extreme temperatures and be able to fit within many areas. Overall, the team will also update the Bill of Materials, Test Plans, and Risk Assessments as the simulations and testing goes on, as more various testing will take place once each sensor is found to be functional in sending data to the SD card, hardware advancements, and enclosure changes. Once each sensor in operational in a simulated version, they will be than taken to a track or placed in a normal car to test in the real environment, along with the test of the wire harness. The designs and flowcharts will also be update from the previous phase if anything is changed.

As a team, what do you need to do to prepare for MSD II?

As a team, we need to come up with a concise and defined schedule with dynamic and feasible deadlines to ensure that we can move forward successfully accomplish our tasks. Our first priority, as a team, is to get the SD card working; therefore, over the break, we will discuss ideas and implement these ideas within the codebase to ensure that we have a successful read/write operation of data acquisition. Intensive testing will be done to ensure that this operation works. We also need to come up more sensor ideas to implement within the microcontroller such that more information can be delivered to the user. Finally, a command-line interface will also be in the thoughts to ensure processing raw data is successful.

Individual Three-Week Plans Below:


Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Customer Handoff & Final Project Documentation