Post Competition Roundup

We’ve had a fabulous (but exhausting) weekend at PiWars. Once again massive thanks to Michael Horne and Tim Richardson for making it all happen.

We travelled down on Saturday, arriving about lunch time and headed straight in to check out the schools competition. Of course before we’d even arrived I’d seen pics on twitter of the various challenges, so no surprises when we got there. It was great to see such enthusiasm from all the participants and spectators, and to finally meet in the flesh so many people with whom I’ve been interacting on twitter for the last few months.

Angus and Erin both had a great time checking out the competitions (and the vendor stands), and Angus was itching to bring Glitterator in to show it off, but I convinced him to hold off until Sunday. I’m really glad that we went on Saturday, because as it turned out on Sunday we were so busy that we barely had a chance to see anyone else competing! Anyway, we met up with our Cambridge-based friend at the competition on Saturday, and after a good look around, went off for a relaxing drink by the Cam. Not a bad place for a pint!

Anyway, after a very restless night, with three of the four of us coughing regularly and waking each other up, it was off to the competition on Sunday morning. As our first challenge wasn’t scheduled until 11:40, we arrived well after the 9am door opening for competitors, and grabbed the last free corner in the team room. There weren’t many other competitors actually in there when we arrived, but we were happy to realise that on the table next to us was another regular at the Manchester Raspberry Jam, with her robot Frankenrobot. However we saw very little of each other, passing occasionally as we went from one challenge to the next. I was happy at the end of the day though to wander down to see the finals of the Pi Noon challenge and discover that she had made the quarter finals, and progressed through to the semi finals.  Here’s her quarter final:

And what about our challenges? Well, our first was a Pi Noon heat, and unfortunately it didn’t go so well. It was looking good at first, with “first blood” (one balloon popped), but then things fell apart, starting with trim falling off, then a balloon needing adjustment, and ultimately the controls went dead.

Angus was extremely discouraged by this setback, and I tried to pep him up. We headed back to the team room, checked it out, and everything seemed fine. So we headed down for the artistic merit, technical merit and funniest robot judging. That complete, we quickly grabbed some lunch and headed for the next challenge: the obstacle course. Unfortunately while the controller had worked fine for showing off at the judging, when we got to the course, it was completely dead, and wouldn’t get the robot to move one bit. Thankfully we were told that we could return later if we fixed the problem, and have another try. So while Peter headed off to see if we could get the same allowance on the skittles (which also required remote control, and where we were due very shortly), Angus and I headed back to the team room to see if we could work out the problem.

It actually turned out to be quite simple: the batteries were flat. So I put it on the charger, and thanked heavens that the next challenges were autonomous ones: maze and line following. So while the controller charged, we headed off to attempt those ones. But there we encountered yet another problem: we had a dead motor. Aaaaargh! At this point, I was ready to give up, but not Angus. He headed back to the team room, completely stripped the robot and reassembled it with spare motors, which were not quite as powerful, but he reckoned would do the job. So then we headed down to try the straight line speed test, with fingers crossed. Our first run was looking good, until inexplicably just before the end it veered off and hit a wall, falling over. Thankfully our next two runs we clear… not exactly speedy, but reached the end without touching!

This was a big boost for all of us, so we rushed to have a go at all the remaining challenges, squeezing in between other competitors for ones we’d had to skip earlier. Everything went smoothly except for the line follower. We saw the line happily, but unfortunately I had forgotten to compensate for the less powerful motors in our code, so when we came to a corner, I slowed the motors down too far and it just stalled and didn’t move at all 😭. Oh well. In the end, we were very happy with our recovery, and managed to complete all of the challenges except for that one.

And the result? Well, we came second in the beginners’ section of the maze, with one clear run and one with just one touch. And overall we came 5th out of 15 beginners, so we were all pretty happy with that.

And even with 5th place, we received such an amazing bag of loot! Thank you too all the sponsors who contributed to this, and to everyone who helped inspire my kids to keep trying and do it all again next time.

Lessons learned

So at the end of it all, the question of course is: What did we learn?? Here are a few of ours:

1. Spares. Lots of them. Assume things will fail!
2. Charged batteries. And spare charged batteries. And if you have a controller that doesn’t have removable batteries, make sure it is fully charged! (We failed on that last point, but for our removable batteries had plenty of spares and made use of them. Other teams failed on this point, thinking they’d have time between challenges to recharge)
3. We’d probably have been better off with point-to-point wireless (with a WAP on the robot). We found that wireless coverage there to be really laggy at times. I did spend a bit of time a few weeks ago looking at this, but put it in the too hard basket. I wish I hadn’t.
4. Wiring/cables: Neatness isn’t just for looks. We thought at first that we’d burnt out one of the motors, but in retrospect I think in fact that it’s just that its cable has been damaged (although we haven’t done the testing to confirm this hypothesis yet). If it hadn’t been so long and occasionally trailing about, we wouldn’t have had this problem.
5. Lego: Great for prototyping. Easily repairable (something we took advantage of on the day). But falls apart a bit too easily. We’ve got split feelings on this one. Half the team want to continue with Lego next time; I’d prefer something more reliable.
6. And over the longer course of things: give yourself time. We worked pretty consistently on this since we found out about the competition (before we even knew if we would be selected for entry). By working this way, we were able to try out lots of different options and had a robot that could have a go at every challenge. Given more time (and money) we would have done better, but for a first go at building a robot, we were happy with what we achieved.

Anyway, it’s goodbye to Pi Wars to 2017, but we’ll be looking forward to the next challenges.

Last minute hiccups (of course!)

Well, my last classroom sessions this term were yesterday, and by the end of them, my voice was gone. I was hoping that it was just the intensity of the last sessions, but unfortunately today I am still mostly voiceless. And then Angus woke up in the middle of the night with a raging fever and coughing uncontrollably, ending up staying home from school today. At least half the team was healthy, right? Wrong. Despite Erin being fine when I dropped her at school this morning, I got a call from school just after lunch to say that she was poorly and could I come and collect her. Poor mite had a dreadful earache, but fortunately that pain was numbed with some paracetamol.

Meanwhile, I’d spent the morning tweaking our line following (it still occasionally wanders off the line, but hopefully won’t in competition) and the lights (where most of the effort went). All was going pretty well until I went to collect Erin from school, when I left the bot running. When I came back, the battery readings were all still fine, but the Pi wasn’t on. And I couldn’t get it to turn on, even with disconnecting/reconnecting the batteries. I headed off to find a spare Pi, but as I did that, I thought “I’ll just see if it will boot from a phone power bank,” and it did. So I finished off the work I was doing on the lights before worrying too much about what might be causing the problem. My big concern was that it might be the voltage regulator – the one thing for which I don’t have a spare. (I did mean to get one, after trying this one out, but somehow it slipped off the radar.)

Anyway, after working on the lights, and committing all to GitHub, I was gearing myself up to tackle the power problem, and I thought “I’ll just plug the batteries in again, to make sure.” So I did. And everything worked. Which is all very nice, but now I have this worry that it will fail all over again in the middle of the competition on Sunday!

Anyway, we’re heading for Cambridge tomorrow morning. Three of us poorly (hopefully not so in the morning). It’s been years since I’ve been in Cambridge, so I’m looking forward to seeing it again – lovely place! It also means a great chance to catch up with my very good friend who lives and works there. And of course the competition. 😄

Sheesh! I just can’t stop writing

I know, I said two (or was it three?) posts ago that I wasn’t going to post an update until just before the competition, but I need to share this too.

I took Glitterator into work this morning, because I wanted to test it in a long corridor before the crowds arrived, so 8am saw me running it down the wall, and while it’s not quite straight (in fact it looks rather drunk!), it does manage to avoid the wall, so I think we’ll complete that course, although maybe not with the best of times.

And since I had it with me anyway, I decided to take it along to my lecture to show my students today. Now robotics doesn’t really have anything much to do with the topic of that lecture – it was the final lecture in a unit on programming languages and compilers, a core unit for all Computer Science students – but just before that lecture, they’d all been sent an email promoting the PGCE in teaching. I used the robot as a way of promoting student engagement and making IT/programming exciting, and there certainly was some interest. I also directed them to this blog, so we’ll see if any leave comments 😉

I wasn’t going to post again this weekend, but…

I was so happy with our achievements today! You may have noticed that in the maze navigation video we posted yesterday, we had a few wall touches. We started the day by tweaking parameters, and now we get much better clearance of the maze.

And then it was on to the lights… we essentially needed to get everything else sorted out before we could work out where they would be attached. In the end, we’ve decided to go with a layer on the top of the Pi casing, and strips along each of the tracks. The strip on the left side will need to come off for the maze, because the sensors will need to be there then.

We do have the potential to drive four sets of LEDs with the Mote phat, but at this stage at least, we think we’ll stick to these three. The challenge then was to build the layer for the top from the strips we had. So… 4 strips of LEDs, 12 pieces of wire, plus the butchered USB cable to connect.

If nothing else, my soldering skills have improved through this competition! Anyway, fully expecting an error, I put it together piece by piece, testing each bit as I went. And when I got to the third piece, I encountered a problem. Each piece had 6 LEDs, so 3 pieces = 18 LEDs. At at that point, only 16 would light up! This happens to be the number of LEDs on a Mote stick, so I had a good idea what the problem was. A quick look at the Mote phat driver code confirmed that indeed this limit was coded in, but it was an easy change to reset it and reinstall the driver. And then it all worked, without having to do any re-soldering! And then we had to have a test drive:

So with that done, we decided to take a break, and headed off to the pub for a team photo 🙂

We’ll fiddle with our lights through the week, and I plan to test the straight line speed test early tomorrow morning in a corridor at work – we simply don’t have a long enough straight at home! We’re happy though – Pi Wars, here we come!

A Fruitful Day!

Well, the combination of unreliable motors and limited sensors was driving me crazy with the maze. In retrospect, I’d add an accelerometer to the robot next time, so that I could be sure about position when turning. I’m using a simple left-hand rule for the maze, working on the principle that if the maze is simply connected (technical term that, meaning that all the walls are connected together or to the outer boundary), if you keep your left hand on a wall at all times, you can keep going and eventually you’ll get out the exit. Based on this, I can make do with just sensors on the left and front of the robot. But the “sticky-outy” bit in the middle of the maze was causing me grief, because it wasn’t so easy to determine when I’d cleared it, and the robot had a tendency to end up in the open(-ish) space in front of it going round and round in circles.

I toyed with the idea of adding an I2C-based accelerometer during the week, but I’m not going to have any time to work on the robot next week anyway, so that was never a realistic option. So in the end, I’ve ended up hard-coding the left hand turn, tweaking speed parameters on the left and right motors until it turned with the appropriate circumference. And it appears to work (thank heavens!). Multiple tests, a few slight touches on the wall, but can definitely solve the maze 😀

And the added excitement for today is that I’ve collected our team t-shirts from the wonderful Sue at Heatherhill Farm Embroidery. (As seen in the image at the top of the post.) Now I just need to get Glitterator glittering to match the shirts!

 

Final Stretch!

Well, we feel like we’ll have something to show next Sunday, but we still have a fair bit of work to do this weekend. The skittle ball launcher has been completely redesigned, and seems to do its job, but it still needs to be thoroughly tested. The maze traversal is much improved, but that sticky-outy bit in the middle is still causing some headaches.

But the best news is, we have some glitter… our main task now is to work out how to mount our light show. The light show is managed by a pi zero, which has both a mote phat and scroll phat HD. The pi 3 that controls the robot sends high level commands to the pi zero, which then runs the low-level code to drive the light show. This is achieved by connecting the pis by USB, and using rPyC to create a service on the pi zero that has two threads, one for each phat. The pi 3 then issues commands like pulse(“red”) and the lights change accordingly. At the moment, I’ve just got the mote sticks connected to the mote phat, but another task for this weekend is to hack some wiring that will allow APA102 strips to connect instead, and work out how exactly these are going to be arranged on the robot.

Ooh, and we had an email today which confirms that we’re not the only ones having trouble with the line following samples, and hopefully there will be an electrical tape track for poor souls like us. I was rather resigned to just bombing out on that challenge, but we tested thoroughly with electrical tape last weekend and that went well. In an ideal world, we’d get it faster and smoother, but it seems to work.

We’re all looking forward to the competition, but most of all, we’re looking forward to seeing what everyone else has done with their robots.

We’ll give another update probably just before we set off, and a round up after the competition.

Temperature control

After posting my update yesterday, I realised that there was one thing that I forgot to mention: our OKI-78SR-5 switching voltage regulator arrived last week, and replaced the old voltage regulator in Glitterator. Oh how I wish I had pushed harder for this earlier on! It has made such a difference to the performance of the robot. Not only does it not overheat, the battery life is massively better. No longer dissipating all that power as heat!

Now we are getting hot motors, but hopefully we won’t fry them!

Jinxed myself?

Last week a few competitors had minor disasters with their builds, reporting on twitter that they’d managed to “fry” their Pis. This is something that I’ve been worried about doing all along (especially now that we’re running on 12-ish V of batteries), but thankfully it hasn’t happened. Unfortunately I had a worse disaster last Thursday. I  closed the lid on my Macbook Air, went to get myself a coffee, and when I came back, it was completely unresponsive. It’s a very old computer – a month or so ago, Facebook flagged up the 5-year memory of me unboxing it – so well out of warranty. Googling suggested a SMC reset might solve the problem, but the recommended key combination had no effect. So the next step was to disconnect the battery, which required a specialist pentalobe screwdriver to open it up, allowing me to get to the battery connector. Sadly though this didn’t help, so I have a very dead laptop. If you’ve ever wondered what the inside of a MacBook Air looks like, here you go:

The vast majority (the four big slabs) is battery. Everything else is on that board at the top near the hinges. Anyway, after that diversion, it was back to Pi Wars work.

So… during the week, a sample of the line following course was delivered. And on Friday morning we received a skittles set. Meanwhile, I wanted to test and refine code for line following, straight line speed test, and maze solving. And there’s still the glitter! So we had a lot to pack in this weekend… and on top of this, Peter was involved in organising a local fell race, and the kids were both competing in the junior races. So lets consider each challenge one by one.

1. Straight line speed test.

Our biggest problem here is that we just don’t have space in our house that is the length of the course. So we have to test over shorter distances. It works fine over these shorter distances, but I’m a bit worried what might happen as it builds up speed over a longer course. I’ll probably bring it in to work to test along a corridor wall early one morning, so that I can feel more comfortable about it. I might need to limit the upper speed. We’ll see.

2. Minimal maze.

I’ve decided to use a wall-following algorithm for this. This means that we don’t necessarily travel the shortest path, but in theory we should be able to solve any maze (at least any that doesn’t have “islands”). It uses two sensors on the left hand side to follow the wall on that side. At the moment, it does the travelling straight well (same code as straight line speed test), and turns right happily, but the bit at the middle where it has to turn left around the sticky-out wall still needs some fine tuning. It mostly works, but could do better here.

3. Line following.

This works nicely so long as the robot hasn’t been running for too long… After it’s been running for a while though, it doesn’t respond to sensor detection changes quickly enough, indicating that either Python or the OS (or both) is getting in the way. And worryingly, it doesn’t seem to pick up the line on the sample that we received, even though it works fine on the black tape on the floor. At this stage, I’m really not sure what to do about this. I think we’ll just have to hope that the lighting conditions at the venue are sufficiently different that we can see the line on the course. If not, I don’t think we’ll be the only ones struggling, as we’re using fairly common TCRT5000 sensors. Here we are going nicely on Saturday:

4. Pi Noon

Angus is fairly confident about his control of the robot, but we’ll just have to wait and see with this one. He did get a chance to have a go at the competition at Brian Corteil’s stand at the Derby Mini Maker Faire last autumn, so he knows what he needs to do.

5. Obstacle course.

Again, we’ll have to see what is thrown at us. I’m not sure our control is accurate enough for everything that could be thrown at us, but again, we’ll wait and see.

6. Skittles.

With the arrival of our skittles set on Friday – I think it is the same as the one which will be used in the competition – we could work on refining our game. Some adjustment was needed for the ball catcher, as the ball from the set is slightly larger than the one we had been testing with. That done, ball catching was tested and worked nicely. However… firing the ball is not so great. In fact it’s pretty pathetic. Yes, the ball can be launched, but then it trickles down the course to touch the skittles, but without enough force to fell a single one. 😦 So if we’re going to manage this challenge, some hardware redesign is needed, I think.

7. Crazy golf.

Again, very hard to tell how this will go. The plan is to dribble the ball around the course and push it into the hole, but without having any idea of what the course will be like, it depends on what hazards are thrown at us.

And don’t forget the glitter!

And ticking along in the back of my mind was the fact that I want to make Glitterator glitter. I’d managed to get my pi zero connected to the pi 3 via USB, and the pi zero has a mote phat and scroll phat hd. The challenge is to get it working so that the pi 3 can send high level commands to the pi zero, which should then put on the appropriate light show. Well, to achieve this I’m using RPyC, and late yesterday managed to set up a RPyC server on the zero, to which the pi 3 sends a command that launches one of the demos for the scroll phat hd. So in principle this now works 😀 Next step is to add the detail! I’d like to have the scroll phat display the challenge name, and some glitter on the APA102s. We also need to decide exactly where the LEDs are going to go!

And finally…

I took quite a lot of pictures and videos yesterday, both of the fell race and the Pi Wars work. Here’s the start of Erin’s race, and Angus nearing the end of his:

Anyway, all of the pics and videos were taken with my Android phone, and at the end of the day, Google presented me with this mashup, focusing on the Pi Wars development. I had no input at all in the creation of this video (other than taking the original pics!).

Oh, and very finally, Tiny (our cat) was very proud of her successful “kill”:

Hot hot hot!

So… Peter loves his dinky little voltage regulator, but I believe that it is the root of all our problems. I went to revisit the issue I was having with connecting the ToF sensors and it all worked fine. So I did quite a bit of work on the maze navigation, and it all worked fine… for a while. And then the same thing started happening again, and I got a blister on my finger by accidentally touching the chunk of aluminium that is attached to the voltage regulator as a heat sink.

Fortunately Saturday was Manchester Raspberry Jam day, and we were there working on Glitterator, with a wealth of experience around us. I’d already had some feedback here on the blog that I might want to consider a switching regulator rather than the linear one, but Peter didn’t think it was going to be an issue. Thankfully I had the chance to talk it over at the Jam with Pete Lomas, who recommended this switching one, which should have about 90% efficiency. We should get less hot and use less battery. Anyway, I’ve ordered one, and hopefully should have it in hand in the next day or two.

Quite a bit of our time at the Jam was spent working on our skittles ball flicker. The mods I did during the week make catching the ball achievable (Angus says he just needs more practice to perfect it), but the ball launcher needed work. The first problem was difficult to isolate: on button press on the controller, it was meant to run the motor that launches the ball for a short time, then shut off. Problem was, it wasn’t shutting off. And so it was winding back the launch lever way too far, eventually destroying the construction. (Fortunately being Lego, it’s relatively easy to reconstruct.) Anyway, after much staring at it, it was suggested that it was the time.sleep() that was the problem – the code wasn’t getting woken up after this to stop the motor. So I changed the behaviour to use the button as a toggle for the motor – first press turns it on, second turns it off.  So the human driver needs to remember to turn it off, but we don’t have to rely on the sleep(). Why was the sleep() not working? Not sure exactly, but maybe a different thread as getting notified rather than that one… Anyway, with that problem solved, Angus could focus on the physical construction, which has had to evolve due to weight distribution issues. Now we have a problem with thread (as in polyester thread) breaking… so either we need stronger thread or somehow adjust the construction to avoid this.

Directly on the other side of us was another Pi Wars entrant, working on his robot snake, which is incredibly impressive. I sure wouldn’t want to be doing the maths to work out the driving of that one!

The Raspberry Blonde was also there, working on distance sensors for her Pi Wars bot. And there were plenty of other people working on other raspberry pi projects too!  Two down from us, someone had got to exactly the same point as me with communication between pi 3 and pi zero over USB: both of us can ssh in to the pi zero using the .local network. I’d like to go one step further than that, and set up RPCs over the USB link, but will have to do some more research on that. (For us, this is so that the pi zero can drive our LEDs, separate from the controller of the robot; the other guy wants to use an array of zeros with cameras to take multi-perspective pictures.)

I took a break from Pi Wars in the afternoon, to attend the gpiozero tutorial run by Ben Nuttall, with Erin. She had a great time messing about with the traffic lights, enjoying learning how to make them go super-fast, and declaring “I’m having fun, but they’re learning!” as if that was a bad thing. (Of course she did learn quite a bit, but I don’t think she realises this 🙄  7 year olds!)

Over the next few weeks, I’ll be tweaking code for the autonomous challenges, but the main focus will be setting up our glittery-ness with Erin.

Dealing with uncertainty

So much of working with robots is about dealing with uncertainty, because they operate in an open environment, and are fitted with sensors (inputs) and actuators (outputs) that don’t necessarily do what you want them to do. In the case of Pi Wars, our environments are reasonably constrained, but we still have to deal with both sensors and motors that don’t always do exactly what we want. To some extent we can control this by choosing bigger / better / faster / more accurate versions of these things, but (1) you can’t eliminate these problems entirely, and more importantly (2) we don’t want to spend a fortune on our robot! So rather than trying to eliminate the uncertainty, we’re trying to deal with it instead. And happily, last night I got a chance to do a bit of work on this.

In my last blog post, I mentioned a couple of problems with the remote control of Glitterator. The first was that it was very difficult to do fine-grained control of the robot, because the top speed is so high, and the difference between zero and max on the joystick controls is so small. The second was a tendency to drift right, because of our need to offset the motors, which in turn requires the right motor to be geared (on a 1:1 ratio), and the gears aren’t great and so skip sometimes. The right track thus turns a bit slower than the left, and so it drifts to the right.

I’ve addressed the first problem by using a couple of the PS3 controller buttons to adjust the maximum speed. One button increases by 10%, the other decreases by 10%. So you can slow it right down to do fine-grained manoeuvres, but speed it up when you want to race about with little accuracy. This seems to greatly improve the remote control, and should make things like ball capture for the skittle competition considerably easier.

To address the second problem, I’ve simply slowed down the left motor slightly. This isn’t a perfect solution, because the skipping on the right motor isn’t consistent, but it does give something much closer to straight line movement. The slight deviations can be adjusted manually for the remote driving, or by checking sensors and adjusting automatically for the autonomous ones.

So, happy to have addressed these issues midweek; now just have to worry about my sensor problems on the weekend!

P.S. Dealing with uncertainty is a big part of my research – but not in the context of robotics. I’m interested in modelling human behaviour, and particularly how they gather information and make decisions without knowing everything about everything!