With the physical attributes of the new bot taking shape we turned our attention to the to-do list for the code that we had accumulated from improvements and ideas we had come up with from participating in Pi Wars 2017 and the intervening time.

To enable multiple members of the club to contribute to the code base at the same time we stored our work on Bitbucket and our members used a combination of GitKraken to manage the code repository and PyCharm to write / edit the code.

Top of the list was to move the core of the project from a Raspberry Pi 2 to a Raspberry Pi 3. We had tried to do this for our previous bot but as were using the on-board serial for Pi to Pi communication we experienced problems with the architectural changes to the Pi, couldn’t get it to reliably work and in order to be ready for the competition ditched it and went back to the Pi 2.

After we had changed the hardware we tested this in the previous bot to ensure all the existing code continued to function as expected and then moved from a Bluetooth USB and USB Wi-Fi dongles to using the on-board ones of the Pi 3.

Happy that everything was still operating as expected we next tackled the single biggest change to our code since we began competing in Pi Wars, moving from Python 2.7.2 to Python 3.5. With some guiding principles set out by our Coder-in-Chief we set about modifying all of our code libraries.

After a few weeks and many code reviews we again did a shake down of our code on the previous bot and once we were happy that everything had ported successfully we got to work with the improvements and code for the new challenges for Pi Wars 2018.

One guiding principle that we set out from the start was to ensure that the code was simple and easy to understand and where possible avoided repetition. As such we created libraries for many of the aspects of the bot, motor control, controller input, sensors and the code for the individual challenges themselves. This meant where a challenge needed the same items as another challenge then they could just call the libraries required and we would not be repeating the same code in multiple places.

Also key was the idea of having a ‘menu’ program that the bot would automatically boot into and then allow us to make a selection depending on which challenge we were to perform. The 4 different programs that were accessible from the menu we as follows:

  • Remote Control: For tasks that were to be user controlled
  • Speed Auto: For the straight line speed test challenge
  • Maze Solver: For the maze challenge
  • Rainbow Bot: For the over the rainbow challenge

At the end of each of the challenges we were able to go back to the menu on a button press combination and launch a different menu item if needed. We also had the ability to trigger a shutdown via a button combination if the robot was in the menu mode so that it would shut down properly before we unplugged the Pi to minimise the risk of corrupting the contents of the SD card.