CE/CZ3004 Multi-disciplinary Design Project

30 October 2015

During my final day of internship at Healint, I described about the heaviness and difficulty of this module to my supervisor, Mr Nicolas. His response was:

It will be fun, but you won’t learn anything.

Hmmm, it’s near the end of MDP, actually it was fun. But do I learn anything? Not much. Most of what I poured into my codes are from what I already knew, and other small parts are just copy-pasted from Stack Overflow.

In our project, we put the “brain” into the Raspberry Pi and hence I SSH-ed to it to run the program. But I’m already quite familiar with SSH  since:

  • I’ve run programs over SSH at Wikimedia’s Tool Labs
  • I’ve deployed (and also debugged) Django website for my part-time work at LILY Research Center


It was fun in discovering and fixing bugs.

It was fun that the Arduino team keep improving a lot.

It was terrible that during Week 11 challenge, our SD card on our RPi is spoilt and hence can’t mount the OS (Raspbian); and we need to set the program up on another SD card and we forgone our challenge attempt, and lots of hours used up for setting up this new SD card. This teaches a hard lesson that we need to shutdown the RPi properly before plugging the power out.

It was fun that, at one instance, we need to put this line of code at the beginning of the program:


No one knows why we need it, and unless we put it, our program will fail to run.


What I indeed learn is that Python I/O (input/output) is blocking (unlike Node.js) and to “trick” it, every components that have I/O need to be threaded. And hence, the program need to be properly terminated, if not, there will be a dangling thread running in the background. Due to this project, now I really dislike blocking I/O 😛

We learned lessons from failures. On week 8, we were panicked while setting up the robot (and since it was us who got the first turn to attempt), and as a result we failed to start. It was combination between instability of Bluetooth connection and also the input buffer from Bluetooth after it was connected. The start command was sent twice and two threads were spawned to issue commands to the robot (cause there is no check on whether the thread has been started or not).


On Week 9 challenge, just before the challenge, our robot miserably failed the previous week’s maze. But during the challenge itself, luckily it was okay.

On Week 10 challenge, the exploration was impossible to perfect our score but luck comes for our fastest path challenge, we managed to reach 13 seconds and be the #1 in that leaderboard.

Update on 23 December 2015:

What happened in Week 12?

Even after lots of rigging & testing on the previous days, “something” occurred at the right place and saved us. But on another spot where we think that the robot won’t fail, the robot went out of alignment and failed the exploration since the robot failed to get back to the start zone. But just for fun (& with some luck), running the fastest path program, our robot can still reach the finish zone. People were impressed.


Reflecting back, this module needed:

  • good leader, this is crucial for making sure the big team was well communicated and task were well done on time.
  • good thinker, for coding the Algorithm/RPi, also familiarity with Linux Terminal and Python I/O.
  • good hardware people, for the Arduino part
  • a lot of commitments and good luck. 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s