Week 30 - lglik/Portfolio GitHub Wiki

04/08/19 - 04/12/19

Day One:

Today, I continued to work on the simple GUI. I finished copying over the array of magnetic tree buttons which took quite some time. I added in a button to go between the simple GUI and the advanced GUI. I made the project go to the simple GUI first since I reasoned that it would make more sense to have someone decide to do something more advanced than to not understand a complicated GUI. I added in four mock buttons for preset shows. I did not actually program any shows but just created the buttons so that I would have a screen that would work as a proof of concept. Once this was done, I decided to show my idea to Mr. Shaer. He agreed that my simple GUI would be much easier to use and would create a more visually pleasing effect. However, he said that it was more important to prioritize the level to which the user can interact with the project. He said that the only thing he wanted a user to be able to do with the project to be designing their own show. He directed me to not have a simple GUI but instead work on streamlining and improving the more complicated GUI.

The mock buttons on the simple GUI screen

Day Two:

I changed the default screen to be the more complicated GUI and removed the simple GUI button. I then started to plan on how to completely overhaul the GUI for the design scene. I displayed the GUI on the monitor and then used a dry-erase marker to map out the changes I wanted to make. I decided to remove the All On and All In buttons, because, while they are useful, I could remove them without actually losing any functionality. I also removed the randomize button since a random scene could be made quite easily by a user if they just move their finger randomly around the screen. I had never really understood the purpose of the save button since a user would always want to save their design, and if they didn't they could use the delete button. Therefore, I bound the functions associated with the save button, to the next frame, previous frame, and play show buttons. I also removed the reload frame button which as far as I can tell, did not do anything.

Day Three:

An issue I discovered while redesigning the design scene GUI was that the states of the trees were not being saved correctly. After some experimentation, I discovered that the tree number associated with each tree would decrement by one when the frame was first saved. Unless new changes were made, this warped frame would not change further. I spent quite some time trying to figure out what was causing this which was hard to do since over half of the code for the project access and/or modifies the frames. Eventually, I was able to track down the cause to three conditional statements, where the code they triggered would subtract one from the treenumber when copying the frame from a temprory array to the permanent array. I did not write this could and there were no comments so I have no idea why there was a -1 there and if it ever served a purpose. Once I removed the -1s, the was no longer an issue with how the frames were saved.

Day Four:

The discovery of the decrementing bug with when frames are saved brought to light a much larger issue. The code for the project is very long, and in many places, flawed, unnecessary or redundant. I had been putting off reformatting and rewriting a lot of the code for a long time. Nathan finally convinced me today to actually do it. I started off by removing code that did not do anything at all. For example, the code for all of the buttons I had removed and other code that Pycharm informed me would never be called. Some code, like that for the popup windows, I decided really wasn't necessary. There were over 300 lines of code dedicated to telling the user that they could not delete the current frame if there was only one frame. I also made it that so that instead of there being a magnetic tree button widget that would be used to make arrays and then displayed in many different scenes, I made a forest class that contained the code for the trees and could be given parameters to determine what pattern and how many buttons to display. I also moved some of the classes such as that of the forest and the design scene to a new file called designer that would deal with all things relating to designing the show and interacting with the hardware.

Day Five:

I rewrote the ramp.py file that controls the motor controllers for the electromagnets. I got rid of much of the code by having each tree have a position, goal position, and velocity value stored in an array. The calls to change the state of the tree would now simply change the goal position. Every set interval of preset time, each try would move a set amount towards their goal position if they were not already there. Besides shortening the code, these changes also made the trees all change seemingly at the same time. At least that's what it looks like anyways. I decided to also create a way for the project to timeout to save power and ensure that a new user would start interacting with the project on the design scene. I created a new screen class called timeout that had a on_touch method that would reset the variable that stores the time since the last touch. If the value stored in this variable exceeds a preset value, other code could be triggered. For now, I was not sure what the timeout code would do when triggered so I just made it set the current scene to be the start scene. To make it so that this timeout class is active on every screen, I made each screen extend the timeout screen.