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.

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!

Time is rushing by!

Well, the competition that seemed so far in the distant future is now less than a month away, and it feels like there is still so much to do! But unfortunately I (and the rest of the team) don’t have a huge amount of time to devote to it. Although my “day job” is related to some of the challenges (I lecture in Computer Science at Manchester Metropolitan University, and my research interests are in autonomous software), I don’t get a chance to work on Glitterator in this time, and it takes up a significant part of my week. And then this week too we had both world book day (child’s costume to make for school), and most importantly, my youngest’s birthday (and associated party on Saturday). In fact I won tickets to the Saturday session of the raspberry pi birthday bash, but could go because of my daughter’s party. (I thought I’d entered for Sunday tickets – but really it’s a good thing that they weren’t, because that would have been another day’s less work on Glitterator – and we got quite a bit done on Sunday.)

This week also saw the release of the zero w, and Pimoroni released some really cool kits to go with it. As soon as I saw them, I placed an order for a mood light kit, for my daughter’s birthday present. And thanks to the efficiency of the Pimoroni crew, it was delivered on her birthday. Of course then I realised my mistake… two more sets of headers to solder! (One for the zero w, one for the unicorn hat.) I managed to have this ready for her when she got home from school on Friday, but then we ran into a problem – we couldn’t get the unicorn hat code to work on the zero w! Thankfully we are the sort of household that has spare old-model zeroes lying around, so I could swap one of these in. (We don’t really need wireless on a mood light anyway.) She had a great time putting it together, and is very happy with the finished product!

Also released alongside the zero w was the new scroll pHAT HD, and I’ve snapped one of these up to add glitter to Glitterator. I’ve made a little sandwich out of the zero w, a mote pHAT and the scroll pHAT HD (this involved soldering another two sets of headers of course 🙄), and had it running in my office yesterday to blind all comers. 😉   Ultimately, I’m aiming to have this sitting on top of Glitterator, replacing at least some of the mote sticks with flexible APA102 strips, and the pi3 “brains” of Glitterator sending high-level commands to the zero, which will run the low level code to drive the lights.

Also this weekend, we managed to get a maze built, and started to do some testing with this. And here we ran into problems. Glitterator has a real tendency to veer off to the right. This is because of its compact design, which means the motors are mounted at an offset to each other, and so to get the drive shafts in the same position on each side, the right hand motor is geared (with a 1:1 ratio) to shift the drive. The problem is, Lego gears are far from perfect, and we get quite a bit of “skipping”, resulting in the right track turning more slowly, and so the veering to the right. I’d noticed it a bit in the straight line speed test runs, but thought it was something to do with my coding rather than the hardware. So this is a problem we need to work on. But we also had a bigger problem that I haven’t had a chance to debug yet… after several tests, working quite happily with our ToF sensors, Glitterator started rebooting when these were attached. At first I thought it might be overheating, but hard driving using the remote without the sensors attached made it even hotter and yet not reboot. And then I ran out of time… so that’s a problem I will have to solve next weekend!


One final issue that cropped up is how difficult it is to do fine-grained control with the remote. Essentially, the top speed is so fast that it’s very difficult to manipulate at low speeds with the little joysticks on the PS3 controller. I think I have a solution to this: I’ll make use of a couple of the buttons on the controllers to increase/decrease the max speed. (So for example if you decrease, flicking to full forward will only drive at 90% of the max speed.) Again, I ran out of time so didn’t get a chance to implement this, but I will probably have a chance to handle this mod one evening this week.

Wiring! Success at the end of the day.

So… turns out my APA102 strips aren’t so bad after all. After some discussion with the wonderful Phil Howard on Pimoroni’s forums, he confirmed that my approach should work, and either my joints were dodgy (I didn’t think so, I’ve done quite a bit of soldering along the way), or the data and clock wires were the wrong way round.

Just to be sure, I redid the soldering, alternating the wires on either side of the strip, like so:


the theory being there’d be less chance of shorting between the pads this way. Still no joy. So then I tried switching the data and clock wires (the photo above actually shows after they had been switched). And oh joy, it works! Here’s a strip of the APA102 LEDs working together with 3 Mote sticks, running off the Mote controller board:

A Frustrating Weekend!

So, now that things are starting to come together, I decided it was time to think about the glitter in Glitterator. I have some Mote sticks that I was planning to use on it, but they are considerably bigger than the bot. Brian Corteil helpfully pointed me towards APA102 LEDs, which is essentially what the Mote sticks are made of, and can be purchased in strips. So I got myself a strip of them, and set about getting them to work. Cue much frustration!

I’d done a bit of research, and realised that they are unlikely to work directly of the Pi3 controlling Glitterator, with all the other work it is doing, due to the very fast timing of the protocol. But I figured that I could at least test them out with another Pi I have, that’s not running anything else – there are plenty of examples out there on the web of people doing this. So I got myself a level-shifter (APA102 operate at 5V) and connected a short length (3 LEDs) up to a spare Pi3 via the SPI0 pins. Then I grabbed the Adafruit Dotstar library for raspberry pi and write a short python script that should have just set each of the LEDs to red, green and blue respectively, blinking them on and off. Something happened, but not what I wanted. Lights went on and off, but not according to the timing in my script (1 sec on, 1 sec off), and while the first and second LEDs sometimes showed red and green, they also showed a bunch of other colours, and the third LED never showed the blue it was meant to (but did show other colours). Just in case it was a problem with the library, I also tried it with this library, but had the same problem. I suspect it’s a timing issue, because there was something happening, just not what I wanted… I also tried it using a pi zero, with the same results. I suspect that to pursue this path, I’m going to need a dedicated microcontroller, such as an arduino of some sort, receiving high level commands from the pi… but I’d like to spend most of my time leading up to the competition refining the algorithms for the challenges, not learning a whole new architecture. (While I would like to play with them, now is not the time!)

So then I thought “Well, if the Mote sticks are just APA102s, I should be able to drive my strip off the Mote controller board!” So I sliced up a USB cable and wired it to a section (12 LEDs) of the APA102 strip:


Then I plugged it in to the Mote controller board, and that into my computer, and a random selection of LEDs lit up, and stayed lit up. The mote sticks on the other three sockets of the controller still worked fine – here they are in the process of showing a rainbow:


While the Mote sticks cycled nicely through the pattern, the strip stayed static. I’m going to look again at the wiring – particularly the joints and whether I have the clock and data the right way round – but given that I’ve re-wired it several times (started with a much longer strip) and got the same result, I would be surprised if it’s the soldering. At this rate, I might just take a cutter to my Mote strips so that they are the appropriate length.

We did make some positive progress this weekend though, with work on the flicker for skittles. Angus and Peter have managed to put together a good strong “kick” from lego technics and an additional motor:

Unfortunately we still have some issues with fine grained control and weight distribution, making the ball capture not so good:

Still, it’s a great First-Attempt-In-Learning 🙂

The difference between satisficing and satisfaction…


“To decide on and pursue a course of action that will satisfy the minimum requirements necessary to achieve a particular goal.” (Oxford English Dictionary, online (accessed 20/02/2017))

We now have a robot that can attempt most of the challenges. The ball flicker for the skittles challenge is still a work in progress, but should get there. So currently, we can complete:

  • Straight-Line Speed Test
  • Minimal Maze
  • Line Following
  • Pi Noon – the Robot vs Robot Duel
  • Obstacle Course
  • Slightly Deranged Golf

The problem is, there’s a big difference between between completing a challenge and doing it well! I think we can complete the straight-line speed test without hitting the walls, but at this stage, straight we are not.

 And similar for the minimal maze. For the line following, we can (mostly) stick to the line, but it can be a bit of a jerky traversal. The remote control stuff we are pretty happy with… but overall, we are far from satisfied! Soooo… over the next few weeks we will be tweaking, tuning, refining and decorating Glitterator.

Tweaking, tuning and refining to do things like removing steering over-correction, removing the jerkiness from our line following, and generally speeding things up. (Currently we run at best at 70% of our maximum speed, or things get out of control!)

As I said, the ball flicker is a work in progress: at the moment just being tested with a separate battery pack, as seen here. 

And decorating because currently Glitterator does not glitter at all. The original plan was to put some motes on, but Glitterator’s footprint has ended up being considerably smaller than first planned, and the mote sticks stick out like jousting poles. We could work with that, but it might make the maze and obstacle course more challenging. So instead I think we’ll be looking at some strips of APA102 LEDs. I’m not sure though if we’ll need another controller to handle them, as their control relies on timing, and we might have too much other stuff going on on the pi… we’ll have to see what happens. (They’re on order and we haven’t had a chance to test them yet.)

Anyway, where we’re at is that we have a robot that (mostly) works, but we’re far from satisfaction. Hopefully over the next few weeks we’ll be shifting more towards satisfaction.