In late 2019, I was interested in filming time-lapses, mainly of the clouds and weather throughout the day. I also wanted get my hands dirty with a “real” programming language, so I set a goal to create a system that could film daily time-lapse videos and upload them to YouTube, all with no (or very minimal) human input.
Anyways, that’s how, on December 25th, 2019, I set out to build this system. Not only that, but I wanted to start uploading on the new year, only a week later. That may seem overly ambitious (and it was), but I actually did manage to get some sort of system set up by then. It was the iteration process on that initial system that extended the project into a months-long endeavor that persisted into the 2020 quarantine.
I chose to use Python for the project, mainly because of its reputation for being powerful and easy to learn. Since I hadn’t written in Python before, there was a learning curve, but as the project progressed it became easier to work with as I learned the basic features of the language.
My first plan involved controlling a phone programmatically to take individual time-lapse frames and transfer them to the computer during daylight hours. Then, they would be combined into the final video and uploaded, ideally during the night.
This version of the system was ready by New Year’s 2020, but I had only been able to test it over short durations up to that point. When it came time to film the time-lapse for January 1st, the problems with the initial setup became apparent:
The phone would overheat from being in the sunny window
The phone would randomly disconnect from the computer
The phone would periodically lose focus, even though it was set to infinite
As it turns out, a phone is not built for taking thousands of photos while continuously connected to a computer and baking in the sun. After this realization, I spent a couple months testing and honing the other parts of the system while using an old webcam to take the actual frames.The webcam had a maximum focal distance of about 5 feet, making it unusable as the actual camera.The webcam had a maximum focal distance of about 5 feet, making it unusable as the actual camera. At this point, I probably could have just bought a nicer webcam and called it a day, but I was hesitant to spend money on the project.
Then, I had to figure out how to download the video, which typically came in the form of multiple video segments topping out at 4GB each. In the end, this involved querying video metadata through the WiFi commands before downloading each segment with a fine-tuned Wget
en.wikipedia.orgWget - Wikipedia command. These steps worked most of the time, but because the GoPro couldn’t record and transfer files at the same time, the video had to be completely downloaded overnight, or else the system would fall behind. As you might imagine, this tended to happen frequently due to the fragile nature of the whole setup.
Reliability issues notwithstanding, the new setup using the GoPro is the one that ran from April to June 2020. But what happened to the videos after they had been transferred?
With the videos processed and ready to go, they would then be uploaded to YouTube, likely during the morning hours as the next day’s time-lapse had already started. At least, if everything had gone according to plan.
The lessons that I learned from this endeavor boil down to two main ideas:
Ability to change directions from initial plans
Self-reliance and confidence in problem solving (given enough time)
First, I was stuck for a while as I tried to make my original idea work. But when I took the time to assess all of my available resources, that opened up more possible ways to solve the problem. Then, I could evaluate the tradeoffs between these different approaches to find the most practical solution. Today, I like this “backtracking” aspect of problem solving because it often leads to surprising methods to overcome or circumnavigate roadblocks in the development process.Although I’d like to think these “surprising” solutions are usually elegant, sometimes they can be “surprisingly” hacky…Although I’d like to think these “surprising” solutions are usually elegant, sometimes they can be “surprisingly” hacky…
Which leads to the second point: that working on this project fueled my self-reliance and confidence that I could solve any problem (within reason), at least given enough time. On one hand, this has been a motivating factor in all of my personal projects since. If I have a vision that seems out of reach at first, but I can break it into manageable pieces and solve each of those, then I can compose them into something awesome. However, that last part, time, is something that I’m still improving on today. I’ve gotten much better at giving myself reasonable deadlines and limiting scope if necessary, but sometimes it can still be a challenge, especially when working in unfamiliar territory.
As a whole, I’m still proud of this project, and of myself for making the jump into “real” programming that led to where I am today.