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.
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!
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”: