Report – Evaluation and Reflection

Looking back at our game and viewing the final program, I believe that whilst the game does work as intended and matches the plan that was eventually laid out for it, it still lacks the qualities of what one would describe a game as being. By this I mean that there is very little user interaction; once the user has selected the number of laps, the only other user interaction is to replace the cardboard boxes which the robot picks up back onto the track for it to pick up on its next pass, which could be viewed as an oversight in the plan of the game. On top of this, the game lacks any real goal or final outcome. Once the robot has completed its designated number of laps, it just stops.

In regards to the process of planning the game, we mostly ended up coming up with ideas on the spot once we had ample working code for the current plan. This meant we built upon the idea of a line follower, adding functions as we went. Looking back this was clearly the wrong way to go about the design of a game. What should have happened was we should have spent more time planning out the entire game and all its objectives and functions before starting on the program.

As for academic skills, it is my opinion that the biggest lesson learnt was to never rely on others until you understand their motivation. Whilst my assumption at the start had been that all members of the course were attending university to work, I believe that this assumption was proved false throughout the duration of this project. Whilst delegating tasks to others works in theory, the structure of the project as a whole then relies on each person completing these tasks on time (or at all) for the project to be completed.

When it comes to professional practices, this project has demonstrated the importance of using all forms of media in order to present and document my work, and to use proper version control when creating complex programs.

Report – Evaluation and Reflection

Report – Wireless Communication/Bluetooth

The Bluetooth functions of the robot require a third-party application which is only available from the Google Play Store under the name ‘EV3 Mailbox Remote’. The application works by selecting a Bluetooth connection to the robot, inputting a matching mailbox title, and then sending either a String, Value or Boolean data type. For certain functions, the robot will only accept certain data types, and so will not change state if it receives a different type.

For our game, we decided to implement user interaction via Bluetooth. At the start of the game, the user can initialize the game via either a button on the front panel, or by sending a Boolean ‘True’ value to the robot. The robot then requests that the user input the number of laps via the screen on the front. The user can then send a value via Bluetooth to decide the number of laps. This number will be displayed on the screen throughout the duration of the game. The user can opt to skip this input via a button, after which the game will set the number of laps it is to complete to 3.


Ferdinand Stueckler (2013) EV3 Mailbox Remote [online] available from <> [2 December 2015]

Report – Wireless Communication/Bluetooth

Report – Components and Processing

EV3 Components

The LEGO® EV3 Home which we were supplied with contains 1 EV3 programmable brick, 1 Color sensor, 1 Touch sensor, 1 Remote Infrared Beacon, 2 Large Motors and 1 Medium Motor (Lego Mindstorms Product page n.d.).

The main EV3 brick has 4 RJ12 input ports for connecting the sensors, as well as 4 RJ12 output ports for connecting the motors, a USB host port for either chaining the brick to other bricks or for a Wi-Fi dongle. For transfer of data between computer and brick, there is a Mini USB port and a Micro SD Card port. The brick acts as a microcomputer, and allows you to control different motors/sensors individually as well as take readings from the sensors and display them on the screen. You can also control individual Wi-Fi connections and run programs that have been stored on the robot. There is also a high quality speaker on the back. It can be powered by either 6xAA batteries or a 2050mAh lithium rechargeable DC battery pack. The sensors are each powered and accessed via the RJ12 ports.

The brick runs on an ARM9 300MHz processor, and has 16MB Flash-RAM and 64MB RAM. The operating system is Linux based. (botbench EV3 review 2013)

Aside from the brick and sensors, the set also contains over 500 LEGO® Technic pieces with which to build the desired robot model, as well as sets of instructions for a few of the models. The rest of the models’ instructions can be accessed via the LEGO website.


LEGO Corporation (n.d) Mindstorms EV3 Product Page [online] available from <> [30 November 2015]

Soldaat, X. (2013) Bot Bench: Comparing the NXT and EV3 bricks [online] available from <> [30 November 2015]

Report – Components and Processing

Week 10

So this week is the final week, meaning that by the end of it we needed a working demo video of the robot to show for. To get to this point, there were still some problems which prevented the robot finishing each lap, but after fixing those problems, I can now present the following 1-lap demo:

The major problems were ones which halted the program, or otherwise prevented the robot from completing the lap. The most prominent of these was that because of the way we stored the paper track (rolling it up) the track had to be pinned down, and between the pins along the edge the paper kept riding up. This was a problem because the robot’s wheels would catch on the edge of the paper and either cause it to stop, or cause it to veer unexpectedly, often causing it to go off track. Another issue was that due to the small space in which I had to record a demo, when the robot executed the Green function (turned off the track and dropped the box) the IR sensor function would trip from detection of the wall, causing the robot to stop. To bypass this I had to disable the IR function for the main demo. The other big problem was the dispensing of the cardboard box. The arm seemed to drop the cardboard box perfectly on any non-filmed test runs, but upon attempting to film the robot, the box would nearly always get stuck on the end of the arm. To fix this I simply upped the speed at which the arm lowers, giving the box added momentum as it was thrown. I also had to slightly decrease the angle in both the lifting and dropping functions to prevent the arm motor getting stuck as I described in the previous post.

As a comparison of the final game and the initial brief, the game scenario matches the following complexity requirements:

  • Movements
  • Pick-up and reposition of an object
  • Colour detection
  • Touch detection
  • Position change detection (IR)
  • Information display
  • Button Input
  • Line Following
  • Timing control for an activity
  • Detection of the position of an object based on it’s distance
  • Repetition of behaviours (loop)

A full image of the program’s code is available here.

Week 10