Robots are inherently cool. Accordingly, I’ve long wanted to build robots, but until a few years ago I wasn’t making any progress. The big problem for me (other than cost) was the skills required. Robot construction requires a mix of mechanical engineering, electronics and programming. The third I could do, but the first two were much more of a challenge.
This changed in 2013. My daughter (Caitlin) – who shares my love of robots – had discovered that two of her friends from primary school were involved in a robotics club. We went along, signed up, and I stupidly volunteered to be a mentor for the programming team. All of which led to an interesting few years.
To give some background, (and a lot of acronyms), the RoboRoos, whom we had joined, were formed to compete in the annual FIRST Robotics Contest (FRC). FIRST (For Inspiration and Recognition of Science and Technology) run four main robotics competitions:
- the FIRST LEGO League Jr (FLL Jr), for students in grades 1 to 4;
- the FIRST LEGO League (FLL), covering grades 5-10;
- the FIRST Tech Challenge (FTC), grades 7-12;
- and FRC, for grades 8-12.
The FLL has been running successfully in South Australia for some time, with approximately 80 schools and community groups competing in 2017. The RoboRoos emerged from the FLL (and still have two teams in the competition), but was formed by a group of parents when they became concerned that there was little high school support of robotics in the state, and thus were unsure of how their children would be able to continue with robotics when they left primary school.
The FRC is a difficult competition. Each year, roughly in the first week of January, FIRST announces the year’s challenge. This varies considerably – one year it might be a ball game, another it might involve stacking oddly shaped objects, and on a third we might be shooting frisbees while climbing a metal tower. The robots themselves are required to operate autonomously (during the first 15-30 seconds of the match) and under operator control. From the time of the announcement, teams are given 6 weeks to build, program, test and learn to operate a robot capable of meeting the challenge. All of which would be fine if we were building small robots – but an FRC robot can be 1.5 meters per side, weigh 50+ kg, and reach over 2 meters in height (this year’s robot, at full stretch, tops 3 meters). In addition, the robots typically need to survive about 20 two minute head-to-head rounds, and while technically you cannot deliberately damage a competitor’s robot, being rammed by a 50 kg robot on defence doing 15-20 kmph is going to have an impact. I should add that being in Australia adds to the challenge, as most of the parts (until recently) were only available from the US, so a team typically lost 2 weeks while they waited for parts to arrive. And when they finally built their robots, they had to fly their robot and team over to a regional contest somewhere in the United States in order to compete.
When I joined the RoboRoos had completed two robots. One was for an Australian off-season competition, called Duel Down Under, which uses the same rules as the official games and was offered as an alternative for teams that could not afford the trip to the US to compete officially. The other was used to compete in the 2013 contents, and which had been very successful in Hawaii, having been chosen as the Rookie-All-Star and thus earning them a place in the World Championship in St. Louis. The team itself was (and is) a great mix of people: the mentors are all parents, with appropriately varying skills, and the students range from grades 8 to 12. Surprisingly, (for me, anyway), the team has maintained a 50/50 gender mix, which isn’t something I see often in engineering and computing. Why is a matter of conjecture, but I’m of the belief that it owes a lot to capturing people in late primary school through the LEGO league, before they’ve been encouraged to move away from STEM subjects.
Having joined in late 2013, the first challenge that I faced came in early 2014: Aerial Assist. Imagine basketball played between robots, only where the ball is 1 meter in diameter. The robots had to pick up the ball, pass it between other robots on the same team, throw the ball raised over the center of the field, and get it through either a low goal (low enough to push a ball through) or the high goal (about 2 meters off the ground). We didn’t think it would be easy, but we thought we could manage the challenge, having had the success of the previous year.
When we started the build, we were told that we’d learnt three things from previous years. 1) Make the robot light and fast; 2) make it it shoot the ball quickly; and 3) ensure that it has a low centre of gravity. After spending the first five weeks of our six week build trying to work out how to shoot the ball, we finally settled on a design – a huge hammer wound back by a boat winch that would slam into the ball and send it flying. It was a fine plan. It also took 20 seconds to wind back, had a massive winch mounted on the top of the shooting mechanism, and was (as far as we could tell), just on the weight limit. Only it wasn’t – it was significantly over the weight limit. Thus when the team arrived in Hawaii they found that had to remove a considerable weight from the hammer, changing the performance so that instead of shooting the ball three meters, the best we could manage was under one. To do so, we had to wait 20 seconds for the arm to be wound back, and when we did wind it back we a) were so off balance due to the winch that the slightest tap could cause the robot to fall over, and b) were so top heavy we were unable to reset if we did manage to shoot the ball. It was the worst performing robot at the regional competition, which was an achievement of a sort.
Thus we have Rule 1: Slow, top heavy, and unbalanced robots are a really bad idea.
When the team returned from Hawaii we had to do something. The robot couldn’t be used for demonstrations, and the only role it could have was as a lesson in what not to do in the future. However, Duel Down Under was approaching, and rather than surrender the team made what was one of the best decisions we’ve made: we would try again, using anything we could salvage from the first robot, only this time we would build on what we’d seen other robots do in the competition. The result was an excellent robot, that performed extremely well at DDU, and considerably improved the skills of both the students and the mentors. The robot used a giant spring loaded catapult to shoot the ball, and was fast, well balanced and powerful. Sometimes you can get things right.
In 2014 the challenge was completely different. Rather than a ball game, the teams had to design robots that could stack crates – for maximum points, they needed to build a stack of 6 crates, place a recycling bin on top, and put a pool noodle in the bin. It was challenging, (and almost impossible for new teams), but uninspiring, and as a result “you shall be cursed to play Recycle Rush forever” has become a common curse in the online FRC communities.
Our robot was a tad unusual, though, as that was the year we tried mecanum wheels. Mecanum wheels provide their thrust at 45 degrees to the angle of rotation. Thus if we place a mecanum wheel on each corner of the robot, and then adjust the rotation of each wheel individually, we can make the robot move seamlessly in any direction. In theory, anyway.
In practice it worked out ok when the students were controlling the robot, but when we needed the robot to move autonomously we discovered a major problem – mecanum wheels only work properly when weight is distributed evenly across them, and we were building a robotic forklift. That’s not exactly the best possible combination. The end result was a good, solid robot, that worked consistently well under operator control, but where we were unable to get consistent results when it tried to drive itself. (There are methods of adjusting for the weight, but they didn’t prove to be an option in 2015). At least the robot was a big step forward from the first one we produced 2014, and we were able to compete in the first Australian regional at the Sydney Olympic Sports Centre. Therefore, we have Rule 2: Mecanum wheels are great, unless you are the one tasked with programming them.
My programming team did have one big win, though – we used strips of lights to indicate what the sensors were picking up to the drivers, and this opened up the possibility of a party mode. Since then, every robot we build – for FRC or otherwise – must have a party mode. From this emerges Rule 3: All robots can be improved through the addition of a party mode.
2016 was a very different year. The challenge changed again, as expected, but this time to a medieval theme where robots had to cross various “defences” (such as drawbridges, a moat, and a portcullis) to throw balls at a tower, and if possible, climb the tower at the end of the match. There were some beautiful robots in the competition, showing great engineering skills. The RoboRoos produced a six-wheeled robot using a unique drivebase incorporating three different types of wheels, and it was a solid performer. We made two mistakes though – we added a mechanism to pick up the balls at the last minute, and it damaged the robot’s balance, and we tried to build the entire thing from scratch, leading to a complex and reasonably fragile robot. The big lesson from this build was Rule 4: Don’t reinvent the wheel (or the drivebase).
There was also another major lesson that I had to pick up, but which I tried to keep quiet. One of the goals of the robot was to have it drive up to the portcullis and lift it. To do this we had to detect when the robot was in range, so we had the great idea of adding an ultrasonic sensor to tell the robot when it had to stop. It worked great – I even tested it by turning the robot on while it was off the ground and moving a “wall” in front of the robot to see if the wheels stopped. As it was going so well, I decided to try it in real life – I placed the robot on the ground facing a wall we had built, programmed it to drive until it was 30cm from the wall, and placed it in autonomous mode. The problem was that I am an idiot. I set the power to full, without realising just how fast the robot was. Therefore the robot rapidly went from zero to over 20kmph almost instantly, racing at full speed towards my wall. The ultrasonic worked perfectly, informing the robot that it had to stop, and it cut all power to the wheels. Sadly, we hadn’t thought to add brakes to the robot, so instead of a high speed robot trying to stop, I now had a 50kg high speed missile. It slammed into the wall and went straight through it. Now there was no longer a wall in front of the robot, and the sensors reacted by telling the robot that it was ok to apply full power – which it did. The robot traveled the full width of the room and was about to smash through an exterior wall when my frantic hitting of the emergency stop button finally had an effect.
Personally, though, the big change in 2016 was Robots in the Outback. Google and Ford sponsored a project where two teams of three mentors spent three weeks travelling to outback towns and teaching the students how to build robots to compete in the regional. We only had two days per school, but that was enough to build a basic robot and teach some programming. Thus at the regional that year I had six teams instead of the usual one, and it meant that I had someone to cheer for in every round. All of the teams were terrific, but three stood out for the work they did after we left – Dunedoo, who made a robot that was based around a bucket that we grabbed from the local hardware store; Narrabri who continued to work on their robot and produced a solid defensive design; and Wee Waa (I love the names of Australian towns) who turned their robot into a tractor complete with lights.
For me, the biggest revelation from Robots in the Outback was just how much I loved working with new teams. Established teams are great, but new teams give mentors an opportunity to share in the excitement of a student’s first robot over and over again.
To try and recapture some of that feeling, I worked with the RoboRoos to create a “training team” to compete at Duel Down Under, using the newest students and taking them through building a basic robot. The result was (as expected) a robot that wasn’t competitive, but was a huge amount of fun.
I should note that by “wasn’t competitive” I mean “we stuffed up”. It was never going to be a competitive robot, because that wasn’t what we were trying to do. However, there’s an interesting aspect to the robot design. The basic design we use is a six-wheeled robot where we employ “skid” or “tank” drive. For example, if we want the robot to turn clockwise, we drive the left wheels forward and turn the right wheels in reverse. This creates a potential problem, in that the middle wheels turn well, but the front and back wheels are being made to travel sideways, and they offer a lot of resistance. To limit this we use the West Coast System, where the middle wheels are positioned lower than the front and back pairs.This means that only four wheels are on the ground at any point in time, and the amount of resistance is only half what it would have been with six wheels touching the floor. But as we discovered, if you fail to inflate your tyres, all six wheels will be touching at all times, meaning that your beautifully designed robot can only move forwards and backwards – turning is almost impossible. This, as one might guess, taught us another important rule – Rule 5: Always inflate your tyres.
In 2017 the theme was “Steampunk”, and robots had three jobs – to shoot smallish balls into a goal; to deliver gears to “airships” on the field, and to climb a rope at the end. It was a difficult build for us, in part due to competing ideas of what to build, and in part because of a tendency to change direction each week. If there was a lesson from that year, it is probably Rule 6: When you have a plan, stick to it. That said, the robot had some nice aspects, not the least of which was the Winch of Doom. To make the robot climb one of the students had the inspired idea of creating a revolving cylinder with rows of spikes. At the end of the match we dropped a rope with a carefully placed knot. The robot would drive up to it and start spinning the cylinder. As the spikes revolved they would catch the knot and pull the rope in, allowing it to climb. It worked perfectly, but it always made me nervous.
The great news from 2017, though, was that the team won the engineering outreach ward for their activities over the year, and this took them to the World Championships in Houston. It was hard to ask for more.
Which brings us to 2018. After the stress of the 2017 competition, I thought it was about time to step back and leave it to others. It wasn’t a bad call, but to be honest I missed the robots far too much. So I’m back working on the Duel Down Under robot with a team of beginners, and we’ll see how we go. The competition this year involves robots that can place milk crates at various heights, and the basic model we’re using is that of a large arm that can lift a crate to around 3 metres off the ground. The goal of the DDU team is to take the robot that the main team built for the official campaign and make it better – which we’ve done, not by adding new features, but by replacing the complex gripper with two aluminium bars that have gardening gloves stuck to the ends. We’re also going to make it dance to Single Ladies by Beyonce, because that’s my new guide to judge the worth of a robot – if it can’t dance to Single Ladies, it isn’t worth building.
The big surprise, though, was that I now have to register as producing a robot that may fall under Australia’s international sanctions. Apparently adding a giant catapult to a robot is fine, as is adding the Winch of Doom, a high speed Frisbee shooter, and producing a 50kg robot with no brakes. But add a general purpose gripper that can be programmed to move in three dimensions and you’re in trouble.
The neat thing is that robots are still cool, and I’ve gone from no experience to touring Australian schools in 5 years. The situation has changed dramatically from when I was first dreaming of robotics – with Arduinos and the Raspberry Pi to play with, electronics have become manageable, even for a programmer such as me. 3D printers have made producing parts for small robots easy and enjoyable, and the ready availability of sensors make it easy to interface your robot with the real world. Robots can be built using cheap parts of eBay, and even humanoid bipedal robots are able to be built using readily available parts.