Chaos Cleansing

Chaos Cleansing is a platformer/shooter, side scrolling game in which the player moves through multiple rooms with a projectile weapon, cleansing the world of ‘Chaos Beasts’.

The goal is to kill all of the chaos beasts before they kill you, and then to go through the portal into the next realm. Eventually the player will find themself face to face against the Chaos King, a large, flying chaos boss with incredible health that does incredible damage.

The game uses A (to move left), D (to move right), W (to jump) and the mouse to point and shoot at enemies. Optional weapon upgrades are available by walking over the gun on the ground, however the player’s weapon automatically upgrades when moving through the chaos portal.

Download the game: Chaos Cleansing-zbhfy7




Jerry the Automated Sumo Bot

Prototype 1

Our original design was going to be a continuation of the remote controlled bot from the first week of the challenge, with minimal changes to allow automation. The design was a medium sized, relatively tall robot with a high centre of gravity and a remote control scoop on the front – the idea of which was to drive under an enemy robot and lift their wheels off the ground forklift style. Unfortunately due to the one major constraint of the challenge – that we were limited to the components from a single EV3 kit – we were forced to use the small motor and a few cogs to actuate the scoop – in order to save the larger motors for the drive train – which rendered it ineffective due to its limited power. The other drawback of this design was made clear when pitted against the short yet wide Death Triangle, with its low centre of gravity and simplistic design: our robot was too unstable.


  • High centre of gravity
  • Weak scoop motor
  • Unstable


Prototype 1.5 was an intermediate design between prototypes 1 and 2. It never actually went to war, however it allowed us to gain insight into an alternative style of design.

Prototype 2

Whilst Prototype 1 was effective in contrast to many of the other robots in the competition due to its sturdy construction and frame, the prospect of automation would open up a lot of opportunities for the other teams to improve their Sumo Bots, so we decided to redesign our robot from the ground up. We did away with the over complicated and ineffective scoop, and built a structurally sturdy frame onto a wide wheel base, lowering the centre of gravity in order to replicate one of the more successful robots from the first round. The automation process involved the attachment of two sensors: an ultrasonic and a colour. The idea was that our robot would swivel until the ultrasonic sensor located an opponent, and then it would charge. The safety protocol to stop the robot driving out of the arena was the colour sensor; when the robot identified the black line that signified the edge of the ring, there was an algorithm in the program that had the robot back up and turn around, ready for combat.


  • Poor programming resulted in poor performance against other robots.
  • The offside of the light sensor resulted in the robot running itself out of the arena on numerous occasions, as it would not register the black line in time when approached from one side.
  • Scoop was a little flimsy which resulted in us being able to apply less immediate force to our opponents, as the scoop would simply flex.
  • To turning circle of the robot was a bit ridiculous due to the nature of its wheels being at the very back and it having a long scoop. This made it somewhat unwieldy to program effectively.

Prototype 3

We concluded that prototype two’s light sensor was in a sub-optimal position, offside of centre on an arm. This resulted in our robot’s edge of ring detection only working effectively when the robot approaches the black line from one side. Approaching the line from the other side resulted in the Robot falling off the table, as by the time the colour sensor was over the line, a critical mass of robot was hanging out over the edge. In order to rectify this issue, we redesigned our scoop to incorporate, centralising it. This was prototype three’s only major hardware addition, however we completely overhauled the program to create more effective enemy detection. Whilst it still had the shoddy turning circle of prototype 2, its edge detection, scoop construction and programming were vastly superior.


Unfortunately our robot did not compete very well against the other for a variety of reasons, however its most obvious flaw was the untested programming. Because we spent so much time trouble shooting and building the hardware, our first trial of the new programming was in our first round of the tournament. With a bit more time we could have vastly improved it.


We chose to make a prototype robotic hand designed to assist people suffering from Parkinson’s disease, and other debilitating conditions that effect the motor function – in other words the strength and dexterity – of the fingers and hand. An exo-skeleton arm, or ExoArm.

The completed ExoArm, ready to assist in hydration.

We chose this disease and solution because:

1) Parkinson’s disease inhibits movement. It is caused by nerve cells in the brain malfunctioning. (

2) Parkinson’s can affect the hands to the point of them not being useful for everyday tasks, which can have all sorts of negative repercussions throughout the remainder of one’s life. (

3) A potential solution to this is the creation of an artificial ‘exoskeleton arm’, to assist with hand mobility, and stop the disease interfering with the everyday lives of patients. (

4) This concept could also be used to assist in the case of other motion inhibiting diseases, conditions and injuries. For example a quadriplegic person who still has some control of their fingers would greatly benefit from one such device. (

And finally: while Parkinson’s is a terrible disease, and a functioning exoskeleton arm could be greatly beneficial, what finally pushed us to choose this project was how cool robotic hands looked!


Our final product was a basic exoskeleton hand with articulating fingers operated by the press of a button. However, as stated in the intro, this was a prototype; our device was clumsy and awkward, and it weighed a ton – it would require more strength and precision to operate the arm than it would just to pick something up. Whilst our prototype may not have any useful real world application, it is a good indication that with more time and better equipment a useful exoskeleton arm could be created.


1) Diavo Voltaggio – a LEGO enthusiast who build a robotic arm for Brick Fair. We were inspired by his three finger design, and just how good his hand looked. His YouTube channel is available at (

2) Builderdude35 – a LEGO YouTuber whose anti-stalling program we implemented in our device.


Given more time and resources, there are a number of upgrades we would like to make

1) It would be cool to give the fingers joints (using complex pivoting mechanisms as opposed to additional motors), more accurately replicating the human hand.

2) We would add a 4th finger, once again more accurately replicating the human hand, however for this we would need to use a second brick, increasing the weight and complexity a lot.

3) We would implement pressure sensors as opposed to touch sensors, which would allow for more control of the fingers – the harder the button gets pressed, the faster the finger closes.

4) We would refine our attachment mechanism, resulting in a tighter, more comfortable fit on the arm, and a reduction in weight and bulk.

5) We would refine the program to speed up the finger closing action, and to upgrade the anti-stalling function of it, allowing the hand to grip objects with more strength.



Program for one finger (This was repeated 4 times)


Program for custom block ‘Finger’ (used within the program for each finger movement)

Team: Barney Russell, Benjamin Bruce and Kindilan Hayes.