After the Competition

The good news is: we at least attempted all challenges and Phantom survived (mostly). The bad news is: we did very badly.

Here is how the “final” version of Phantom, our walker based on poorly understood alien technology, looked like (photos taken after the competition):

Unfortunately, Phantom was far from finished. We had to cut a lot of features that we initially intended to have during the last few months, but that wasn’t enough: we couldn’t even finish the essentials in time. Our goals have proven to be a bit too ambitious, and by spending a lot of time on various details, some of which were probably not essential, we ended up in a situation where everything was half- or almost finished, but nothing ready. (“Second-system effect” maybe?)

This led to last-minute assembly of the “final” version, including late-night re-printing of the chassis the day before to fix some sizing mistake, taking short-cuts where things didn’t quite fit together, like using Blu Tack – with a few minutes left at the end for testing and hacking on the software to at least make the basics work (the latter continuing even during the competition).

We also had a major problem with our choice of motors that only became apparent very late – see the previous post. This meant a lot of time wasted, and at the end we had to fall back to the small micro metal gear motors we used earlier: these had just about enough power to drive reliably, but were very slow. Ideally, you should finalise the mechanical / locomotion / motor control part of the robot first, and build everything higher level or fancier on these already stable foundations. In our case, the seriousness of the lack of precise control at low speeds only became obvious when we tried to implement control for the autonomous challenges – so maybe it’s a chicken and egg problem: you don’t really know if your “foundation” is good enough until you actually use it for real…

Despite all this, the overall journey was great fun, a lot of “crazy” experimenting with a huge amount of completely new things tried and learned – in no small part thanks to the awesome Pi Wars community! And even despite failing in literally every challenge, the final Sunday we’ve been waiting for a long time was amazing and we thoroughly enjoyed it!

And now, here is a summary of how and what we did at each challenge – and most importantly, the lessons learned (or should be learned)!

Pi Noon: The Right Stuff

We got “destroyed” in the first few minutes: our opponent, a much heavier robot, hit us from the left and a critical part of a single 3D-printed gearbox/motor assembly that connects the big gearbox with the motor, snapped. This was a fatal blow: with a broken gearbox, we couldn’t move and there was a risk of dropping out of the rest of the competitions for the day.

It wasn’t our opponent’s fault though: Pi Noon is supposed to be “non-destructive” but even if you’re not doing it intentionally, it’s inherently aggressive in the sense that you do need to drive at your opponent, and collisions are inevitable. If a heavy robot with a lot of motor power happens to hit sideways a weak or unprotected spot, damage is inevitable.

We didn’t have any spare parts, but fortunately we did bring lots of sticky tape, even two different kinds! So we managed to fix the broken gearbox. There was nothing else apart from the tape, nothing rigid to support the weight, and to prevent the left side from collapsing. It was a little bit wobbly, but amazingly, the tape held throughout the whole day!

Analysis

The main issue is that the part that snapped is cleary too weak: those two horizontal bits were supporting the whole weight of the robot and were too thin.

Phantom was not designed or even tested for Pi Noon, so the danger from this kind of collision wasn’t even considered.
The gearbox/motor assembly was actually a weaker, second version: the original design was for bigger motors, with wider and thicker struts. This second version was “Plan B”, designed hastily, “merging” parts of the original (holding a round motor) with a rectangluar holder for the small motors we had to revert to.
We should have done some stress-testing for the critical 3D-printed parts: nothing fancy, just testing it by hand to see how easy it is to break it would have helped!
We were planning to print and bring a spare gearbox complete with legs, just in case something breaks or fails during the day. Due to lack of time, this didn’t happen.
Sticky tape can be stronger than 3D-printed plastic!

Spirit of Curiosity

This was quite a straightforward challenge – you pick up a sample and bring it back, right? The reality is, getting over the crater in the middle was very dangerous as we weren’t sure if Phantom would survive a fall onto its back. The only other option was to go around which was very time-consuming and also the robot only just fitted into the canyon around the large “hill”, and so it was difficult to maneuver through it. The small bumps and uneven details were also a problem as the robot got stuck on them on more than one occasion. We still managed to bring back one piece of sample though!

Analysis

In theory, legs should be perfect for this terrain. Unfortunately, our motors didn’t have enough power. The legs were also quite small, as we wanted to keep the robot body as small as possible. Phantom was also very slow: even without getting stuck, we wouldn’t have been able to do many more round-trips in the allowed time.

We really need motors that are both more powerful and faster.
Making the legs a little bit bigger and/or changing the stride to lift the legs higher would definitely help here to avoid getting stuck.
Another problem (which we luckily didn’t encounter) was the chance of the sample falling out and having to go back to the pile again. To avoid this the robot should be quite stable and maybe it would have been nice to have added some sort of suspension.

The Canyons of Mars

We didn’t have high hopes for this challenge. The “proper” code was not ready and all the testing was done the night before, for about 5 minutes. So we just relied on a very simple idea that we were experimenting with: a simple, generic “behaviour” to keep going forward and avoid obstacles – just based on distance sensors, without knowing anything about the layout of the maze, or taking into account orientation or anything else.

The code is literally just a few lines. Here it is:

dist_sensor_angles = [-np.pi/2, -np.pi/4, 0, np.pi/4, np.pi/2]

[…]

def run_canyons(state):
    dists = state.get('dist', None)
    if not dists:
        return                                           # Return if distances not available yet
    state['speed'] = 7                                   # Drive at constant speed, forward (max. is 10)
    dist_vectors = [(dists[0], dist_sensor_angles[0]),   # Get the distances as vectors,
                    (dists[1], dist_sensor_angles[1]),   #   measured at ±90° (sides) and ±45° (front)
                    (dists[3], dist_sensor_angles[3]),   #   (and ignore the front sensor at 0°)
                    (dists[4], dist_sensor_angles[4])]
    dist_sum = sum_vectors(dist_vectors)                 # Add up the above vectors
    state['dist_sum'] = dist_sum
    state['dir'] = np.rad2deg(dist_sum[1]) * 1.8         # Turn towards dist_sum: the longest opening

This is how it looks in simulation, using the same exact code as above (the yellow “beam” is the dist_sum vector):

(One interesting thing learned from the simulation: at first, we tried it with only the three sensors at the front – it was much harder, almost impossible to navigate through without hitting a wall or turning back. But adding the left and right 90° sensors made a very big improvement!)

We didn’t win with this of course, but it worked surprisingly well: in our first try, we only needed one “rescue”, near the top left corner, and after that, our robot continued to the exit. On the second try, somewhere near the second bend, it turned back and found its way back to the entrance – taking a shortcut, which is completely reasonable if your “goal” is to escape, rather than to go through the maze!

Analysis

This “success” has proven that it was worth it to develop all the simulation tools, and that sometimes a very simple approach can work too.
With some more tweaks (e.g. something like disallowing 360° turns or backing off when getting too close to a wall and trying again), and a bit more real-life testing, this could have been made much more robust.
And of course: Phantom was slow – we need more speed!

Space Invaders

No surprises here. The shooter attachment simply didn’t make it: we had an idea, but this was one of the things that were completely left out at the end, due to lack of time. So we simply tried to nudge the balls but Phantom was too slow. The tiny motors we ended up using were just enough to slowly and carefully roll the balls over the white line, but not much further.

The Apollo 13 Obstacle Course

This challenge was fairly straightforward apart from the treadmill which was very frightening. We ended up skipping it because Phantom didn’t have any thing protecting it should it fall over and flip. The rest of the course wasn’t too difficult – the problem was time. The robot was simply very slow and so we only managed to do one lap and were over the time limit.

Analysis

The Oyumaru thermo plastic ’feet’ (a silicone-like material that melts easily in hot water and can then be formed by hand) were really useful in this challenge for gripping onto slopes (and just generally not falling over). The feet worked very well and didn’t come off (unlike last year’s wheels).
There were no problems with controllability. But we had an idea that we didn’t get around to implement: “absolute” directions for remote control: by using the compass (9DoF sensor) the joystick could be used to point to absolute directions: so instead of turning left relative to the current heading of the robot, you could point “left” to the “left” of the course. So it wouldn’t matter where you stand – as it’s quite difficult to move around the course and adjust your sense of direction when standing behind or in front of the robot.
We really didn’t have any practice driving before – even if the robot isn’t particularly fast, this would have helped, and some testing with any kind of mock course would have made us more confident!
We need more speed…

The Hubble Telescope Nebula Challenge

This was a perfect example of trying to do a bit of everything but finishing nothing: last year we didn’t attempt this challenge at all. This time, we spent quite a lot of time on perfecting the colour calibration, developing the tools for it, etc. The code was almost ready, the colour recognition worked perfectly, but the whole thing was left unfinished at the end, because of all the other tasks that seemed more critical, like fixing fundamental motor control problems.

So at the end we just attempted to use the “easy” method of trying to visit all corners, only using distances from walls (ToF sensors) and orientation (9DoF sensor) without using the camera at all. The code was put together in the pit room, with no real-world testing. It could have worked, but unfortunately it didn’t: some parameters (speed, minimum corner distances) were not set correctly, so Phantom ended up wandering around the course, looking very confused.

Analysis

Better prioritisation earlier could have helped: maybe giving up preparing for one of the simpler challenges completely, we could have saved some time to finish the work for this and at least have a good chance of doing this one correctly.
Brian Corteil’s Robot Club at the Cambridge Makespace was a great opportunity to test things in the real courses, under the same conditions as at the competition: but because we were always behind schedule, we mostly missed this!

Blast Off: the Straight-ish Line Speed Test

This is really the easiest of the autonomous challenges: as long as you have reliable sensors, there shouldn’t be a problem… We were relying on our ToF distance sensors and an even simpler algorithm than for Canyons of Mars. Again, we didn’t do much testing and wasn’t expecting to be fast, but maybe with some oscillations between the walls this should have worked just fine.

Unfortunately, one of the many leg joints on the right got stuck a little, so the right side could barely move. This resulted in the robot turning right in the beginning, and hitting the wall. The code was just pushing the motor to maximum power, trying to reach the set speed, but of course it wasn’t prepared for this fault. (Generally, in this case the right thing would be to reduce power to the other side to match the side that’s blocked, and keep going in the desired direction, just much slower.)

Analysis

It took a long time and a lot of experimenting to design the joints. Some of the challenges were: keeping the size small, ensuring the joints can rotate smoothly, but still making the joints as rigid as possible, reducing sideways motion to avoid too much wobble. The final design used M2 screws covered with PTFE tubing inside the joints, secured at the end with lock nuts press-fitted into the plastic parts (and with also some thread locker fluid). This seemed to work really well, and we didn’t see much of this issue of getting stuck before. However:

Assembling the legs was quite a long process and required manually cutting the PTFE tubes to exact sizes, and each screw had to be tightened “just right”. After assembly it was difficult to tell whether something was too tight or too loose, without actually trying to drive the robot and looking at the movement and checking the motor power for each side to see any differences.
The final version of the gearboxes and legs were assembled the day before, so these didn’t have much testing. It’s really odd that we only encountered this problem in the last challenge in probably the easiest situation and haven’t seen any issues before during the whole day! But this proves the unreliability of the current design / assembly process.
We need to improve the design of the joints to ensure we have smooth movement, without relying on manual adjustments. Maybe switching to ball bearings – at least on some of the joints – would help, and would also reduce sideways movement (and wobble).
The failure to drive straight also highlighted an issue with the software: even if it doesn’t have to be complicated, all software driving the robot should be much more robust to be able to deal with failures or degraded functionality: this probably needs a different mindset, to consider every possibility, all the what ifs and to fill in all those possible else if branches!

There is clearly a lot to keep us busy to fix all the problems we know of and finish everything properly for next time – the question is: will we do it or will we jump on to the next crazy idea and start from scratch again…?