4 dabs = 1 yeet is basically 4 player pong.
Remote controlled: We initially wanted to make an attacking-defending robot. The design was that resembling a ramp for a shield, and an arm for a sword, powered by a motor. These were mounted as part of a standard car. This arm transitioned to four on an axle, resembling that of a Buddhist swastika. During the tournament this was mounted on the side, then changing to a large arm on the front. Both spun in an attempt to flip the other robots. Both variations worked to varying degrees. The remote controls using Bluetooth were a large part of people’s horrendous matches, as the steering was relatively off with minimal control if a robot had more than just movement controls.
The automated robot was a massively scrapped version of the “Disabled German”, in that we initially wanted to look towards the winning sections of the competition. So, we looked at the “Swiss Cheese”, Harry’s robot. It seemed to deliver on the fantasy of being a large skirt disabling robots from moving and charging it. This was our initial take before we realised we needed to mess with the wheels further. So, instead, we looked to the true winner, and google images. It appeared that a flat design was the best idea, whilst turning the brick upside-down, utilising the slight tilt the brick brings to the joints it allows for off the side.
The “Mock 1” as dubbed by Steve, allowed us to elaborate on our own design whilst simultaneously keeping to a ‘winning’ design. Our sensor at the front allows us to detect robots ahead. We had issues with detecting the ‘ring’ we fought on. It worked after some time of adjusting the range. We modified where we put the light sensor, to detect the edge of the ring. We put it to the front, allowing us to detect if it was going to go over the edge after going forward, turning, backing off, repeat.
We did relatively well in the standings, strategically outsmarting many an opponent, only falling short to the one of which it attempted to remake. We sub-named it Lucifer due to the weight being 666 grams.
Andrew & Joe
The book holder effectively upgrades on the inconvenience of holding a book, allowing for automation in a previously unexplored area. This book stand allows readers to take drinks, read the page selected and to take notes. It does this through a clamp system controlled via two motors. The clamps are adjustable, and allow for minimum obscurity of the words on the pages. It uses the back-board to hold the book at a thirty five degree angle, allowing for reading while sitting or standing.
We found inspiration from book stands on Amazon, allowing us to create an effective model prior to programming.
Large and heavy books, such as many maths or science textbooks will close on themselves, and require constant attention from the reader to keep the books open whilst taking notes, or a drink. The act of a book closing, despite the book, is quite an inconvenience – One we wished to eliminate. It is particularly useful for cooking, as it allows for a stand and keeps the book open on the recipe without accidentally overcooking something whilst scrambling to find how long it’s meant to be cooking for.
- Must allow for usability – Cannot get in the way of users.
- Must hold the pages down without damaging the book. (Too much pressure.)
- Must allow for other tasks to be performed whist the book is being held by the stand.
We attempted to create a page-turning system, through use of wheels. This seemed to only be able to turn no pages, or too many, as well as getting in the way of the reader. It also appeared it would damage the pages if too much pressure was applied.
We also attempted to create an over-page clamp. Both sides were unable to exist at the same time, due to the difference in motor types on the top and bottom. Both of the top sides were out of sync, and subsequently there was nothing we could change in the program to improve such a fault.
Team members – Andrew, Joe, Bill, Will