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!

IMG_20170325_170928461Well, 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:

IMG_20170317_102155684The 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!C6otTkGWcAAxLb3

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.)

IIMG_jgt883 (1) 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.