10/26/19 Team Update

Enes Palaz Status Update

  • What did you personally accomplish this week on the project?

Tested and verified the code logic for making DAC code sleep until next points time is ready. I tested my code by generating square waves that were buried inside ILDA file format so observing aimed frequency verified that my calculations for timing between points were working. Found out the bugs in our ILDA structure with the help of Eliana and Jake. We suspect that format for ILDA files are in big endian and my initial assumption required testing with big endian changes made on my code.

  •  Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

We are still on schedule for integrating software modules for next weeks demos.

  • What deliverables do you hope to complete in the next week?

I am planning to be done with the DAC parts and successfully project an ILDA frame generated by our own software. Also planning to start some filtering on edge detection data so we can remove points from a frame if it contains more than 1200 points.

Jake Zimmer Status Update

  • What did you personally accomplish this week on the project?
    • Constructed a rig to test the laser output from Enes’ DAC program with some test ILDA frames. I have included images of both the rig and the laser output below in the team portion.
    • Finalized and ordered the PCBs for the system.
    • Worked on the BOM for parts ordering.

 

  •  Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?
    • On schedule. I knew that getting the boards ordered would take some time and it is estimated to take less time than I expected.
    • As I said last week, I have also been working on writing some firmware for the STM32 microcontroller that we have decided to use. By writing this in parallel on a dev board, I have ensured that we should continue to be ahead of schedule for the near future.

 

  • What deliverables do you hope to complete in the next week?
    • The boards should arrive at the end of next week and I will assemble and test them then.

 

Eliana Cohen Status Update

  • What did you personally accomplish this week on the project?
    • Integrated Enes’ DAC/ILDA libraries, got them to compile with makefiles on raspberry pi, discovered new memory interface bug between software blocks.
    • Improved speed performance of Opencv frame reading by figuring out Camera resolution bug with Enes’ assistance [~50ms contour to ILDA frame conversion time, and ~30ms video to frame conversion time in multithreaded parallel computation, so our speed performance is now safely accomplished]
    • Tested ILDA output on laser hardware along with Jake and Enes
  •  Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

On track, though I need to finish up the memory copy bug, but should be able to get the ILDA to DAC pipeline completely finished by next week, which will allow us to test live frames on our laser hardware. We still need to work on figuring out some bugs/calibration with our physical hardware system, so that might take a priority.

  • What deliverables do you hope to complete in the next week?

By next week, I should have completed:

  1. Get a demo-ready implementation together for the hardware system
  2. Fix the C++ Memory copy bug for the ILDA->DAC libraries.

Team Status Update

  • 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? 

Laser being too thick, heat produced by the hardware are both concerns that degrade the quality of our image. Since laser thickness makes it harder to see a decent output, we need to be more careful with our laser selection for the future parts of our project. While doing initial testing, we also found our hardware produced a significant amount of heat (< 140 degrees), so we included a heavy-duty fan to reduce temperature. We recognize going forward we will need to install heatsinks, so we will begin part selection for heatsinks for this project.

 

  • 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? 

Inclusion of heatsinks, potential fan, to reduce chances of damaging our hardware. This will increase the cost of our project slightly, but it isn’t a difficult or extremely costly change to make.

 

  • Provide an updated schedule if changes have occurred. 

N/A

 

10/19/19 Team Update

Week of 10/19/2019

Enes Palaz Status Update

  • What did you personally accomplish this week on the project?

This week I completed designing and coding the DAC controller. Test setup for the code can be seen below. A screenshot of header file with function definitions can also be seen in the second image posted below. A screeshot of oscilloscope readings of a square wave generated is added too in which we tested the proper communication speed to get 12,000 points per second. Currently, I am still testing it to verify our timing constraints are satisfied and triggers happen simultaneously.

Test Setup for DAC
Dac60508.h
Square Wave Test
  •  Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

My progress is behind by 2 days because of the problems that I had while testing my code. Fortunately, I was able to debug my code to make it work properly. So, my schedule for DAC is moved by 2 days since I needed 2 more days of testing. This will push our integration with double buffer by 2 days. We have enough time to move integration by 2 days but I will try to spend more time on integration to finish it earlier than what we planned for.

 

  • What deliverables do you hope to complete in the next week?

My deliverables for next is the integration of double buffer and DAC control system that will read from double buffer and automatically draw a test set of frames and points.

Jake Zimmer Status Update

  • What did you personally accomplish this week on the project?
    • I got familiar with the STM32 development environment. The IDE is essentially a reskinned Eclipse IDE with some really near extra features like pin feature configuration. The SDK has some really neat features that make me confident that this was a good choice of microcontrolller and make me want to use it in future projects.
    • I finished the board design and routing and the schematic is currently under review by Elliana. The finished layout can be seen below:

      Board Design
  •  Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?
    • It is a little behind due to needing to coordinate schedules during this busy time of year in order to do the schematic review. To rectify this, Eliana and I decided to simply have her review the board without myself present.
  • What deliverables do you hope to complete in the next week?
    • Next week I hope to finally order the boards and have some of the code running on a dev board. The boards should arrive within two weeks but I will develop the firmware in parallel as to mitigate delays.

Eliana Cohen Status Update

  • What did you personally accomplish this week on the project?
    • Began reviewing Jake’s schematic designs
    • Further improved speed conversion time of OpenCV images by distributing the image conversion into multiple threads 
    • Updated speed conversion time to include time to interface with camera [From around 250ms conversion time to 70-120ms conversion time, the differences are due to number of features in a frame, which will be capped at 1.2k points allowing us to reach our under 100ms conversion time goal.]
Speed Testing

  •  Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

A little behind due to preparing for exams, most of this work has been accomplished over the 3-day weekend. I should be back on track after focusing on finishing up more image optimizations and ready to test out the hardware next week.

  • What deliverables do you hope to complete in the next week?

By next week, I should have completed:

  1. Work with Enes to test out ILDA images on the DAC systems
  2. Test DAC board with laser systems
  3. Work on integrating with Enes’ software

Team Status Update

  • 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? 

Image Processing time is still a major risk, and there are risks with producing our circuit boards in that the boards may have some minor design errors. These are being mitigated through reviews, and also the ability to ‘botch wire’ boards to fix minor mistakes. The time for this is already planned into our schedule, so that we have time to fix our boards. We’re also working on integrating the systems together this next week so that we have more time to fix integration problems as they arise.

  • 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 new changes.

  • Provide an updated schedule if changes have occurred. 

10/12/19 Team Update

Enes Palaz Status Update

  • What did you personally accomplish this week on the project?
    • Finished designing the interface for DAC module
    • Took a slack period for a midterm and homework for most of the work.
  •  Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?
    • I am on track with my gantt chart expectations
  • What deliverables do you hope to complete in the next week?
    • Finishing the code for controlling DACs
    • Testing DAC code with the galvanometers

Jake Zimmer Status Update

  • What did you personally accomplish this week on the project?
    • Designed the safety subsystem and implemented it in the schematic and PCB.
    • Redesigned the PCB to be a Raspberry Pi Hat.
    • Implemented changes to the DAC circuitry based on experimentation.
  •  Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?
    • I am on track although I expect that actually programming the safety subsystem will take longer than I allocated due to getting set up with a new toolchain.
  • What deliverables do you hope to complete in the next week?
    • I will have a formal design review with Eliana Cohen.
    • We will order PCBs and parts.

 

Eliana Cohen Status Update

  • What did you personally accomplish this week on the project?
    • Finished implementing the C++ implementation of the frame to ILDA converter, and benchmarked performance. Time to convert an image is now in the range of .1s – .08s, which is within specs for our conversion time. It might be nicer to get an extra factor of safety in regards to computation time.
    • Researched other improvements to make with the C++ implementation, and found further speedup could be accomplished via preallocating arrays rather than using vectors. 
    • Applied some minor code fixes to the C ILDA double buffer code.
    • Set up makefiles for compiling whole project and integrating the C++ and C buffer code together
    • Tried setting up the project on the raspberry pi hardware, but encountered some problems with configuring opencv. Currently investigating why certain environmental variables are having difficulty finding the built opencv libraries, but wasn’t able to figure this out by the end of the week.
  •  Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

On track, though the problems I encountered with getting the OpenCV files to work on the raspberry Pi were unexpected. These aren’t really problems with the code, so I was still able to accomplish my deliverables for finishing up the libraries, and Enes was willing to give me some extra help fixing the environmental variables as I’ve been stuck on this for a couple days. It should be a simple fix, so it shouldn’t impair the schedule by too much.

  • What deliverables do you hope to complete in the next week?

By next week, I should have completed:

  1. Review the Safety Subsystem Hardware with Jake
  2. Start working on and researching safety subsystem implementations. As I have exams next week, I’ll mainly focus on initial research and high-level design.

Team Status Update

 

  • 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? 

No new risks.

  • 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? 

The Frame to ILDA library was converted to C++ instead of Python, as discussed in the previous status update.

 

  • Provide an updated schedule if changes have occurred. 

None

10/05/19 Team Update

Jake Zimmer Status Update

  • What did you personally accomplish this week on the project?
    • This week I did an in depth evaluation of the feasibility of the PID subsystem. PID was never a core goal of the project because the galvanometers come with their own PID controllers and so making our own was just an attempt to learn more about analog PID. The galvanometers use a pretty interesting method of providing feedback to the PID controller. The galvanometers use a light source, blocking element attached to the reverse side of the mirror output shaft, and two photosensitive elements to create a fast feedback system. After getting the device up and running with some basic test patterns and measuring the output I realized that there appears to be some non linearity in the system and that mitigating the effects of this would be incredibly time consuming. Therefore, my efforts in the future will be focused on other areas of the project.

 

  •  Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?
    • My schedule has drastically changed this week. I was slightly behind on the PID part of this system but now have changed focus to work on the required parts of this project.

 

  • What deliverables do you hope to complete in the next week?
    • In the next week, I hope to have finished a raspberry pi sheild for the DAC component and finalized specification and detailed design requirements for the safety subsystem.

 

Enes Palaz Status Update

  • What did you personally accomplish this week on the project?
    • This week, we received our DACs and breakout boards for DACs. I worked on soldering the DACs on their breakout boards which was challenging due to their size (3mmX3mm) and got help from Jake for creating protoboard steps which would allow me to create a reliable test bench on which I can test my code actively.
    • After all the soldering work was done, I worked on setting up a RaspberryPi 3 for testing DACs since Eliana has been actively working on performance improvements on our RaspberryPi 4 and we needed another Raspbian environment to develop in parallel.
    • Lastly, I coded initial test code which tried to read DEVICEID register from DAC and worked on debugging the setup with an oscilloscope and logic analyzer. I was able to successfully communicate with the DAC but hardware setup needs improvements to prevent noise on power and data communication pins.

 

  •  Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?
    • Even though, issues that I had with the DAC communication coding extended the completion time for DAC subsystem, we already had some extra time that was allowed for these situations so we will just move the deadline further and try to finish other parts in shorter time so we can still keep those safety days that we have.

 

  • What deliverables do you hope to complete in the next week?
    • Next week, I am expecting to finish testing of the DAC and prepare interface for the actual code that will update DAC channels according to ILDA point structure. I am also expecting to start coding the part that reads from ILDA points and updates all 5 channels of the DAC and triggers those in synchronization.

Eliana Cohen Status Update

  • What did you personally accomplish this week on the project?
    • Did research into speeding up the Python frame to points library. Initially I thought it’d be as simple as translating the contour object to point library into C, but then it turned out that writing python-wrapped C code is much trickier than anticipated due to the contours data structure not having any equivalent in C. 
      • After an initial attempt at the Python-wrapped C library, I investigated CPython’s ability to speedup C code. However, due to the use of numpy-arrays of variable size in the Contour data structure, I couldn’t achieve more than 4x speedup (~0.2 seconds to generate a frame) as I couldn’t define the numpy arrays at a fixed size, so CPython couldn’t optimize more of the code.
      • I then investigated Pytran for its integration with numpy arrays and its improved optimization as a result, but ran into similar trouble as the numpy arrays’ length weren’t decidable by compile-time.
      • After exhausting all of these options, I decided to rewrite these libraries entirely in C++ as it became evident that trying to work around the inefficiencies of Python was too time consuming. I’ve finished rewriting about half of the libraries, and should be able to produce a speed test of the C++ system by Sunday.

 

    • As we had our galvos and laser hardware, Jake and I tried to test out the system through a standard test-ILDA file and the frame-to-point library’s generated ILDA file. We purchased a parallel port to attempt to write the file to the board, however, the control board lacked documentation or drivers. After researching online and attempting to forcibly write the ILDA file to the board, we were unable to transfer any ILDA files to the test board. We concluded that we should wait for our DAC and DAC library so that we could bypass the black-box test board and instead write analog signals directly to the galvos. 
  •  Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

Behind, as this Python speedup problem was much more complicated than I initially expected. However, this was a necessary problem to tackle, as the 10fps frame to point conversion is part of our requirements. I’ll have this finished by Monday, and since the DAC library isn’t finished yet, this library will still be ‘on time’ relative to when it needs to be done to test it with the other parts of this project. This also applies to the double-buffering library, but testing the double buffer library requires a complete Python-to-Points library.

  • What deliverables do you hope to complete in the next week?

By next week, I should have completed:

  1. Finish the C++ new version of the library and test it on the raspberry Pi. This will also involve setting up makefiles for easy testing.
  2. Finish the double buffer library and integrate with the new C++ library

Team Status Update

 

  • 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? 

 

Reducing the computation time to calculate contours in a video frame is required to meet our requirement of being able to display 10fps of live camera feed. Earlier in the week, we discovered that our python implementation was too slow, and sought other optimization programs to compensate for it. Trying to use python in the project was far too slow, and C was unable to handle some of the more complex data structures passed into the C interface by python, so we ultimately decided to rewrite our old code in C++. Most likely this will finally fix our framerate issue for this part of the project, we’ll need to research more thorough code optimization.

 

Since last week, we substantially reduced the risk of the PID feedback subsystem by doing an in depth analysis of the photocell-led section of the galvanometers. The feedback looks promising but there are still some minor concerns about getting this nonlinear system to perform adequately.

 

  • 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? 

 

Since the PID controller is a significant risk to the project, we already have adequate PID controllers that came with the galvanometer, and PID control was never an explicit requirement nor core function of this project, the PID subsection is being made a stretch goal for this project. This means that we will focus on the DAC and safety hardware subsystems for the circuit portion of the project and leave the custom PID controller portion as a task if time allows.

 

We’ve begun to rewrite our old python libraries into C++ due to the aforementioned framerate issue. The main cost of this is the time required to do this, as rather than work on new libraries we’ve had to rewrite old ones. However, we’ve learned to avoid python and other higher-level languages for performance reasons, so for the rest of the project we should stick to C and C++ to avoid these sort of porting issues.

 

Since we switched to C++ for our whole pipeline, we decided to use go forward with the WiringPi library for SPI communication between RaspberryPi 4 and our DAC. This wasn’t exactly a design change but a key choice in our development.

 

To refine another requirement and highlight that both the frame-processing and frame-displaying should be at 10 frames per second, we’ve added this requirement:

 

  • The laser shall draw frames at 10 frames per second because it is proximal to the classic animation framerate of 12 frames per second (which is proven to look visually fluid) while also being an easy divider of 30 frames per second, the modern framerate.
  • The system shall process camera frames into DAC-readable points at 10 frames per second as well. Therefore, the hardware should not be stalled by the processing time of the frames-to-points library.

 

  • Provide an updated schedule if changes have occurred. 

 

Due to unexpected difficulty in optimizing the python code and then eventual decision to switch to C++, the frames-to-point library schedule has been delayed.

The part of this project devoted to PID has now been changed to the DAC and Safety Subsystem.

Captone_Team_A2_-_LaSEEr-10-05-19