Team report:
The most significant risks right now that could jeopardize the success of the project are a lack of clarity regarding design and requirements. Since our project has changed significantly over the past couple weeks, we are currently trying to re-establish clear requirements and design specs with the help of our TA, Zilei. We have other project ideas as contingency plans, but at this point, a pivot is pretty much out of the question, so we really have to make this idea work. Many changes were made to the existing design of the system, which were necessary to establish a use case for the project, but these changes do not significantly increase our bill of materials for the project, other than adding another Pi to our parts order. We are working on defining more requirements specific to our finalized use case of a scalable security camera system.
The other main risk is FPGA bring-up, which needs to be taken care of as soon as possible so we are confident that our platform is set up and our toolchain works. We will be starting to work on this most likely at the end of this week, and our goal is to avoid getting stuck by using some of the Altera/Xilinx demos and application notes to get over any bumps in the process. If we get stuck, some TAs have experience with both platforms and could offer some guidance as to how to get everything set up efficiently.
To more concretely define what our system will do, we’ve been spending the majority of this week researching algorithms that we feel comfortable implementing in an additive manner so we can visually confirm our progress, and we’ve found a good candidate to be Canny edge detection. The algorithm is nontrivial, but it is also a well-defined step-by-step algorithm that we can implement each piece on top of the previous after confirming functionality of the current pipeline. We are doing final research this weekend to finalize our algorithm, so that by Monday we can update our current design documentation. This will likely impact our schedule a bit, so we have adjusted that as necessary to accommodate the timeline for the algorithm. We will also be finalizing our decision to go with Wi-Fi or Ethernet based on how complex and troublesome getting Wi-Fi could be. Once these two decisions are finalized, we’ll be moving on to refining our block diagrams from our proposal presentation and having a much more fully defined project so we can begin the initial work. With the video algorithm decision made, we can start properly design our FPGA implementation, estimate development time for each part of the algorithm, determine how we will communicate data and control between programmable logic and the core on the board, etc. These are a lot of the unknowns that both we were aware of and that the TAs and professors brought up when discussing our project. We have updated our schedule accordingly after this week’s progress. Most tasks have been pushed out a bit due to the focus this week being on solidifying our project’s use case and processing functionality. Starting this week, we hope to be focusing on the actual tasks we have laid out for this project.
Brandon:
For the first week of work on the project, our team was very lost as to what direction to take with our project. After presenting our project proposal, we were met with pretty intense pushback, and several questions arose that we were unable to answer. I believe the biggest issue was that we had misunderstood the intentions of this project – while we thought it would be adequate to conduct an exploration of FPGA computational power, in reality, we’re required to have a clear use case that we are able to demonstrate. Thus, instead of working on our project this week, we spent all of our time discussing and brainstorming all the issues with our current idea, and considered pivoting toward a different project. After talking to various TAs and professors, we finally nailed down our project idea, but since it’s changed, we haven’t completed any tangible work yet on the actual project. This means that to be completely honest, I don’t have any progress on my part of the project. We’re still in the refinement stage.
Obviously, this means that I’m significantly behind schedule, and our team is also significantly behind schedule. I’m aware of this, and am prepared to invest a significant amount of time this upcoming week to catch up. I have to implement basic UDP functionality along with full video frame send functionality. These are the deliverables I hope to complete in the next week.
Ilan
This week my team and I were going over feedback from the proposal presentation, and ultimately we decided to stick with our current system architecture and refine the use case to target security camera systems. To make the video processing portion more concrete, I spent quite a bit of time researching different algorithms, analyzing their feasibility, and seeing what numbers are reasonable for different algorithms and platforms. Based on this research, a lot of machine learning algorithms are most likely too complex to fit in with the rest of our project and our skillset, but a more tangible computer vision algorithm is likely feasible. The main candidate I’ve found so far is Canny edge detection, which is used as a step to more complex CV/ML algorithms like object detection. As a result, I thought this would be a good candidate since it’s not extremely simple, but also does not bring with it the complexity of a neural network or another complex algorithm. Additionally, the algorithm has 5 main steps, which we could implement one on top of another as we progress with the rest of the project. This is good since none of us have strong backgrounds in machine learning, so having an algorithm that we would be able to visually inspect for correctness is beneficial.
In addition to researching the specific computer vision algorithm we will implement, I also looked at the FPGA boards we have available and did some research to determine what board would be the best choice for us to work with. To make it easier to implement the software baseline implementation, it might make more sense for us to use an SoC board rather than the original Virtex 7 + MicroBlaze architecture we originally intended in an effort to reduce bring-up time and unblock Brandon on the server-side implementation. I worked on comparing between the Zynq board and the DE10-Standard, but still haven’t found a clear reason to choose one over the other.
Due to our proposal presentation feedback causing us to reconsider and brainstorm a bit, we are slightly behind schedule, but I plan on acquiring hardware as soon as possible this week and finalizing the algorithm decision. Once that is done, I’ll be immediately moving to bring-up by running through some of the demos and documentation to get things working. That will be my focus for this week, so that we are sure that our hardware works and we have all of the toolchain and infrastructure set up when we need it in a few weeks. Hopefully bring-up will go relatively smoothly, and Edric and I can take a few days to properly design the programmable logic portion and the interfacing between the logic and the rest of the system.
Over the course of the next week, I plan on finalizing the video processing algorithm we will implement and updating our documentation to reflect this change accordingly. Additionally, I’ll be submitting a request for hardware and trying to set up everything (less of a deliverable, but more of a prerequisite for future deliverables).
Edric
<insert here>