One of the interesting things Adam does in his “spare” time is to build robots.
After taking a year off, in 2019 I returned to mentoring the local student robotics team, the RoboRoos. I enjoyed my break but I admit to missing the team, and even though difficult years can be more than a tad frustrating, when things are working there is little that I enjoy more. The RoboRoos is a community-based team consisting of high school students, alumni and a small number of parent/mentors.
As mentioned in a previous issue, each year the teams have been given a new task and six weeks to build a robot. The theme this year was “Destination: Deep Space” to coincide with the anniversary of the moon landing, and the task proved to be a complex one.
Our robot needed to prepare a shuttle by:
- Placing plastic hatches to cover holes in a transport and two rocket ships
- Place cargo (30cm rubber balls) into cargo units on the transport and rockets
- Climb to one of three levels on a “habitat” at the end of the game
The majority of points came from climbing at the end of the match, but points were also scored through the hatches and cargo. Unlike previous years, the robots were not required to be autonomous, as they were always under the control of their drivers – however, during the first 30 seconds of the match, a “sandstorm” prevented drivers from viewing their robots, and thus they had to drive using cameras.
Our team has been competing for some time, but while we started extremely well and we’ve been very successful off the field, in the competition our robots have always sat some distance behind the leaders. As a general rule – and I suspect that this applies to a range of similar pursuits – a successful team will need to do three things:
- Work out an effective strategy
- Design a robot that can meet the strategy
- Build a robot that meets the design
Naturally, these are not either/or propositions. It is possible to have an awful strategy, a perfect one, or something in between, and that is where the competition comes in. Most years we’ve failed to some degree on all three.
Work out an effective strategy
Competitions consist of a number of qualifying rounds in which teams either try to finish in the top eight (and thus become an alliance captain) or try to impress other teams so that they’ll be picked for a good alliance. Ranking is determined by ranking points, and these can be scored by winning a match, drawing a match, or by completing a predetermined task during each round. This year two tasks were on offer: to completely fill a rocket with six balls and six hatches, or to score 12 points in the climb at the end – typically managed by having one robot climb to the top level of the habitat, while one other robot parks itself at the bottom.
We were very lucky to have Jess as the student team captain this year as she led the strategy debate. I wanted to fill the rockets, as I wanted to score as many ranking points as were on offer. She, on the other hand, wanted to focus on scoring points on the transport and climbing. I was wrong and Jess had the right idea. The rocket, while appealing, would require our robot to lift the hatch six feet into the air, and while we technically could have done this we couldn’t have done it well. By focusing on scoring and climbing we could potentially pick up 3 out of the 4 ranking points each round, have a simpler build, and make a quicker robot that might be more likely to get the two ranking points from a win.
Once we were at the competition this proved to be the correct strategy. Sadly, implementing it was a problem.
Design a robot that can meet the strategy
With a good strategy in mind, the team had three big problems to solve: how do they pick up and deliver the cargo (balls); how to collect and place the hatches; and how on earth do they make a five foot, 50kg robot climb up on top of a table? While picking up a ball may seem like a minor issue compared to climbing, our problem is that we had never successfully been able to do this in the main competition. Every attempt has failed. The closest we’ve come to a working system was in 2015 with an off-season robot, and we managed that by copying more successful designs from other teams. That said, the principles are fairly simple, and after much deliberation we went with a grabber with a spinning wheel each side of the ball attached to an arm. Building it may be a challenge, but the idea was simple. We called the grabber “Doris”.
Picking up and placing the hatch was also fairly simple, but we did our best to complicate things. After going through a few ideas we narrowed the field to two. One was to latch on to the velcro on the side of the hatch and lift it up with that. The other was to build a spear that would be stuck through the middle, then open up like a triffid to hold the hatch in place. The first was boring, but would work. The second was complicated and entertaining, had the potential to work, but came with its own unique problem. Specifically, building a 50kg robot that could do 20kmph mounted with a spear that could pierce abdomens before suddenly expanding within the body lent itself to safety concerns. To address this we added a bust of Einstein to the tip, thus rounding it off. Some in the team argued that just removing the sharp point would be enough, but they lacked vision.
That said, the Einstein Thruster never worked, and we ended up going with velcro.
Climbing was always going to be an issue, and we ran through dozens of ideas, including scissor lifts; a huge balloon mounted underneath the robot that inflates to lift it up; using pneumatic cylinders to bounce it on to the platform; a giant suction cup; and lowering down a ramp that the robot then drives up. After a week of discussion, we gave up and just added stilts.
Build a robot that meets the design
Surprisingly, this was the best organised and most effective build we’ve ever done. I blame Jess as captain and Alan as project manager. It certainly wasn’t my fault. We built exactly what we intended, everything worked, we found time for driving practice and we did it all on schedule. It even met the weight requirements without having to spend days cutting holes into every flat piece of aluminium. It was, I’d argue, the first time we had the right strategy, a good design, and a successful build. We were very confident heading over to Sydney for the regionals.
I didn’t travel to Sydney this year. Instead, I followed everything online. Doris worked very well – we consistently collected the balls and scored during the matches. The hatch system also worked fine. The climber failed completely.
When the team arrived in Sydney they had the sensible idea of testing the climber. Unfortunately, they forgot to reconnect one of the switches, and the particular switch that they forgot about was the one that told the climber when to stop. Thus when they started the process, the winch started winding up and reached the point where it should stop, but the switch failed to trigger. The winch continued to wind up until it (literally) destroyed itself. Oops.
After a series of emergency rebuilding attempts, they still ended up nowhere. It failed to climb every round. That might have been ok, but some bad luck coupled with a strategy that depended on climbing meant that we were always behind and failed to make the finals.
The robot was good, but luck and an early crucial mistake took their toll.
Everyone back home was convinced that the robot could do better, so when the Duel Down Under came around we decided to enter the same robot again with only minor adjustments. Held in Sydney, DDU is a chance for teams to experiment, train and show off, without the pressure of the official competition. We did hit a complexity when we found that the new wheels were heavier than the old, forcing the mechanical team to spend many hours cutting holes into the robot in order to reduce the weight, but that was mechanical’s problem rather than software’s.
Thus everything was as before, but with a slightly modified climber and a bit more hope which was not entirely misplaced. The robot did climb. The climbs just didn’t count. The problem was that we had built a platform in Adelaide to test the climber, and the platform was – unsurprisingly – made of timber. Accordingly, the wheels had good grip and the robot went through the climbing routine with all the precision that we had imagined that it would possess. It never failed. However, the actual platform was made of High-Density Polyethylene (HDPE) which you may have encountered as the white and slippery plastic that bait boards and kitchen cutting boards are made of. Sadly, the “slippery” is more accurate than we may have hoped. Each time the robot climbed, it would almost get into position before slowly sliding backwards. It didn’t fall off, technically, but the rules required that our bumpers were above the level of the platform at the end of the climb, and by falling back a bit they were now just below.
We spent a lot of time in software trying to come up with a solution, but the problem was a lack of control. If the surface wasn’t slippery we could easily overcome the issue. But as it was, every solution that incorporated delicate driving was out. A mechanical solution was our only option, so we made two changes: a) we purchased some door stops from KMart which we fitted just in front of the real wheels, raising the back of the robot after the inevitable fall; and b) we raised the height of the bumpers to the limits of what was legal. We still fell back, but the bumpers were now 5mm clear.
Not that we were entirely in the clear – we had two significant falls where we failed to even get close. But overall this was enough to get us into the top 16. We managed to win the first round of the finals, and even though we didn’t make it into the final two, everyone was very pleased. This was the robot that we had set out to make.
The next competition has just started, with the FIRST Tech Challenge (smaller robots, but the same general idea) now about four weeks in. With a new home and a solid year behind us, might this be the season when our robot finally takes us to the World Championship?