"Software is like entropy. It is difficult to grasp, weighs nothing, and obeys the second law of thermodynamics; i.e. it always increases."
-Norman Ralph Augustine
I’d like to clarify something that is probably in a lot of your minds. You’re probably thinking “Will, your description of your third space is somewhat brief, isn’t there other things that are happening there? After all, you spend nine hours there.” Unfortunately, the answer is that no, I do not do much else. The swarm lab is a graduate research lab, for better or for worse, and that means that people are working at their desks, progressing on electrical designs. I'm coding the entire time, or I'm planning how I'm going to code something. So pretty much, I don't have much to talk about besides technology overall and the project itself. I wish I had more media to show on my blog, and I've been meaning to get some images of the lab and my coworkers there, but someone has been gone every single time I've been there. I'll be looking to get a photo with everyone.
On Monday and Wednesday, I continued working through code for microscope analysis. After committing to slowing down for the sake of higher quality and readability, I think the overall cleanliness of my code has improved substantially. Unfortunately, I was not able to finish configuring git at the lab on Wednesday so I do not yet have a remote code repository to share with you, but hopefully I can get that done when I get back. The lab has been generally quiet this week; many graduate students are on the UC system’s spring break. Daniel was still there though. I’m progressing towards the ultimate goal of performing analysis on a live video stream quiet nicely. As of Wednesday, 3/29/17, I’ve written 2960 lines of code. This is not all that much, but it really does put things in perspective, since it makes one realize that my codebase is still quite small.
I’m only currently utilizing about two-thirds of my code. In my other related work, things are mixed. My progress on machine learning is progressing well: I’m currently on week 5 of the online Coursera course. After the ESC disaster recently, I’ve scrapped a lot of the octocopter and built a quadcopter out of the octo’s parts. Quadcopters are generally easier to maintain, since they only have four motors and four escs. It only took me a few hours to build the quadcopter. All this just goes to show how once you possess a solid understanding of an idea and its many facets, how simple it is to actually execute it. Most of the trouble seems to be in the system design and planning, and not so much in the execution. Though I certainly mess up both, I make mistakes in system design far more often. I’m looking to work on that. My drone frame design work is hindered by the fact that I’m not well acquainted with Fusion360, the 3D design and CAD software I’m using to design the 3D-printable frame. I’m thinking I’ll use the standard and widely distributed ABS plastic for that. I should read up on structural engineering and design to get an idea of how to make the frame robust. I’m looking to continue to reference the research paper I read as my second research book as a springboard for my drone architecture.
Generally, in any software project, it is useful to categorize the project by its design requirements. Are the desired features of the software constantly in flux? Or are they stable and easily accounted for. In my drone’s case, the requirements I have for it are quite stable, but conditionally stable. If I should decide I want my drone to do something I hadn’t originally desired, then that will be much more costly to implement than planning for that requirement at the beginning. It is imperative that not only is the structure of my software sound, but that I plan for all my requirements, allocating appropriate amounts of time for programming and debugging. This sounds incredible easy. After all, it would seem that this sort of thing is just like being on a train track but seeing a train coming from many, many miles away. All one needs to do is plan for the train’s arrival, and step off the tracks. The only issue here is that without substantial prior research into the system you are programming (the flight controller in my case), and the language you plan to use, you can end up being unable to design the system as originally envisioned because it may simply not be possible, or horribly inefficient. In this case, you may be able to substitute a suitable replacement design spun up on the fly, or you may not be able to. Either way, you are stuck between a rock and a hard place. Damage to your schedule is assured, and damage to your overall software system’s integrity is quite likely. This is quite different from the way I’ve programmed in the past, which is much more iteratively. Iterative design philosophy is centered around the reality that requirements inevitably do change, and attempts to mitigate the damage of these requirement changes. One thing I’ve realized recently is that I’m not a good coder. In the past, I’ve used “iterative design” as an excuse for extremely poor planning, and lack of documentation. There’s something I should have realized though: Iterative design may have changing requirements, but the design philosophy itself is no less rigorous. The iterative programmer does not get a free ticket. Program design is still necessary, and clean coding practices must be adhered to as strictly, if not more strictly when compared to more stable requirements because every line of code must be incredibly clear to be able to work around and modify, since everything is revisited eventually in an iterative design. And in following this philosophy, I need to be extremely faithful, never lapsing in a clean methodology. That’s extremely easy to say, and very hard to do.
The last thing that is happening currently for me is the end of the applications process. The final volley of college applications are about to land, and then the dust will settle. For those readers of my blog that are currently juniors, I wish you the best of luck, and I think there is something you would do well to remember during your applications process. I know that Orinda is so college focused that it seems like everything you’ve done in high school has led to applications, and that college will “make” you or “break” you. Remember that a college doesn’t make a person’s life. A person makes a person’s life. Make your life.