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:
- 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.
- 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
