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.
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
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.
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.
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.