Rainbow time!

It’s been a productive weekend our PiWars efforts. Not only are our blog posts finally tumbling out, but progress is being made on the software and hardware. I’ve been playing with OpenCV, using still images of the balls under various lighting conditions, and I’m pretty happy with the progress so far. You can see the detection of the different balls in two of the lighting conditions above – I’m not to happy yet with yellow in low light, but I’m not overly concerned with this at this stage. I’ll either tune it to deal better with it, or add some headlights to Glitterator 2 which should eliminate the low light conditions. (Neopixels are bright!)

These images are stills that I took using my phone camera, but of course in the long run we want to use the pi cam. I’ve connected up the camera and confirmed that I can stream images from it, but I haven’t yet hooked it up with the program used above. That’s the next step.

Some people have reported problems installing OpenCV, but it was painless for me:

sudo apt-get -y install libcv-dev libopencv-dev python-opencv

I have a fairly good home internet connection though, so maybe it might be more difficult with a slower link.

Once that was done, I used the tutorial on this page for object tracking, but changed this line:

ret, img=cam.read()

to

img=cv2.imread(args["image"])

With a bit of code higher up to handle passing the image file as a command line argument. (Ultimately I’ll shift back to using the camera.) Then it was just a matter of adding masks for the different coloured balls. Green was given in the existing code, so I had to determine suitable values for red, blue and yellow. Red is a bit tricky because its values wrap (hue values of 0-10 and 170-180), so you have to create two masks for it and use both. And as I said, I don’t think I’ve got quite the right values for yellow yet. Still, not a bad day’s work!

And while I’ve been focusing on this, Angus has been working hard at developing his LEGO firing mechanism. It’s evolved tremendously since I last talked about it on the blog, and currently looks like a LEGO crossbow. No guarantees that it will stay that way, but if it does, I’m sure I’ll discuss it in a future blog post.

Advertisements

Setting up a WiFi access point

I’d mentioned in a previous blog post that one of the problems we had last year was wireless access. At the venue, we struggled in some areas to get coverage, and worse, when we left the venue, and wanted to demo “in the wild” there wasn’t always a wireless network that we could easily connect to. This meant that when things went wrong (as they inevitably did!), logging in to the robot to fix them was a painful process (because we tended not to carry a monitor and keyboard around with us). Well, now that we have our pi-in-a-briefcase, we have the monitor and keyboard anyway, so I guess we could just use them, but there are advantages to connecting wirelessly to a robot (testing is a lot easier if you’re untethered). So on top of the pi-in-a-briefcase, we’ve made the pi itself a WiFi access point, that Glitterator 2 will automatically connect to if detected.

I actually thought about doing this in the last few weeks before the competition last year, but things were a bit stressful at that stage (read: nothing was working as it should!), and I couldn’t get it to work quickly and easily. I’m fairly certain though that this page on the raspberrypi.org website wasn’t there at that stage though, which would have made things a whole lot easier! It sets out, step-by-step, exactly what you need to do to set up a WAP on a pi. Unfortunately, according to Peter who followed it, the problem is that if you make a mistake, there’s nothing to give you feedback on what was wrong. (In his case he accidentally replaced a ‘-‘ with a ‘_’, or vice versa.) If things go wrong, he suggests that you head over to the adafruit tutorial on the same topic, which goes into more detail on how to test each step as you you complete it.

I will add… I’m not sure that everyone at PiWars having their own personal WAP is a good idea. It might cause contention issues that actually makes things worse for everyone. But even if we don’t use it there, it will be useful for use when we go out to do demos, like we did at the kids’ school last year.

Our pi-in-a-briefcase

I mentioned in my last blog post that we were putting together a mobile setup for our robot (or any pi-based demos really).

To do this, we’ve stolen the screen from a long-dead 2004-model PowerBook. (I knew there was a good reason to hold on to it!) I’d already pulled the PowerBook apart once many years ago, when the hard drive failed just after the warranty expired. So I knew straight away that there was a good guide for how to get at the innards (here). That left the screen intact, but it was just a matter of finding a similar guide for replacing the LCD (here) and it was easy to extract. Next step was to work out which controller board I needed to add an HDMI connection to it. On the back of the LCD the model number was printed (LP121X04-C2), so it was a fairly straightforward matter to search for an appropriate controller board. Unfortunately – probably because this is such an old model – no appropriate boards were available locally, but I found a couple from China on eBay. Resigning myself to a long wait, I placed an order just before New Year. To my surprise and delight, the board arrived within a week. (The earliest estimate was Jan 16th!)

Next step was a power supply – 12V, 4A – which was easily sourced locally. And then it was a matter of wiring things up, building some casing, and putting it all together – all Peter’s doing.

It started with a fairly boring briefcase:

IMG_20180118_181039497

And some plywood framing to sit inside the lid:

img_20180118_181032048.jpg

The plywood is covered with black cloth (you can see the wrong side of it here; the right side in the image at the top), the controller board and pi are mounted with spacers on the plywood, and the monitor is mounted over the controller board. It still needs a screen protector for during transit, but there is plenty of space still in the briefcase for other stuff, including the keyboard, a good range of tools, and a fair bit more besides. (It won’t fit the robot itself – the briefcase isn’t deep enough – but that’s fine; Glitterator 2 has its own box – a ReallyUsefulBox – anyway.) And the pi, as it boots up, starts up as a WiFi hub, which Glitterator 2 will connect to if detected. More on the setting up of the WiFi hub in another post.

Oh, and as a slightly late addition to this blog post… we realised that the screen driver board has a USB connection, so we’re able to plug the pi in to that and do away with the separate power supply for the pi. Ultimately we’ll be looking to put in a powerbank for portability too.

In sickness and in health… or maybe not!

OK, maybe we aren’t quite as wedded to this project as we should be, because for the last few weeks the entire family has been plagued with various ailments and we’ve made little progress on our robot (or update on this blog). Flu, impetigo, tonsillitis, ear infections, perforated eardrum – every one of us has suffered at least one of these ailments! But still along the way we’ve made some minor progress, so here’s an update on where we are.

First of all, one of my challenges was to get UART serial communication working between our “brain” (pi 3, used for the autonomous challenges) and the motor controller (pi zero w, used for remote control). The plan is to detach the “brain” for challenges that only involve remote control. But first, I needed to make sure that I could get the serial communication working between the two. So, I used raspi-config to enable serial and disable the login shell via serial, then I set up a pair of simple python scripts that should allow one pi to send messages and the other receive them. I connected together the two pis (common ground, GPIOs 14 and 15 interchanged – i.e. 14 on one pi connected to 15 on the other and vice versa) and gave it a whirl. No joy. A little more digging reveals the pi 3 “steals” the default serial port for bluetooth – as does the pi zero w.  Good news is, you can revert back (so long as you don’t want to use BT) by editing /boot/config.txt and adding the line:

dtoverlay=pi3-miniuart-bt

That gives you back the hardware-based serial port /tty/AMA0, which is more reliable than the software-based one that you would otherwise have. (Use the same line for both pi 3 and pi zero w, despite the use of “pi3” in the text.)

Sadly, things still didn’t work. So then I looked at dmesg on both the pi3 and the zerow to see if I could see anything unsual. Nothing appeared to be odd on the pi3, but got some messages related to the serial port on the zerow. I wasn’t sure what those messages meant but I decided to try it out with a spare pi3 I had rather than the zerow, to see if that helped. Nope. For some reason at this point I decided to try the spare pi3 with the zerow – I can’t even remember what prompted me to try this. And you know what? It worked!

So then the question was, what was wrong with my “brain” pi 3? Well to be honest, I’m really not sure :-(. It was running a recent clean installation of stretch, fully updated. It wasn’t a hardware problem, because it worked fine when I took the microSD card from the other pi3 (for which I’d created the installation at the same time as the microSD card that I swapped out!). So I can only assume that somewhere along the line, I typed in the wrong command or made a typo or something. In any case, I gave up trying to identify the problem, wiped the microSD card and did a fresh install. Then went through the process of enabling serial, disabling serial login and restoring the hardware-driven UART all over again. And it worked. Several days of pain most likely because of a silly mistake!  But anyway, now it is confirmed that it works – hooray! Time to move on.

IMG_20171227_114106839_HDR

IMG_20171225_161244

In the mean time, Christmas happened, and Angus was delighted to receive a Boldport Club subscription, so is busy enhancing his soldering tools. (He also received a set of new soldering tips.)

Erin meanwhile was delighted with her #girlswithdrills sweatshirt.

And while we didn’t make much further progress on the robot itself, we had a few related projects in progress. Last year at the competition, we struggled with WiFi a bit at the venue (struggling to get a connection). Also, a couple of times we wanted to demo the robot to people in places where there was no WiFi access available – so if something went wrong, we couldn’t easily log in to fix things. So this year, we’ve set up a separate pi 3 to act as a wireless hub. The robot connects to this, and we can easily log into it, wherever we like (at least so long as we have charged batteries!). In addition, we’re in the process of building a mobile setup – with monitor and keyboard/mouse – in a briefcase, stealing the monitor from a long-dead (14-year-old) MacBook (and purchasing a driver board from China, which arrived surprisingly quickly). Both of these side projects are largely driven by Peter, and I’ll give more detail about them in a subsequent blog post.

Angus has also been thinking the Duck Shoot challenge. Way back when I first heard about this, I bought a Nerf gun – actually the same type as in this Magpi article, though before the article was published – thinking we would use that. Angus however has decided that it is not fit for purpose, as it sometimes jams. (This may have something to do with the extent to which children have been playing with it…) Anyway, he’s now working on a purely LEGO-based firing system, as demoed in the video below. He’ll have to reload after every shot, but he feels confident that that will work. And as I’ve given him full control of all the remote control challenges, that’s his decision to make. I admire his dedication to producing a “pure” LEGO-based robot.

We’re over the LiPo scare!

Well, as you will know if you’ve been following the blog, a few weeks back Angus shorted the wire on Glitterator 2, leading to a minor LiPo fire. This freaked him out a bit, and he spent considerable time trying to convince us to convert to a different battery type. He did a lot of excellent research (and found out about all sorts of obscure batteries along the way), but failed to convince us. Instead, we’ve convinced him to be considerably more rigorous with his safety checks, and we’re sticking with the LiPos.

Once we reached agreement on that, a decision was made to hack a LEGO battery box. These boxes are designed to hold 6 AA batteries, and will happily drive the motors. Adding a voltage regulator to them and attempting to drive a pi as well though is iffy, as you typically get a 1V drop over the voltage regulator, so you don’t have to have the batteries get very flat before you can’t get the 5V that the pi needs. Last year, we simply had the LiPos tucked into a cavity below the pi, but they had an annoying tendency to fall out at the most inopportune times (like in the middle of Pi Noon). So we’ve ripped the guts out of a LEGO battery box, integrated a low voltage alarm into it, and have four 1S LiPos housed within – one powering the pi zero via a LiPo shim, and three in series to power the motors. There’s room in there for another LiPo to power the “brains” pi 3 as well, should we want to do it that way.

With that in place, it was time for more test driving. We had snow last weekend, which was the perfect excuse for some extreme weather testing:

Angus is getting quite adept at manoeuvring the beast; I only hope that I can get the autonomous driving to work half as well! He also continues his chassis refinement, with the addition of a “bonnet” for the pi zero:IMG_20171214_194242192_HDR.jpg

We had hoped to attend the Christmas Manchester Raspberry Jam, but sadly illness struck, leaving the kids feverish and voiceless, so we had a quiet time at home instead. We did indulge in a bit of Christmas Raspberry Pi cheer though:

IMG_20171208_135932163_HDR.jpg

Merry Christmas from all at Team Glitterator.

A busy time of year.

Well, I thought I’d throw in an update, not because we’ve achieved a lot; more to stay that we’re all still alive! Best I can say at this point is that progress is slow but steady; no spectacular results, but trickling along. We’ll probably continue making slow progress right up until Christmas, as Angus and I both play in a brass band… and we have a lot of gigs at this time of year!

Two steps forward, one step back; it’s all about learning!

So… didn’t manage to get a post up last week, because it was a mad week, but have a moment’s breathing space right now to reflect upon what has happened in that time.IMG_20171106_063056784

First up, the chassis design continues evolving… actually even this photo is a little out-of-date, but the main idea being that we now have rhomboid tracks.  The footprint is marginally larger (still well within the A4 paper), but it gets over things more easily, and I think it might actually go faster too. Not that it needs to go faster. In fact it goes so fast at the moment that control is the issue!

In my last blog post, I was talking about options to communicate between the pi zero driving the motors (and handling remote control) and the pi 3 with the sensors and handling autonomous control. I realised afterwards that the option we used for the lights pi zero last year – USB – isn’t available, because the remote control wifi dongle uses the pi zero’s USB port.  But in any case, I hadn’t really want to use that option anyway.  So I was considering I2C and SPI… but it was pointed out to me, when I was chatting to people about it at Manchester Raspberry Jam, that UART was probably the easiest option. And I have to agree – why I didn’t consider this myself, I don’t know! So that’s one problem solved… or at least a decision made – I still need to test it.

Also on the agenda has been testing my sensors. And that’s sort of been successful. Since the last competition, I’ve been keeping my eye out for any sensor that might be useful, ordering them, and tucking them away till I had time to test them out. The problem is, now that I have time (sort of) to test them out, I’m not quite sure where I’ve tucked them all away! 🙃😊 But so far, it’s clear that we’ll be using VL53L0X sensors again this year – they worked a charm last year, and there’s no reason not to use them again. Obviously we’ll need to use a camera for the Over the Rainbow challenge, and no need for the myriad of line following sensors left over from last year. (While we could do line following on the straight line speed test, I would prefer to use the distance sensors. Yes the chicanes make it a bit more tricky this year, but I plan to handle that by having distance sensors on both sides of the robot and keeping equidistant from the walls.) I’m still playing with the idea of using a gyroscope/magnometer for the maze as well…

It’s all about learning though!

OK, so that’s all positive, but I think it’s obvious from the title that it hasn’t all been that way. That’s a good thing, not a bad thing though, because every setback is a wonderful learning experience for my kids.

Angus (10 years old) was already heavily involved last year, building the chassis and contributing to the coding. This year, he’s again in charge of chassis design, and it’s obvious he’s putting much more thought into the engineering of it. At the moment we haven’t done much software development, but he’s been writing software for other things, and reading Computational Fairy Tales and Best Practices of Spell Design by Jeremy Kubica. These books are wonderful ways to introduce young adults (he reads well above his age) to computational thinking, without writing any code. So I’m expecting him to make significant contributions to the code this year.

Erin (7 years old) was less involved last year – an interested observer more than anything. But over the summer, she told me “Mum, I want to learn to code!” – and I’m sure that’s come about because of pi wars. So we’ve started looking at coding using the Kano operating system for Raspberry Pi – it has a bunch of great tutorials for children included. She was working on its turtle-graphics-like drawing package when she came to Manchester Raspberry Jam with me, and very happy to create Stick Man, amongst other things, while she was at it. It’s still not clear exactly what her contribution will be to Glitterator 2, but her peripheral involvement so far has opened her up to new challenges, and that alone is fantastic as far as I’m concerned.

So… I still haven’t got to our setback. Well, some background first. We parked ourselves next to Nick Young at Manchester Raspberry Jam on Saturday – just Erin and I, as Angus was competing in a cross country competition. Nick had a multi-segmented robot called “Pithon” in last year’s pi wars competition. He was disappointed that he didn’t spend enough time on it, so it didn’t perform very well, but he’s continuing to work on it – and I must say it is now much more impressive!  But shortly after we arrived, it started smoking. Somehow one of the battery packs had shorted. No major drama, but a nasty smell.

Well, on Sunday morning, I was doing something upstairs, and Angus was test driving Glitterator 2 downstairs.  I hadn’t registered that it had stopped driving around, but then heard Erin yelling, “Mum, I feel sick! Angus is making smoke like at the Pi Jam yesterday.” Ooops. And unlike Nick, who was just using AA battery packs, we have LiPos. Fortunately I’d been through the risks of battery explosions with both kids, and Angus had immediately moved the whole robot outside. I cautiously peeked out the door, and it had stopped smoking. Definitely still hot though. Retrieved the LiPos and put them in the battery bag, leaving that outside, then brought the robot in for post-mortem. Seems that the screws on the power terminals had come a bit loose – possibly due to rough driving – exposing some wire, and these wires had crossed. Luckily, there seems to be minimal damage to the electronics. But you know what? The house really stinks! And the terminals melted…

And a bit of fun…

Only a little bit Pi Wars related, but also this week I had a day off work in order to visit the place that will be my new workplace in January – the Department of Computer Science at the University of Sheffield. We talked about my role there, what I would be teaching, and various other things. One of those things is that I’m keen to establish a Raspberry Jam in Sheffield – and it looks like it will go ahead. I’m not sure how long it will take to get it off the ground, but for anyone who is interested, please get in touch.

While I was in Sheffield, I also took the opportunity to visit Pimoroni.

I should point out that they are not set up to receive visitors – I organised this well in advance.

I talked Pi Wars with Tanya, who’s recently been given a place, along with her son, in the beginners competition, after being on the reserve list, and also got a tour of the factory (spending a good 5 minutes or more being mesmerised by the pick and place machine) and chatting with Sandy and Phil as well. I came away with a wonderful swag of goodies, but could have spent a fortune more… so much STUFF!

Cutest of all was the new product “Bearable” (yes, I know it’s a fox, but there’s a bear version of it too), which Erin took great delight in showing off to everyone at the Raspberry Jam. The crocodile clips connect to a sensor that make the LEDs flash. There are two types of sensor – light or motion – and she spent a lot of time jumping around to show off the motion sensor.