Author: cowarang

Chakara’s Status Update for 03/28/2020

This week, I spent more time understanding different algorithms in our software pipeline. I mostly work on triangulation, converting point clouds to triangular meshes. The actual implementation of triangulation is very complicated, especially for 3D objects. Thus, I decided to search for different libraries and modules that would fit our project scope best (which is also according to our design). I decided to use pyvista because it is a well-supported library and can provide VTK which helps with the project.

Below are examples of my work converting generated sample point clouds to triangular meshes.

For the plane object, we can see that there are 2 meshes, one is completely inaccurate while the other is a bit more accurate. This depends on different parameters I have to adjust: distance value to control the output of this filter, tolerance to control discarding of closely spaced points, and multiplier to control the size of the initial, bounding Delaunay triangulation.

This would most likely be the main risk and complicated part of this algorithm, figuring global parameters that would work well for all objects to meet our requirements.

I’m currently on schedule.

Next week, I hope to fine-tune this algorithm more to work with multiple objects. I also hope to integrate my part with Alex’s to test if the algorithm works on our objects. I also hope to start working on the test benchmarks and prepare for the demo.

Team Status Update for 03/21/2020

This week, we met with Professor Tamal and Joe over Zoom to discuss our change in plans. Our team members will be scattered in different places: Alex will be in Connecticut, Chakara will be in Bangkok, and Jeremy will likely return to Toronto once circumstances allow. This means that our project must be able to be completed remotely, which would void any hardware or physical requirement for our project. After the Zoom meeting, Joe brought up a fantastic idea to simulate the input data we would get from our laser setup – Jeremy will be exploring options for this since he will handle most things related to modeling and rendering for the project. Alex and Chakara will start to write code for handling the camera data and Alex will specifically be doing the math to convert 2D coordinates for the laser beam into 3D world coordinates to generate the point cloud with.

Currently, the main risk would be if we can or can not efficiently and accurately simulate or laser setup, more specifically, capturing the laser data and rotation angles. Jeremy has done a fair amount of research on this part and it seems likely that it is possible. If it does not, we can move back to using a RealSense camera to capture depth maps instead. 

The main change to the system is as mentioned in the above paragraph. We are removing all hardware/physical components of the project and will be using simulated data that we will create from rendering 3D objects instead. 

Below is the updated Gantt Chart with physical component related tasks removed. 

https://docs.google.com/spreadsheets/d/1GGzn30sgRvBdlpad1TIZRK-Fq__RTBgIKN7kDVB3IlI/edit#gid=1867312600

Below is our Refocus SOW describing the steps we will take to refocus our project:

TeamB3_2D23D_Refocus_SOW

Chakara’s Status Update for 03/21/2020

This week, I spent the first half of the week traveling back to Bangkok and setting up so I did not have much time to work on the project. After meeting with Joe and Professor Tamal on Wednesday, our team would be removing the physical parts of the project and would be creating a simulation of sensor data instead. Since my main tasks of this project were all related to the physical components (rotational mechanism, circuits, platform assembly, etc), our team changed our task delegation. I would now be working closely with Alex to implement different algorithms as needed. As I only understood briefly of our algorithms, I spent this week trying to learn and understand more about them. I also worked on SOW with other team members and was responsible for updating our task list and gantt chart. 

We are currently behind schedule because of the situation of the Coronavirus outbreak. However, after this next week, we hope to catch up on our process since we’re replacing all the physical parts and calibration mechanism with simulated data. 

By next week, I hope to fully understand the main algorithms we would be using and help Alex write some parts of the code related to the testing benchmarks and algorithm to construct global point cloud from sensor data. This would also depend on the data Jeremy would be able to simulate.

Alex’s Status Update for 03/07/2020

This week our group was responsible for ordering components and setting up our work environment so we could begin implementation as soon as Spring Break ends. I was responsible for identifying that we were missing a couple required items in our order form, such as the microsd card, sd card writer, and power supply for our embedded system. We also considered availability of components that do not need to be ordered, such as wires and soldering irons to connect GPIO pins with the motor driver and to hook up the motor driver to the stepper motor. We will also require power for the stepper motor, which requires a 5V variable amp supply to the driver, which we need to figure out (the Jetson also takes 5V at ~2A, but this signal is rectified from a 120V AC wall signal). The last thing we want to do is burn our driver board, since it is not cheap and we would need to wait for additional delivery time and would lose an additional chunk of our budget. Because of this, we will prototype analogue circuits on a mini-breadboard (provided from the lab) with a potentiometer to ensure we meet the voltage and current requirements of the motor driver.

 

I have had a very busy week before mid semester break as many courses (including the one I am TAing) are rushing to gather grades for the mid-term report. I have also departed on a 10 day vacation starting Thursday morning to Europe (Norway), and will return on Tuesday the week after Spring Break, meaning I will be missing another mandatory lab session. Luckily, we have factored in Spring Break and additional margins for slack to account for this busy time of the year, and thus we are prepared to get back on top of this project after the break.

 

This week I have also been considering implementing the testing routines, so that by the time our prototype software has been completed we can get a sense of its accuracy and timing efficiency. Instead of this however, we first need to determine our intermediate data formats, such as what the partial point clouds look like before merging multiple scans or during a single scan. To provide unit testing on each software component in the pipeline, these formats must be determined so that our testing and benchmarking software understands how to interpret our results. Because of this, instead of writing the testing code first, I began planning the prototype implementation software first, to allow also Jeremy enough time to find ground-truth models for accuracy analysis.

 

When writing test prototype code, the only parts that matter to us are:

  1. Accuracy meeting our project requirements
  2. Ease of coding and simplicity

The second requirement of the prototype code is not important to the final implementation of our project, but it is important to the prototype development. This is because we do not want to waste all of our remaining resources writing code that will not be used in the final project.

 

To meet the accuracy goal, we will test our prototypes extensively. These same tests can be reused for our final GPGPU implementation, so we do not need to re-implement testing infrastructure. This also makes sense since the prototype implementation should be a “complete” implementation that does not fully meet our timing requirement. If we have trouble implementing the accuracy goal for a stage of the prototype, we may choose to implement the section directly as our final GPGPU optimized software.

 

For ease of coding, Python is unparalleled in both our team’s knowledge of it, and the amount of computation that can be expressed in small amounts of syntax. Because of this, we will choose to use Python libraries to implement the prototypes. We will also use popular Python libraries for the prototypes, since we do not want to get stuck on issues that cannot be resolved. The library we use must be open-source (to avoid licensing complications and fees), have good documentation (for ease of development), and have an active support community (for ease of debugging).

 

Because of these, and prior experience, we will be using the following Python libraries to implement our prototype pipeline:

  1. Numpy for representation and transformation of matrices
  2. Scipy for solving optimization problems on Numpy arrays
  3. OpenCV for image filters, point-in-image detection, and other calibration procedures

 

These three technologies cover our entire use-case. Once our prototype pipeline is completely implemented, we can use the Python library Numba to auto-generate GPGPU code from our pipeline. If this code is sufficient, we do not need to implement C++ by hand for the GPU. If sufficient optimizations cannot be found, then we will need to implement some sections by hand to meet our timing requirements.

 

As a summary, my next steps:

  1. Write a “formal” specification identifying how intermediate data structures are organized throughout each stage of the pipeline.
  2. Write calibration routines using Numpy and OpenCV to do intrinsic/extrinsic camera calibration using the CALTag checkerboard pattern on the rotational platform.
  3. Write global calibration parameter optimizationusing Scipy
  4. Write laser-line detection using OpenCV
  5. Write laser plane calibration using Numpy and OpenCV
  6. Write 3D scanning procedure, interfacing with the motor controller and camera in real-time. This procedure will use ray-plane intersection with Numpy. Once this is complete, we will not only have unit tests for each section, but we can do a complete integration test on a single scan (after mesh triangulation done by Jeremy)
  7. Write the integration testing code for accuracy. Unit testing procedures will have already been implemented during development for each of the above sections of the algorithm.

Chakara’s Status Update for 03/07/2020

This week I mainly was responsible for picking up different project components and making sure they work as they are supposed to. Below is a summary table of the components that arrived and have been tested. For most mechanical components, we just tested whether or not they are fragile, rotate as they are supposed to, etc. The laser is shown to have enough intensity and the camera capture quality is great. The laser is also class 3A, but as suggested by Professor Tamal, I still contacted CMU to make sure that we don’t need additional training or safety requirements or the laser (which we do not).

 

Ordered Arrived Tested Item
Yes Yes Nema 23 Stepper Motor
Yes Yes Yes 15 Inch Wooden Circle by Woodpeckers
Yes Yes Yes Swivel Turntable Lazy Susan Heavy Duty Aluminium Alloy Rotating Bearing Turntable Round Dining Table Smooth Swivel Plate for Kaleidoscopes Tabletop Serving Trade Show Displays(10 inch)
Yes Yes Yes Source One LLC 1/8 th Inch Thick 12 x 12 Inches Acrylic Plexiglass Sheet, Clear
Shaft’s Gear
Yes Yes STEPPERONLINE CNC Stepper Motor Driver 1.0-4.2A 20-50VDC 1/128 Micro-step Resolutions for Nema 17 and 23 Stepper Motor
Yes Yes Yes Lazy Dog Warehouse Neoprene Sponge Foam Rubber Sheet Rolls 15in x 60in (1/8in Thick)
Yes Yes ~ Adafruit Line Laser Diode (1057)
Yes Yes Yes Webcamera usb 8MP 5-50mm Varifocal Lens USB Camera Sony IMX179 Sensor,Webcam Support 3264X2448@15fps,UVC Compliant Webcamera Support Most OS,Focus Adjustable USB with Cameras,High Speed USB2.0 Webcams
Yes Nvidia Jetson Nano Developer Kit
Yes Yes Yes 256GB EVO Select Memory Card and Sabrent SuperSpeed 2-Slot USB 3.0 Flash Memory Card Reader

 

The main part that I tried to test were the motor and the driver board, but I didn’t want to potentially burn them, so I decided to wait until our Jetson arrives or when we borrow an Arduino with a potential mini breadboard and potentiometer (to make sure that the current going to the driver and motor are as specified by their specs). 

 

On top of this, I did more research on how to connect the motor and driver together and read more articles which use Jetson to control a stepper motor (although different models and drivers). I also talked to TechSparks about the use of their space. I would have to 3D print a gear on the shaft of the motor and all we need to do is create an STL file and estimate how many grams of 3D-printed material we would need. For the laser cutting part, I am not trained. However, I reached out to a friend outside of this class who is trained for laser-cutting and he agreed to help cut out our acrylic sheet to create our internal gear. 

 

I am currently on schedule. Luckily the parts arrived earlier than we expected even though our team ordered them a few days later than what we planned to. 

 

For next week, I would mostly be outside of the US for spring break. I would probably not be working on this project until I come back. When I come back, I hope to test out the motor and driver and start assembling the platform together so that Jeremy and Alex can see how the rotational mechanism affects the data capturing and see what adjustments we would have to make. 

Chakara’s Status Update for 2/29/2020

This week, I was mainly working on the Design Review. I was responsible for the main platform design and rotational mechanism. On top of working in parallel with other team members on the Design Review Presentation and Design Document, I was mainly responsible for ordering project components. From the Design Review Presentation, we did a tradeoff analysis and ended up with different project components that we need. From that, I started doing research on different suppliers and models of the components we need to get the most cost-efficient ones while getting the most appropriate shipping time. Below is a table of the project components we ordered this week.

 

Ordered Item Quantity Unit Price Total Price Shipping Cost Total Cost Description Expected Shipping
Yes Nema 23 Stepper Motor 1 $23.99 $23.99 $0.00 $23.99 2 Days
Yes 15 Inch Wooden Circle  1 $14.99 $14.99 $0.00 $14.99 Plywood for platform 2 Days
Yes Lazy Susan Bearing 1 $27.19 $27.19 $0.00 $27.19 2 Days
Yes Acrylic Plexiglass Sheet, Clear 1 $9.98 $9.98 $0.00 $9.98 Laser cutting for Internal Gear 2 Days
Yes STEPPERONLINE CNC Stepper Motor Driver  1 $38.99 $38.99 $0.00 $38.99 Motor Step Driver 2 Days
Yes Neoprene Sponge Foam Rubber Sheet  1 $14.80 $14.80 $0.00 $14.80 High-friction surface 2 Days
Yes Adafruit Line Laser Diode (1057) 1 $8.95 $8.95 $8.99 $17.94 Projected Laser Stripe 2 Days
Yes Webcamera usb 8MP 5-50mm Varifocal Lens  1 $76.00 $76.00 $0.00 $76.00 2 Days
Yes Nvidia Jetson Nano Developer Kit 1 $99.00 $99.00 $18.00 $117.00 3-5 Days
Yes 256GB EVO Select Memory Card  1 $42.96 $42.96 $0.00 $42.96 MicroSD card for Jetson with Reader Bundle 2 Days
Yes MicroUSB Cable (1995) 1 $9.00 $9.00 $8.99 $17.99 MicroUSB cable for Jetson 2 Days

I did not include the sources and full names of the components in the table above. For full details, please visit https://docs.google.com/spreadsheets/d/1AP4Le1eVNL51T8ovUJb9YF-H2u47EvRG4AHWqp7ULIM/edit?usp=sharing

This comes up to a total price of $401.83 including shipping. (This is the maximum cost. If we are able to order both items from DigiKey together then it would be $392.84 instead). This gives us at least $198.17 left in case we need other parts. We will still need to order wood for support of the platform later and some of the budget could be used if the laser we ordered doesn’t have the light intensity we need. 

I’m still a little behind schedule since I ordered the parts later than what our team planned for. Our team compensated for this by moving up other tasks that could be done without the parts up the schedule. We’ll be working on those tasks while waiting for the parts to come. 

As my work is mainly related to the project parts we ordered, for next week, I hope to get the parts by Thursday and started performing basic testing on them before leaving for Spring Break. While waiting for the parts during the beginning of the week, I also hope to help Alex write some testing benchmarks. 

Jeremy’s Status Update for 2/22/2020

This week I focused on some of the data pre-processing methods we will use for our algorithm. Note that the things mentioned in the first two paragraphs in this report may not be used for our current method which involves projecting a laser strip. I first looked at the geometry for converting between the data returned from a depth camera to cartesian coordinates. This involved doing some rudimentary trigonometry to get these calculations. The depth camera should return the z-distance to each pixel, but I also accounted for the case where the Intel SR305 camera would return distance from the center of the camera to the pixel instead. We will be able to see which one it is when we actually get the camera and test it on a flat surface like a flat cube. The math computed is as follows:

As mentioned in the previous status update, we were considering using an ICP (Iterative Closest Point) algorithm to combine different scans for the depth camera method and also accurately determine the angle between scans. The ICP algorithm determines the transformation between two point clouds from different angles of the object by using least squares to match duplicate points – these point clouds would be constructed by mapping the scanned pixel and depth to their corresponding 3D cartesian coordinates as shown from the math above. Similar to gradient descent, ICP works best when starting at a good starting point to avoid being stuck at local minima and also save computation time. One potential issue with ICP is that shapes like spheres or upright cylinders would have uniform point clouds across any angle – a good method to help with this risk factor is to start the ICP algorithm using the rotational data from the stepper motor, an area that Chakara has researched on this week. Essentially, we will have the rotational data from the stepper motor and then use ICP to determine the rotational difference more precisely between the two scans, then find duplicate points and combine the two point clouds this way. 

I also looked into constructing a mesh from a point cloud. The point cloud would likely be stored in a PCD (Point Cloud Data) file format. PCD files provide more flexibility and speed than other formats like STL/OBJ/PLY, and we can use the PCL (Point Cloud Library) in C++ to process this point cloud format as fast as possible. The PCL library provides many useful functions such as estimating normals and performing triangulation (constructing a triangle mesh from XYZ points and normals). Since our data will just be a list of XYZ coordinates, we can easily convert this to the PCD format to be used with the PCL library. The triangulation algorithm works by maintaining a fringe list of points from which the mesh can be grown and slowly extending the mesh out until it covers all the points. There are many tunable parameters such as size of the neighborhood for searching points to connect, maximum edge length of the triangles, as well as maximum allowed difference between normals to connect that point, which helps deal with sharp edges and outlier points. The flow of the triangulation algorithm involves estimating the normals, combining that data with the XYZ point data, initializing the search tree and other objects, then using PCL’s reconstruction method to obtain the triangle mesh object. The algorithm will output a PolygonMesh object which can be saved as an OBJ file using PCL, which is a common format for 3d printing (and tends to perform better than STL format). There will probably be many optimization opportunities or bugs/issues to be fixed with this design as it is just a basic design based on what is available in the PCL library. 

I also looked a bit into noise reduction and outlier removal for filtering the raw point cloud data. There are many papers that discuss approaches and some even use neural nets to get probability that a point is an outlier and remove it in that sense. This would require further research and trying out different methods as I don’t completely understand what the different papers are talking about just yet. There are also libraries that have their own noise reduction functions, such as the PCL library among a few others, but it is definitely better to do more research and write our own noise reduction/outlier removal algorithm for better efficiency, unless the PCL library function is already optimized for the PCD data format.

We discussed using a projected laser strip and a CCD camera to detect how this laser strip warps around the object to determine depth and generate a point cloud, so our updated pipeline is shown below.

By next week, I will be looking to completely understand the laser strip projection approach, as well as dive much deeper into noise reduction and outlier removal methods. I may also look into experimenting with triangulation from point clouds and playing around with the PCL library. My main focus will be on noise reduction/outlier removal since that is independent of our scanning sensors – it just takes in a point cloud generated from sensor data and does a bunch of computations and transformations.

 

Chakara’s Status Update for 2/22/2020

This week, on top of working in parallel with other team members to finalize our sensor, I was mainly responsible for the rotational mechanism and platform design. The individual work I did this week can be broken down into 3 main tasks. First is to design the overall design of the rotating platform. The platform would be mainly composed of the motor, a gear, a lazy susan bearing to reduce friction, a platform, a high-friction surface, an internal gear, and a support. The high-friction surface here is to simply help reduce the chance of the object slipping off-center while the platform is rotating. The support here is to give the platform itself enough height so that the motor can be put under. The motor with a gear attached to the shaft will be inside the platform. The lazy susan will be the base, and the internal gear will be attached on top of the lazy susan bearing, and the platform will be attached on the internal gear. The gear on the motor’s shaft will be connected to the internal gear, and when the motor rotates, the platform will rotate with it. Below is a rough diagram of the design. 

For the high-friction surface, I have done some research and reduced the materials down to Polyurethane foam, Isoprene rubber, Butadiene rubber, and Nitrile rubber which our team still has to analyze them together to see which one would fit our requirement best. 

 

After deciding on the rough design, I started choosing material that would work best for the platform itself. The platform will be a circular disc with a diameter of 35cm. I then did some rough estimation to compute the stress that the platform needs to be able to handle. From our maximum input object’s mass of 7kg, the maximum gravitational force that it can exert on the platform is around 68.67N. The lazy susan bearing our team might end up using has an inner diameter of around 19.5cm (or 0.0975 m radius). This would give us an area of around 0.03m2 that would not have any support. I simplified the stress analysis of this design down but it should still give a good estimation of the stress the object would apply, which is around 2300Nm. 

 

After that, I did more research on the material that would be able to handle this much stress, be cost-efficient and easily accessible, and easy to use (cut, coat, etc). I consulted with a friend in the Material Science program and we did some optimization based on cost and mass-to-stiffness ratio to narrow down the number of materials I had to do research on. Below is an image of the optimization graph. Note that we only looked into plastic and natural materials as they are easier to use and more easily accessible. The line in the second image is the optimization line. 

 

After that, I narrowed it down more to 3 materials: plywood, epoxy/hs carbon fiber, and balsa. The table belows shows the tradeoffs between different main properties that would affect our decision. Young’s modulus, specific stiffness, and yield strength are mainly to see if the material would be able to handle the amount of stress the object would exert on it or not. The price per unit volume is to keep this within our project’s contraint. The density is used to compute the mass of the platform (for computing the torque required and to stay within our Portability requirement).

 

Material Young’s Modulus (GPa) Specific Stiffness (MN.m/kg) Yield Strength (MPa) Density (kg/m3) Price per Unit Volume (USD/m3)
Plywood 3-4.5 3.98-6.06 8.1-9.9 700-800 385-488
Carbon Fiber 58-64 38.2-42.4 533-774 1490-1540 26200-31400
Balsa 0.23-0.28 0.817-1.09 0.8-1.5 240-300 1610-3230

 

From here, we can see that carbon fiber is the strongest but is very heavy and expensive and might not suit our project well. Balsa is very light but is not as strong (even if the values here are still higher than the stress I computed, it might be because of the simplified stress analysis I did). Thus, our group decides to use plywood which is strong, inexpensive, easy-to-cut, and not too heavy. With plywood, the maximum mass our of platform would just be around 0.6kg (computed using density and dimensions of the platform).

 

The final part of the main platform design is to choose the right motor for the project. The main 2 motors I looked into to rotate the platform are the servo motor and the stepper motor. A servo motor is a motor coupled with a feedback sensor to facilitate with positioning for precise velocity and acceleration. A stepper motor, on the other hand, is a motor that divides a full rotation into a number of equal steps. To figure out the motor used, I computed the torque required to rotate the platform with the maximum object size. From the density and dimensions of the platform, I computed that the plywood platform would weight around 0.64kg and carbon fiber would be around 1.2kg (I still accounted for the heaviest material and strongest material in case of a change in the future). From that I computed the moments of inertia which is around 0.024kgm2. For the input object, I used maximum size and different dimensions and shapes to cover most main and edge cases, the maximum moments of inertia computed is around 0.1575kgm2. Thus, the total maximum moments of inertia is less than 0.2kgm2. To get the torque, I also estimated the angular acceleration needed. From Alex’s computation, we need at least a rotation of 0.0033 rad per step to capture enough data to meet our accuracy requirement. Assuming that 10% of the time requirement, which is 6s, can be used for data capturing (so that we have more buffer for the algorithmic part since we don’t exactly know how complex it would actually be yet), we would get that the angular velocity is around /3rad/s. Assuming we want our motor to be able to reach that velocity fast enough (0.5s), we have an estimated acceleration of 2.094rad/s2. From here, the estimated torque needed to rotate the platform is around 0.4188Nm. Below is the rough computation made. 

Since we need a high torque and from our algorithm we would need an accurate step, the stepper motor is preferred. The two stepper motor I looked into are the NEMA 17 and NEMA 23. NEMA 17 has a holding torque of 0.45Nm, and NEMA 23 has a holding torque of 1.26Nm. Even though NEMA 17 seems like it might be enough, in my computation, I neglected the friction which would drastically affect the torque the motor has to supply. Moreover, I also neglected the energy that would be lost through using the internal gear to rotate the platform. Since NEMA 23 is not that much more expensive, I believed NEMA 23 would fit our project best. 

I’m currently still a little behind on schedule but I caught up a lot. Learning everything about stress, torque, and material took up most of my time for this week and computing different values and making sure the simplifications are not over-simplified were also a difficult task. I am a little behind in that I expected that I would have the gear and design fully drawn with dimensions written correctly. I would do that by putting in more work before the design reviews.

 

For next week, I hope to find all the specific parts for purchase and order them. I would also like to work on the design document. Once all the material and components arrive, I would start assembling the platform. 

 

Team Status Update for 2/15/2020

For this week, we did a majority of the work as a team. After getting feedback from the Proposal Presentation, we realized that our user-story was too vague and that some of our requirements were not as clear and quantifiable as they could be. As a team, after doing more research, we narrowed down the scope of our use-case to just archaeological documentation and refine our requirements to fit our use-case more. For example, we made the error rate for accuracy depends on the object size dynamically instead of just static measurements. We redefined our usability requirement to include the input object size and weight limit and redefined our time requirement to be one minute. We also refined some other requirements. As a team, we also discussed different sensors we researched on to use for the project. 

Currently, the most significant risk we have right now is that we have not finalized the type of sensor to use yet, so we might be a little behind the schedule in terms of ordering parts. We are managing this risk by starting other tasks that could be done in parallel such as researching more on the common pipeline generally utilized in 3D Mesh reconstruction from raw depth data. We also assigned everyone on the team to do more research on different sensors available. We first agreed on using Intel real-sense depth camera (RGB-D camera using coded light), but was suggested by Professor Mukherjee to look into 1D/2D laser array/LIDAR sensor which could be more accurate and time-efficient. All of our team members are working on this to be able to finalize the sensor by this upcoming week and get back on schedule. Another risk factor we have is our lack of expertise in mechanical engineering and robotics. The rotational mechanism and platform design seem to be more complex than what we initially thought. The rotational mechanism is a crucial part of our system no matter which type of sensor we use. This risk is being managed by letting Chakara take care of the part and he only has to worry about this part for the upcoming week. We also started seeking advice from someone with more expertise in the area. 

As mentioned earlier, there were some changes made to the requirements and use-case. The changes were necessary for us to be able to narrow down the project scope to be able to finish it in the given period of time. They were also necessary since we need requirements that are more clear and quantifiable to use them as metrics. These changes cost us time from last week but made our project goals and scope clearer which will benefit us in the future. 

Below is the link to our updated schedule. Or you could also refer to our “Project Schedule” section.

https://docs.google.com/spreadsheets/d/1GGzn30sgRvBdlpad1TIZRK-Fq__RTBgIKN7kDVB3IlI/edit?usp=sharing