Daniel Wolff

During the summer between grade 12 and university, a couple of friends and I decided to complete a "Countdown Clock" as a going away gift for our First Robotics Competition team (FRC team 4976). The plan was to create a large digital LED clock that counted down from the start of the FRC build season to the end (about 6 weeks). I was put in charge of the software because that's what I'm most familiar with, but I also helped with electrical occasionally to strengthen my prototyping skills.

The initial design was simple: use a real-time clock as an accurate representative of time, take that data and process it into a countdown from 6 weeks, and output to a bunch of 7-segment LED drivers. Easy, right? ... Sort of.

We came across many bugs, ranging from the LED's flickering every once in a while for unknown reasons to the LED's not even displaying numbers. Debugging was a long and painful process consisting of outputting data to the command line and trial and error on the electrical side ("what happens if we unplug this?"). Eventually we managed to reduce flickering by optimizing the code to eliminate unnecessary operations, and ended up replacing the 7-segment LED drivers with TLC5940 16-bit shift registers, which simplified both the code (due to the TLC library) and the electrical side of the project (reduced the amount of components/wiring).

On the electrical side of things, we came across more environmental barriers than we did technical barriers. Our FRC team was actually a high school robotics course, so the clock would be set up in a technological education classroom - a classroom that had the power shut off when it wasn't in use. At first we didn't consider this when writing the code, and quickly realized that the countdown clock would reset every time it lost power. This, obviously, is not good.

Our summer was slowly coming to an end, all of us were preparing for the big step into university, and we had little time left to work on this project. So, we had a tough decision to make. Do we invest in a powerful enough battery to run the clock when there is no power? Could we get away with hard-coding the start and end times of the build season? Both answers were no, so we had to improvise and shoot for a solution right down the middle.

It turns out the the real-time clock we were using (DS1307) supports a backup battery, so we used a small battery to power the RTC and not the LED's while the power was off. The RTC uses very little power, so a small battery can run it for a very long time. Sadly, due to our limited time, we had to hard-code the end date of the build season into an EEPROM. To make this less of an issue, however, we designed our PCB to be easily removed from the clock, and features programmable pins that allow our team to upload different code. By providing the source code, our team can always make some changes and upload their own version of the clock - perhaps with buttons that allow you to manually change the end date through the hardware! Looking back, this solution is really neat due to how it adds a customization aspect to our project.

In the end, this project was a HUGE learning process for all of us, and we all learned important tips and tricks that allowed future projects to progress easily. If you're interested in the schematics and code of the clock (or more pictures), click here for the Google Drive made by my friend whom I worked on the project with. The same friend, David Perna, also walks you through the design of our clock and how it works in the following video.

The EPIC Game Challenge is a contest held by the McMaster University Engineering faculty where first year engineering students compete to see who can program the best game. The winner is determined by other engineering students who are asked to vote for the game that is their favourite.

I entered this contest hoping to blow the other contestants out of the water. I've had experience programming games and visuals before due to my high school computer science courses' culminating assignments, so I figured I would have an advantage over my peers. However, I didn't want to enter the contest for the sake of winning first place - I wanted to challenge myself with a type of game I've never made before. After a lot of deliberation, I decided to try and attempt to build a sprite based game much like the popular Nintendo classic, Super Smash Bro's Brawl.

Luckily for me, the contest was held in a language that I'm very familiar with - Python. Furthermore, the contest allowed for the use of the PyGame library, which is the same library I have used to develop many games before. The only difference is that now I have a much better understanding of Python classes, and am now able to build a much more efficient code base for the game than I could have for any other game I have designed. So, that's where I began when approaching the project. In fact, I had a sturdy set of classes that handled all the logic, windows, and event handlers that were needed for the game before I had even decided on what my game would be!

At this point in the development process I had to take a step back from the code and had to do some drawing. I'm definitely not the most artistic person you'd ever meet, so I had to settle with stick figures drawn up in the most professional image editing software, Microsoft Paint. As a result, I ended up naming my game "Super Smash Sticks Brawl". Since the characters were sprites, I had to draw each stage for each animation - 13 images for each direction (26 images total). The game loads each image up during startup, and draws them according to a finite state system within each character. The finite state system was simple yet complex; it was merely a variable that held a number that corresponds to a certain animation or image. This number either changed automatically due to environmental effects (like being kicked), or changed via button press. The complexity started to arise when it came to keeping the animations fluid. For example, if the player wanted to walk in the other direction while rolling, the game wouldn't let that control take over until the roll animation had completed.

When it came down to debugging, the state system was the only aspect of my game that I actually had a hard time with, especially when it came to automatic state transitions. Of course, discovering what the issue was was as easy as printing the state variable to the console along with any relevant variables that may affect the state, but the amount of times fixing one issue caused more issues was awfully frustrating. Eventually, I managed to get the state management down to a point where it is very hard to break it. There is still one bug that I haven't managed to solve, but isn't easy to trigger so I decided to leave it in the game for the time being.

The rest of the game is all code I've written before, so it was rather easy to get working. The menus are controlled by another finite state variable, collision detection is just box-to-box, and hit detection is based off proximity.

In the end, I managed to make a very addicting game that is very fun to play against friends. I placed first in the competition with a 13 vote lead over second place, and was awarded an "Engineering Certificate of Excellence" by my Engineering Computation professor, Dr. William Farmer.

The code for my game can be found on my GitHub if you wish to give it a try. Please note that you will need to install Python 2 and PyGame in order to play. The installation packages can be found in the SETUP folder included with the game.

This project was inspired by the Professional Engineering course taken by all first year engineering students at McMaster University (1P03). The final project for the course was to design a solution to a problem of your choice that was given by St. Peter's Residence at Chedoke, a long term residence care home located in Hamilton, Ontario. One of the projects proposed by St. Peter's was to create a falling alarm to notify the nurses in the event of one of the residents having fallen.

The VATS notifies nurses if a resident falls or stumbles via a push notification to the nurses phones directly, or ideally a nurse station within the residence. It does this using an accelerometer in a shoe/slipper to detect the orientation and motion of the residents feet, allowing us to accurately tell if the resident has encountered a fall.

To learn more about this implementation and analysis of the VATS, please visit the Devpost page we created to outline the creation of our project.