Student Robotics are an organisation who strive to enthuse, excite and encourage a real-world approach to engineering through organising annual robotics competitions. My school had been taking part in the event for several years before my first competition in 2015. That year we were not so successful but this gave us some good motivation for the 2016 competition and some hands on experience which proved invaluable. Preparations began in September 2015 and continued right through to the morning of the competition in April. I was heading up electronic design and one of the members of the hardware team. Here are the things we learnt along the way and the finished robot we produced. The game in 2016 was called sunny side up and involved flipping tokens (cardboard boxes) so your teams colour was facing upwards. Points were then awarded at the end of the game based on how many tokens you had 'captured'. Further points could be gained if your 'captured' tokens were moved into your corner of the arena. The full rule book is available here . Each game was only 3 minutes long so it was important tokens could be flipped and rotated quickly and efficiently. This was one of the major design considerations we took into account when starting work on the robot. Another aspect we tried to focus on was the aesthetics. The previous year, the robot which won the Committee award was much more refined than the rest of the competition, it was functional and not just a box with wheels! So with these considerations in mind we came up with the following design: The main feature of our Robot was the grabber/turntable mechanism which allowed tokens to be manipulated quickly. From the video you can see that the grabbers can open/close, rotate to pick up the box and the pads on the grabbers can then rotate and then finally the turntable on the robot can rotate. This was a complex system to design and required several modifications to get it up and running. Firstly the grabbers being able to open and close, this was achieved by two high torque servo motors, one on each arm. They are connected to the 8mm hardened steel pivot rod via a steering rod from a remote control car and a custom metal part which anchors the steering rod and provides the pivot point for the open/close motion. This part was originally 3D printed with 100% infill out of PLA however it was not strong enough to work reliably. On the final version they were Steel which was difficult to machine as accurately but much better overall. Next the rotating pads on each arm. These are controlled by two NEMA 17 stepper motors which form counter balances at the bottom of each arm. They are linked to the pads via timing belts which run up the middle of the arms. To ensure they rotate at exactly the same speed they are connected to the same stepper driver but in reverse so one opposes the other ones direction. The combination of these grab and rotate mechanisms initially did not work due to a lack of grip on the pads combined with the inability of the servos to close the grippers to exactly the correct point. This problem was solved with some cheap makeup sponges from the pound shop which seem to be spongy and grippy at the same time, ideal! Next onto the arm rotation. This proved the hardest to get working as the boxes where significantly heavier than first expected. A standard NEMA 17 stepper had no were near enough torque even with extra gearing from the timing pulley ratio. The solution to this problem came in two forms, firstly the use of some springs to aid the stepper in lifting the box and secondly a planetary gear box on the stepper. Some careful tuning of speed and acceleration allowed the box to be lifted and dropped reliably every time. Finally the turntable, probably the easiest part of the mechanism as it is simply a stepper motor under a round piece of 6mm ply. Once again though the acceleration and speed of the movements had to be fine tuned to get a good balance of speed and reliability from the mechanism. Overall the grabber mechanism worked very well, however it took a lot of tweaking to get it to its final working stage. <br /> From the outset it was clear that stepper motors were going to play a key role in controlling a significant amount of the robots functions. This complicates the electronic design somewhat as stepper motors require a more complex drive circuit than a standard DC motor. Using a full H bridge is one option however this requires 4 pins per stepper motor and with a potential of 3 or 4 stepper motors on the robot to control this could soon get out of hand. This is were my experiences with 3D printers helped me out. Thanks to the open source 3D printer revolution there are many cheap and compact 2A stepper drivers on the market such as the A4988 which can be purchased as complete modules for as little as £1 each. Having decided this would be the best option my attention now turned to the control circuitry as a whole. At this point it might be a good idea to explain what student robotics provide in terms of the electronics. They have a complete eco-system of parts which communicate over USB back to the main brain board which is a small computer very similar to the Raspberry Pi. The whole system is then powered from a LiPo battery connected to the power board which distributes 12V and 5V to the entire robot. The add on modules include a camera, servo control board, 2 motor control boards and a Ruggeduino . More information on this can be found at the Student Robotics website . Our team used only the camera and 'Ruggeduino' for control of the robot as this allowed us to reduce the amount of communication required between modules, increasing reliability and saving time in the process. However this would not have been possible if I was unable to expand the rather limited IO capabilities of the Ruggeduino. To overcome the shortage of IO I initially planned to swap the Ruggeduino for a bigger Arduino Mega. However this didn't work with the SR firmware for whatever reason and consequently I had to try a different approach. Although speaking to a team at the competition who had managed to switch the Ruggeduino out for an Mbed platform, I now think it may have been possible after all. Anyway, at the time I didn't see this as an option and instead had to substitute the Mega in another way. Reading up on the issue I found it may be possible to change the firmware on the Mega's DFU chip, seeing as it is using the same one as the Ruggeduino (ATMEGA16u2). This worked initially with the Mega showing up on my computer as a Ruggeduino and the programming still working fine, however it produced a weird error message in the SR Python logs which suggested the communications were failing. My final attempt was to remove the IC from an Arduino Uno board and effectively use it as a USB to serial converter which pretended to be a Ruggeduino at the same time. Finally this worked and after ironing out some grounding issues I had a reliable connection between the brain of the robot and the 'ruggeduino' (actually the Arduino Mega that you see hiding away in the photo underneath the RAMPS board). Download (Atmel Flip) - Ruggeduino DFU.hex It was the motors that used up the most of my time on this project. In 2015 when we entered the competition we used Polou 37D 100:1 geared DC motor with the 64 CPR encoder mounted on the motor end of drive system. This was extremely accurate as we were able to detect 6533 counts per revolution of the wheels and with the help of a PID loop we had the robot tracking in a perfectly straight line. However having produced the first prototype of the 2016 robot it soon became apparent the motors were no longer up to the job due to the rather substantial increase in weight. Knowing the current motors could only provide 16 KgCm at best I started hunting around for some new motors. It turns out a high torque DC motor with encoder is quite hard to come by in the UK and with little choice I ended up going with the "High Torque DC Servo Motor" from Active Robots which is spec'd at 30 KgCm of torque. This turned out to be a complete nightmare as the built in speed controller means it's impossible to get the motors moving perfectly in sync and to add to the problem Rhino Motion Controls seem to pride themselves in using cheap rip-off's of some critical components in there H-bridge motor driver. Having already sent one of these motors back after it stopped working during normal operation, and having its replacement also go up in smoke I decided to open the motor up to see what was going on inside the aluminium housing. On inspection of the electronics inside it became very clear why the motor had stopped working: one of the FETs that made up the H bridge motor driver was no longer functioning correctly, presumably due to an over-current event. After replacing the cheap rip-off of a IRLR7843 N-channel MOSFET the motor functioned fine again, phew! Fortunately the actual control board is completely separate to the main driver board making it significantly easier to reverse engineer. After half an hour probing around with the scope I established the four necessary connections that would need to be made to control the motors directly. Here are the signals required to perform certain motor functions (5V logic): Forwards, speed 255/255 : 1 = 0 , 2 = PWM 3.91KHz 95% duty , 3 = 0 , 4 = 1 Backwards, speed 100/255 : 1 = 1 , 2 = 0 , 3 = PWM 3.91KHz 30% duty , 4 = 0 In the end this motor solution worked fairly well. The motors, despite my doubts had sufficient torque to maintain relatively straight lines however having the feedback on the gearbox side of the motor significantly reduced the accuracy and refresh rate of the speed/distance monitoring. If I were to repeat this project I would certainly use the same motors however I would attempt to mount a magnet based encoder on the motor side of the system for increased accuracy. One of the unique features of our robot was its laser based ranging system. During the 2015 competition we used the standard ultrasonic transceiver approach to measuring distance, however we found this gave us to broader picture of the arena ahead. For 2016 we planned to implement a LIDAR based system in the robot to give us a complete picture of the arena, mapping the robot's location as well as the location of tokens and other robots. Work started by first hacking a UT390B laser tape measure as documented here: http://blog.qartis.com/arduino-laser-distance-meter/ . This allowed a Serial enabled device to trigger measurements and store the extremely precise values in memory (The UT390B claims to be accurate to +/- 2mm over a range of 0.5m - 45m!). Next step was to spin the laser tape measure and plot the values relative to the angle they were measured at. Here is the first prototype of the LIDAR setup. It involves the laser tape measure being mounted on a stepper motor for accurate rotation, controlled via an Mbed development board and placed in the mini mock arena. This worked well, producing accurate plots were the obstacle could be clearly seen. From here I wrote some code in Processing which applied some statistical analysis to the situation and could work out the LIDARs location in the arena as well as it's relative angle. Unfortunately it also introduced some problems: Whilst the laser tape measure could measure accurately whilst stationery, once on the move it struggled to take readings meaning the stepper had to spin relatively slowly. This thwarted our idea of constantly polling the arena because an accurate scan took almost one minute to complete! As each game only lasted 3 minutes the data wasn't terribly useful. Nevertheless, we proceeded with the idea on the basis we could spin the LIDAR to a specific angle to take a quick reading without having to manoeuvre the whole robot. To prevent the LIDAR tangling itself up we used the combination of this hollow shaft stepper (http://www.robotdigg.com/product/21/Nema17-Hollow-Shaft-Stepper-Motor) and a slip ring which allowed the wires to pass through the shaft and spin freely. The initial robot design left the whole bottom part of the robot clear so the LIDAR had an almost 360 degree view of the arena (with the only obstruction being the wheels), however this introduced yet more issues. As the LIDAR spun, the slight tilt that the robot was on caused the laser beam to vary in height so much that for half of its rotation it was measuring the floor in front. The solution would have been to mount it higher up but this was not possible due to constraints placed on the design by the mechanical aspects of the robot. Consequently we compromised and had the LIDAR fixed at the front of the robot which was more reliable, something that is very important for the SR competition. Although most of this part of the project was not used in the end, it still proved to be very interesting and a nice application for some A-level statistics. Downlaod (Arduino) - LIDAR.ino Download (Processing) - LIDAR.pde So there you have it! Here are a few pictures of the finished robot and some of the electronics that made it work. Unfortunately the competition itself did not go so well. The way it works is Saturday is a long day of consecutive matches that can be used for tuning the robot, your positioning in the league just contributes towards your seeding for Sundays knockout, therefor it is not critical to excel on Saturday. This went fairly well for us and we came into Sunday being positioned roughly middle of the tables. However Saturday had taken its toll on the robot, unbeknown to us one of the wheels had worked itself loose and consequently on the first run of the knockouts the wheel was not responding correctly, the motor tried to drive it too hard and tripped the breaker for that channel. The robot was then left stranded with just one wheel in action and consequently we were out of the competition. Fortunately though, the design of our robot had impressed the organisers sufficiently that we were placed in the running for the Committee award. "The Committee Award will be given to the team that displays the most extraordinary ingenuity in the design of their robot. It will not be awarded for complexity of design, rather the implementation of a simple and elegant solution to a problem." As you can see from the picture above we ended up coming away with the committee award which gave a great sense of achievement and made all the hours spent on the project worth while!