Design, code, reflect

After spending many days with all hands on deck working on a design project, there's finally some time to sit back and reflect about what has been done so far.

30.007-bot-prototype

Here's our prototype that will autonomously roam around your house and entertain your dog. Right, a pet for your pet.

Good practices that I applied:

  • using version control (git) to manage source code

This "habit" allows me to prevent the case of omg what did i change? Where is the code that was working?!

I can safely refactor a whole big chunk of code without worrying about losing previously working stuff. easy rollback ftw!

For those who are not so familiar with version control, it allows you to check-in at different stages instead of doing the "backup", "backup1, "backup-final", "backup-final-working" thing that we are so used to doing.

  • writing modular code

Splitting up code into blocks allow one to reuse it and makes your code more manageable. All you need to do is to make changes in one place and it everywhere your code that uses that block will be modified too. No more "CTRL + F" and searching high and low just to change one thing.

  • test individually, integrate incrementally

Right from the beginning, we test out each component (bluetooth, Infrared sensor, accelerometer, sound module, RGB lights) separately first and ensure that they are all functioning correctly. This allows us to split up the workload and test them simultaneously, reducing the time required.

Once that is completed, we combined code in stages and test them again, before importing more code in. You don't want to be scratching your head over !#)!@( error messages by being too ambitious.

  • share what you know, let others try

It's good to explain things to others about concepts that you are aware so that everyone learns together. You might be able to finish it faster for being more well-versed in a subject but knowledge transfer goes a much longer way. Although it might take a longer time for someone unfamiliar to carry out a task, they will eventually be proficient and be of great help!

Lessons learned:

  • communication and teamwork is key

  • good planning minimizes cost

Before we dived into purchasing, we brainstormed about all the sensors that are critical to get our prototype working. We were not in a rush have our hands on all the parts as the project is on schedule.

If you are behind time and no proper planning was carried out, you end up incurring extra cost. Extra cost comes from express delivery and purchasing components that is redundant, ending up wasting more time and having to repurchase again.

  • product without documentation is crap

We bought this audio module from [a local shop] and I couldn't get it to work after 5 hours. Emailed technical support and....no reply.

Reading articles from online shows that your mileage may vary.

The other module that i bought from ebay (for my own hobby) which costs 5x lesser but already proven working performed way better. It took me 10 minutes to get a who let the dogs out song playing!

  • laying out a task list keeps everyone on track

As a project grows and is divided into sub-teams, having a task list allows us to track progress and ensure that everything discussed is worked on.

Here's an example for the electronics team:

electronics-task

  • working on a project accelerates learning

There's so many components that I have never used before and working on the project allows me to have a better understanding of how it works.

I highly encourage you to work on projects that you are interested in and improve your skill set and knowledge. Doesn't matter which field you are in, just find something you are interesting in and work on it!

Some points that I can improve on:

  • increase typing speed

We used to have lessons in primary school that teaches us how to errrr use the keyboard properly.

It sounds funny but your typing speed has an effect on how fast you can code, shaving seconds off development time makes a huge difference. That's when you are talking about coding for almost 5-6 hours a day. o.o

  • code testing

Basically, it is the code that tests the code you are using. When a codebase grows too big, any minor change might affect how the overall integrated behavior work. At some point in time, having this test harness on allows you to work faster and be confident that all parts of your code is fully functional.

In summary, here's some fancy geek way of tracking development:

Line count
-----
code comments total
   63    12     92  accelero.ino
  214    46    284  dog-comp-combined.ino
   96    49    152  functions.ino
   43    31     82  globals.h
   90    14    109  lights.ino
   50    10     59  motor-control.ino
   43     5     55  sound.ino
   50    12     63  tests.ino

Back to more work!