Team’s Status Report for April 30

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?

Our most significant risk is not putting adequate time into the presentation of our project. It is easy to spend all our time making marginal improvements on the device, but at this point, our system is mostly finished. The poster, demo, and final report are substantial amounts of work. It is important that we begin working on these assignments in parallel with our current testing and adjustment.

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

After the final presentation, Professor Savvides advised us that one camera would be sufficient for our proof of concept and that we shouldn’t waste resources adding the second camera. This update will save us time and money down the stretch.

Provide an updated schedule if changes have occurred.

  • Sunday-Tuesday: Poster + Test
  • Wednesday-Saturday: Report + Demo

Team’s Status Report for April 23

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?

We are finishing integration this weekend and working through testing. At this point, our biggest risk is not being able to upgrade our system to two cameras. Because the cameras are not in the same location, an additional alignment code will be necessary. This may be difficult to get operational. As a contingency plan, we can stack the two cameras together. One can be permanently zoomed out (for tracking) and the other can zoom in (for photographing). This approach is simpler and would not be much less effective.

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

After speaking with one of Professor Savvides’ Ph.D. students, we realized that using two MIPI-CSI cameras on our version of the Jetson Nano is not possible even with our multi-camera adapter. This is because the camera stream must be terminated before another camera can be accessed. We found that the best way to troubleshoot these problems is by purchasing a USB IMX219 camera. This is the same model we currently have, so our code will be compatible, but the USB input can be streamed simultaneously to the MIPI-CSI. The camera will fit on our current pan tilt system and is only $35 on amazon. We will cover this expense ourselves and can get two-day shipping.

Provide an updated schedule if changes have occurred.

We will add our second camera this week after our initial round of testing. This will go under the ‘modifications’ time previously allocated.

Team’s Status Report for April 16

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?

At this point, we have two major risks. The first risk is that multiple pieces (detection, tracking, hardware, editing) of our system fail to meet the quantitative requirements. If this is the case, we will not be able to team up to make final system revisions. We would have the capability to work separately on adjustments, as this is how we began work this semester. However, this would not be the ideal situation and could possibly complicate a second integration round.

The second major risk is adding a second camera to our system. This process will hopefully go smoothly, but with the difficulty we faced getting the single-stream working, there is a possibility that adding a second camera could be equally challenging. If it becomes too difficult to integrate the second camera, then we should focus on getting the best possible single-camera system. Our goal is to have a strong and functioning proof of concept, and while not ideal, this can be accomplished with one camera.

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

No changes were made to the system.

Provide an updated schedule if changes have occurred.

No schedule changes.

Team’s Status Report for April 10

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?

Integration, unfortunately, took longer than expected, with errors in the camera compatibility and control. For example, the provided library for using the camera had errors that took time to debug. Now that we have a better understanding of these challenges, we should be able to finish this task in the next week. Our largest current risk is getting caught up on tasks that are not essential to meeting MVP and having a functioning robot. For this reason, we reworked our schedule. We have done sufficient individual work in the areas of detection, tracking, and editing. Now we will work together to get an operational system. We have also decided that our initial plan with multiple rounds of testing and development was too ambitious for the task we have . For this reason, we have reorganized our schedule to focus on meeting MVP.

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

No changes were made to the system.

Provide an updated schedule if changes have occurred.

Week of April 10: Finish Integration

Week of April 17: Finish Integration/ Start Testing

Week of April 24: Finish Testing / Start Adjustments

Week of May 1: Finish Adjustments and Work on Final Report

Team’s Status Report for March 26

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?

The risk that we presented last week, failing testing in multiple areas, still remains our largest risk. Additionally, we found that the integration and setup needed for testing are larger than expected. It is vital that we are able to integrate detection and tracking into the robot this week. Also, we need to finalize the plans and materials for testing this week as well. This way we will test in time to make adjustments by the project end. We have the slack to adjust if this goal is not accomplished, but this is a very doable goal.

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

No changes were made to the system. However, we realized that we will have to print color images for testing. And ideally, these images may be larger than the paper size to replicate some animals. We can cover some of these costs with our printing quota. For the larger printouts, we need to explore options on campus but may need to use personal funds for off-campus printing services. Our definitive answer will be provided when we finalize testing plans.

Provide an updated schedule if changes have occurred.

No schedule updates.

Team’s Status Report for March 19

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?

With setup complete, the largest initial risk for the project has been avoided. Now the largest risk is performing poorly in multiple areas in initial testing. Our schedule is designed such that we perform initial testing ASAP, and focus our remaining time on the design requirements not met by the initial setup. With testing occurring over the next two weeks, we will receive important information on how to proceed with the rest of the project. The biggest concern is that all 3 areas of our project (detection, tracking, and editing) fall short of their quantitative requirements. If this is the case, we will each need to continue working on our area of the project. This will limit our ability to team up on the issues.  We should still be able to manage this situation as there is one person per area. However, as a last resort plan, we will focus on detection and stationary photography first, tracking second, and photo editing last.

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

Our original plan was to have our robot’s camera platforms be square with rods in the corners. However, when building the tower, we realized that the camera, when vertical, would bump into the rods. To fix this we replaced the square platforms with long rectangles. Our initial material purchases were sufficient for this adjustment, so no additional costs were created.

Provide an updated schedule if changes have occurred.

No schedule updates.

Team’s Status Report for February 26

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?

The largest risk to the project is not finishing the setup on time. We made satisfactory progress this week, but it is essential we finish in the upcoming week. To achieve these goals we are parallelizing the tasks needed. Sid is working on the CNN, Fernando is working on the Jetson/Camera software integration, and Justin is working on the physical setup. The biggest risk area is the physical setup because our expertise is not on woodworking or manufacturing and a lot can go wrong with the hardware. If worst comes to worst we can begin testing with a temporary set up the following week.

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

During this week we began to design the physical stand for our robot. Given this class’s focus is ECE, we overlooked the importance of this step. We realized that the process of stacking 2 cameras and a jetson vertically would not be as trivial as we thought, so we created sketches and bought materials for our design. The material costs were inexpensive and we covered them with our personal funds.

Provide an updated schedule if changes have occurred.

No schedule updates.

Team’s Status Report for February 19

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?

The most significant risk to our project is not finishing the physical setup. We faced a delay ordering our parts, so we already plan to use our setup slack. Therefore, it is of the utmost importance that we work diligently this week. We made adequate progress on our software this week, so we should be ready to test the following week. If setup takes longer than expected, we can likely complete the testing in half a week, though a full week is dedicated.

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?

We decided to change the cameras we were using as part of the system.
We originally planned to use 12MP cameras however decided to switch to 8MP cameras instead. We also decided to purchase a servo motor base for the PTZ system (pan tilt zoom) separately as opposed to an assembled system with the camera. These changes were suggested to us by our mentors as they resulted in a reduction in the expenditure on these parts of the system. This idea made sense since we did not have to actually need a great camera to photograph animals and needed one capable of photographing test subjects and since assembling the setup ourselves would be a more economical option too. Because of this, we get more wiggle room in our budget and space for any expenditure that may be needed during the later stages of the project.
We also discovered that our jetson nano had only one MIDI port, so we added an extra adapter to our plans. This part was ordered with the cameras and only cost $50, so we still have extra budget to spare.

Team’s Status Report for February 12

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?

Our most significant risk at the moment is falling behind on the initial project setup. Having the camera stand functional is essential to our plan of having multiple rounds of development and testing. We recently received a message from Professor Mukherjee suggesting some changes to our camera order, so our order has not been finalized.

Our parts should arrive a week after our original plans, but right now we still feel confident in our ability to finish the setup phase on schedule. We gave conservative time estimates on the setup tasks (almost 2 weeks), and have extra setup slack. With that being said, we must finalize the order update ASAP and be extremely diligent over the next few weeks.

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?

We have decided to change the camera from 12MP to 8MP. This reduction will not significantly impact any of our software plans. We are not able to produce a professional quality camera system within our budget, and this choice will allow us to still complete a proof of concept while saving some of our budget for an emergency.

Provide an updated schedule if changes have occurred.

Our schedule will be slightly modified by this setback. We will finish the initial algorithm design while the parts are shipping, and push the setup tasks into the designated setup slack.