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.

Cons

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

Cons

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

Conclusion

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.

Leave a Reply

Your email address will not be published. Required fields are marked *