Other Side of the Fence

This unconventional design portfolio was attempted to convey the entirety of my learning process, the shift of perspective, and expansion of horizons over the course of my final year at the University of Toronto.

I’ve observed the Arts & Science (specifically Computer Science) vs Engineering banter ever since I started university. Never really understood it, especially the remarks and criticisms exchanged between the CS students and the Engineers.

All you ever hear as a non-engineer is that:

  • all the engineering classes are ridiculously hard
  • they work five times as hard for the same jobs
  • we are learning the exact same things! (ECE vs CS)

Without any engineer friends, I bought into that. I thought I’d excel at engineer courses based on how well I was doing in my courses which involved the software development process and report writing. A technical project for a client? Easy Peasy. I’ve delivered working prototypes before.

In my hubris, I took the leap. I applied and got accept to a Multidisciplinary Engineering Capstone project course. I walked into the first course meeting to see my group, and I will admit, I held my nose higher than usual. Confidence was exuding out of me for being one of the very few Computer Science students accepted for the project course. My resume clearly showed I was qualified for engineering work.

We met with our client, Defence and Development Research Canada [DRDC] (an agency of Canada’s Department of Defence). They were looking to see the feasibility of a hands-free, wearable learning platform which Aviation mechanics could use. We would be working with the Epson Moverio BT-200 augmented reality head set, with a bunch of gesture detecting peripheral devices.

I realized the project was right up my alley; wearables, Android and coding?! During the initial meeting, my mind went through 10 different kinds of ways we could create this prototype, all of which involved finishing this project months before the deadline.

However, the rest of the group started talking about the design process. Umm. What? What is that? Aren’t we just here to build something cool? I asked the group to fill me in, and that is when I learned about the Engineering Design Process. It was similar, and yet much more extensive than the product development life cycles I had learned.

Design Requirements

Throughout the fist couple of weeks, we met consistently with the client to figure out the requirements of our prototype. The group identified key stakeholders, and the current processes of the airforce mechanics.


In my mind, we would have gotten the hardware from the client and off we go. However, the client wanted research done as well, and I couldn’t comprehend what they needed us to research. The DRDC had probably already done more extensive market research than what our group of students would do!

Nope. The first step I learned was doing research. This research isn’t about finding out what commands in Java do what on an android device, or researching the software architecture of our prototype. We would be looking for everything available on the market which might be better fit for the task of augmentation, object recognition, learning content management, biometric feedback, gesture control, etc. Or perhaps we may find that there is already an existing solution in the market which the DRDC should focus its attention to.

Design Proposal

This was a process I was familiar with. We proposed our main and back up plan with regards to the hardware we would be using. Our initial idea was to use the Meta glasses, which had built in depth sensors, gesture detection, an augmented Field of View, amongst other required capabilities. To avoid the complexity of peripheral devices, as well as to prototype the learning module using just one device, the Meta would have been the ideal solution to investigate. The only issue was getting our hands on one.

We spent quite a bit of time trying to acquire access to one, unfortunately with no results. We had anticipated this outcome however, and thought of a back up plan! We finally proposed a solution that involved using:

  • Moverio Epson BT-200 (while we waited for the BT-2000 to be delivered to the DRDC)
  • Leap Motion controller for gesture detection and recognition
  • Microsoft Band for biometric feedback
  • Wikitude SDK for object recognition

Execution & Iteration

Once we got our hands on the hardware, I sat down with a couple of group members and worked on the software architecture of our prototype. Since our ideal solution of one integrated device did not work out, we had to carefully architect the Moverio interacting with peripheral devices.

The BT-200 headset is where we would be displaying the course content and biometric feedback, which the user would interact with using gestures. This involved making sure the Android application running on the headset could communicate on multiple sockets with multiple devices, as well as multithread safely to be able to process and react. After my work at IBM and Xtreme Labs, this was the next most complex software project I had worked on.

For a detailed design breakdown, you can checkout our final Design Report. It takes you through the entirety of the project, from requirements to final implementation and user testing. You can read about how we managed to feed Leap Motion data to android, and successfully control the application without physically touching the device.

Lessons Learned

This project really came together because of the engineering principles I learned from the group. In my little bubble, I assumed I’d be able to take most technical projects from clients, and deliver something great. I never considered the research phase. Why can I not suggest a [partial] solution which already exists instead of reinventing the wheel?

That one single phase outlined inherent flaws in the 10 initial ideas I had right off the bat. It also made our work a bit easier by finding what exactly is out on the market, and seeing approaches others have taken in the same problem space. If it was left up to this Computer Science kid, the client would have received a more polished revision of what the previous group delivered. That was not what the client wanted coming into this project course.

The Engineering Design process was just the tip of the ice berg. My group showed me over the year just how brilliant they are, the differences in engineering and computer science education, and the different approaches we learn and when to apply them. The product management process which software companies employ is not one size fits all.

Computer Science & Engineering (ECE) are separate disciplines for a reason. We should not think one is better or harder/easier than the other. I can say I’ve put one foot over the fence this year. Our side isn’t as green as we think it to be.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.