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.