AER201 Robot
The 2015 AER201 project

Go to GitHub Arduino Prototype C/C++

The AER201 engineering design course of winter 2015 required the design and construction of an autonomous robot capable of playing a modified version of Connect-Four.


The team was divided into three seperate roles: Electromech, Circuits, and Microprocessor. The electromechical member would be responsible for the physical construction of the robot - building and attaching the chassis, motors, and actuators. The circuits member would be responsible for putting together circuit interfaces to connect the electronics to the microprocessor. Finally, the microprocessor member would be responsible for programming the microprocessor and ultimately controlling the robot.

Role Name Tasks Tools and Materials
Electromech Jessica Leung Build chassis, attach components
  • Drill, rotary tool
  • Bandsaw, handsaw
  • Screws, nails, and glue
Circuits Wesley Heung Build circuit interfaces, connect electronics
  • Oscilloscope
  • Soldering iron
  • Printed circuit boards, resistors, wire
Microprocessor Zhi Ye Program microprocessor
  • Computer
  • USB cable





As I had a strong interest in programming (particularly robots), I decided to assist with programming the robot. I began by experimenting with small submodules that we would eventually need. Several small progams that tested a specific functionality were developed. Many of these programs were considered "proof of concepts" to demonstrate that a specific functionality could be achieved.

Name Purpose
Analog Reader Reads analog inputs A0-A4 and prints them to the serial monitor. Useful for checking if the sensors and sensor circuits are reading properly. Eventually evolved into the Virtual Oscilloscope function of Heartbeat.
H-bridge Test Turns the motors one way, then another one at a time to exhaustively test the functionality of the H-bridge and ensure it is working correctly.
Comsat (master/slave) Sends radio-frequency communications from the master to the slave. Requires two Arduino microprocessors.
Encoder Test Records the number of rising edges seen from an encoder attached to the hardware interrupt pins 2 and 3.
Line Follower Follows a simple dark line on a light background.
Navigation Test Based on the Line Follower, navigates a pre-programmed series of directions on a grid.

Heartbeat (Main article)

The serial communication program Heartbeat was developed in support of this project. It was initially intended to serve as a simple graphical debugger, but quickly transitioned to its final role as a complete IO bridge between the Arduino and a computer.


Lessons Learned

As a school project, this robot contained a plethora of lessons. However, the majority of these lessons tended not to be in the practical aspects such as the design and construction of the robot, but rather in conceptual aspects such as the planning and management of the project and team.


This entire project was a demonstration of why reliability must come before efficiency. When components fail to behave as expected, the entire robot cannot perform its task. Debugging takes hours, or even days. No matter how good the robot is, if it doesn't work, it won't finish its task.


Even when each component works on its own, often putting them all together is the biggest challenge. Suddenly there is no room to fit the sensor board, because the motors mounts are in the way. Or perhaps the motor torque is too high and tears itself off the mount. Maybe the navigation algorithm works, but can't handle a slippery surface. Whatever it is, there is bound to be a multitude of problems as the various components of the project come together.


A core concept of this course was documenting _in writing_ all actions taken. To this end, each student was required to maintain a handwritten notebook. In engineering, your notebook is physical proof of due diligence - proof that the work was done. The contents of my notebook has been scanned here. In addition, electronic documents were maintained in a shared Dropbox.


Our group had a major issue where communication was inadequate. Therefore, the group timeline was neglected and tasks left unfinished (or even unstarted!). Because the timeline was uncoordinated, there was no way to schedule dependencies appropriately and important tasks were often left waiting. In order to complete a project on schedule, the team must agree on the timeline and constantly revise it so that the tasks will be finished.

A sample from the timeline