A Little Tidy Up

Last weekend we got the sensors mounted and tested, but if you read that post, you will have seen the mess of leads connecting up to the I2C pins via a breadboard. And those of you who looked carefully may have noticed that in fact only four of the five sensors were actually connected. (Due to the breadboard strips being five pins wide, and me being too lazy to add jumpers to another row.) Last year we did just connect all the I2C sensors via a breadboard (with jumpers to another row), but this year I wanted something a bit more elegant, so I decided to create a loom.

Each of the ToF sensors has 6 pins, but we’re only using 5 of them. Four are common to all of them (VCC, GND, SDA and SCL), while the fifth has to connect to a different GPIO pin on the Pi for each sensor. (This is used to trigger the sensor to accept a new I2C address. If I didn’t do this, all sensors would have the same address, leading to problems!) I decided to daisy-chain the four common pins in a loom, and use separate jumpers for the control pins. There’s a couple of reasons for this: I just happen to have some fine-gauge wire in four colours, and I’ve got a bunch of existing jumpers (which have much thicker wire) in a range of different colours. In order to connect two wires to a single dupont connector, they need to be fine – I tried doing it with 20awg wire, and it was just too thick. The wire I have is 26awg and only just fits a pair in a connector.

To keep the wires neat, I threaded them through some heat shrink. At this stage I haven’t applied heat, and I’m not sure if I will, because its’s already looking pretty tidy

Ultimately I’m not sure what I’ll do about the control wires… maybe they should go through the loom, because as it is it’s still a bit of a mess. Alternatively, if I trim the wires a bit, making them a good fit rather than the standard length, maybe that will be enough to tidy it up. As it is though, it turns the above into a bit of a mess again:

Nothing like as bad as it was last week, but still lacking some elegance.

The next step of course was to test. I knew from my tests last week that the sensors were working, so I had fingers crossed that they still would with the new loom. Actually, there was a correction needed before this – did you spot it? (Try to spot a difference in wiring between the previous two pictures.)

The correction? Well, VL53L0X sensors come in a range of different packages. We’ve used them for three years now, but used different versions in each of the previous two years. Last year’s version, which we’re reusing this year, have this pin order: VCC, GND, SCL, SDA, GPIO1, XSHUT. The previous year’s sensors had seven pins, which were: VDD VIN, GND, SDA, SCL, XSHUT, GPIO1. Other variants exist… Well, for some reason, I had it in my head that the order had VCC followed by either SDA/SCL (couldn’t remember the order), then GND. So my original wiring had blue and yellow wires bracketed by red and black. It was only when I went to wire up the header for the Pi, where it was important that SDA and SCL were in the right order, that I realised my mistake. Now, colour conventions are just that… it wouldn’t really matter if I used blue for ground and black for SDA, but there’s something about my psyche that just won’t let that happen. So I re-did all of the sockets to put the black wire in the right place!

But anyway, back to testing. Well, the first thing I had to do was add a fifth sensor to my test code, because as I said, last week I only tested four at any given time. Do you want to know the lovely thing? It just worked 😁

Advertisements

Radio Silence… ended!

Sorry to anyone who’s been trying to follow our progress… you may have noticed rather a lot of silence. Essentially it’s because we’ve been waiting on the bodywork. It doesn’t look like much, but it’s the long-awaited start of the body of our chariot. Why so long-awaited? Well it turns out that it ain’t so simple to work with clear polystyrene!

At first, Peter tried building a mould for it, heating it in the oven and sucking it into place with the vaccuum cleaner while hot. After several tries it was starting to look something like what he wanted, but still not really right… He tried the hair dryer, but that didn’t produce enough heat to bend it. Then I suggested the paint-stripper hot air gun. That actually turned out to be just right, resulting in the lovely curves of the top photo.

So with the start of the bodywork finally in place, the next step was to mount sensors. We’re using the same VL53L0X sensors that we used last year. Some people reported having troubles getting readings from them when in direct sunlight, but that wasn’t an issue for us. Fingers crossed that it will continue that way! (Though I’m a little worried that our radically different bodywork might impact upon this – some testing to be undertaken, soonish!)

Out first attempt our sensor mounting though wasn’t so great. Looked like this:

The problem? Well, a constant reading of between 5 and 6 cm, whatever was in front of (or in this case, beside) the sensor. Didn’t matter if I put my hand 2cm away, or had it a metre from a wall, it gave a reading varying between 5 and 6cm. I suspected that the aperature of the opening was too small, causing some interference in the readings (these are time-of-flight sensors). So we tried again, with a larger hole:

Success! Now we get meaningful readings from all five sensors. (Two on each side, one at the front.) A bit of a mess of spaghetti wire, but that will be thoroughly cleaned up shortly.

We’ve also mounted our “brain” in the body – a Pi 3A+. We used a 3B+ last year, but quite frankly, that was overkill. So this year we’ll have the same pi zero to drive the motors (with two PZM Pi Zero Motor Shims – one for the track motors and one for the gun). Next step is establishing communication between the “brain” and the “brawn”. Last year, we used serial communication via the GPIO pins for this. For the most part that was fine, but every so often during testing it would just fail, and for the life of me I couldn’t figure out why. (Luckily it worked fine on the day.)

So this year, I though I’d try a different tactic: communication via bluetooth. So I followed the instructions here and got two pis to talk to each other easily enough. I’ve just spent the rest of the day trying to decide exactly what they should say to each other… still working on that one!

Slow progress

Things have been moving more slowly than we would like, and last weekend we had a team meeting about it. I was very proud of Angus, who took charge and laid out the problem: our plan was to have the hardware finished by Christmas, and at this stage we still had no sign of the body being ready.

This led to a long discussion, and while we haven’t quite resolved things, it does look like it might still be a feasible plan. We talked about what sensors we’d like mounted and approximately where, while Peter discussed his plans for the bodywork. I can’t say much about the bodywork because that’s all a bit hush-hush. I kind of wish there was some 3D printing involved, but he’s going for some more traditional methods involving heat and moulds. Still, fingers crossed we will soon have a way to mount out sensors.

Meanwhile, Angus has continued refining the gun, and took the initiative to wire it up to the controller. Hey it works!

Maybe it could be a bit faster, but it fires five shots reliably.

Some progress

Progress at this stage is focusing on the physical design of Glitterator, including the gun. The image above shows the current chassis (lacking the “brains”). This isn’t too different at first glance from the prototype we had going when we submitted our entry, but has some subtle changes, making it more robust.

The main focus though has been the gun. Last year we had a mechanism that fired small pieces of LEGO at the targets. There were two problems with that: 1) It broke the “soft projectile” rule and 2) It wasn’t quite powerful enough – some hits to the targets didn’t actually knock them over. So this year, we’re looking at a radical redesign.

First up, we’ve switch our ammo to foam balls. Now this is a bit of a problem… the foam balls are a bit lighter than the small pieces of LEGO, so we actually need to fire them harder! And also, they are a completely different shape. So the firing mechanism is quite different to what we had before. But still made of LEGO!

IMG_20181015_100507998

This is what it currently looks like, but it’s gone through several iterations to get to this stage, and is likely to go through several more, because at this stage, the reload mechanism isn’t quite reliable. Below you can see an earlier iteration of the gun in action (the one above is significantly more compact), and a birds’-eye view of the loading/firing mechanism in action.

Obviously the firing mechanism is just running directly off a battery pack, but we know how to move from this to a motor driver after last year’s experience.

Still very much in conceptual design stage is the “cabin” that will house Glitterator’s brains and sensors. Various options are under consideration, but no one is the clear solution at the moment. I’m going to stay a bit vague on this topic until we have more idea where we’re going with it 😆. We need to get there soon though, because I want to get Angus started on the autonomous challenges.

IMG_20181013_114045107Part of our work this week was completed at Manchester Raspberry Jam. We haven’t managed to get there as frequently as I would have liked in the past several months, largely because Northern Rail keep striking on Saturdays. This month we made the effort though and actually drove to the Jam. It was good to catch up with people there, many of whom have given advice on our previous entries to Pi Wars (and some of whom have also competed themselves).

We’re in!

We just got the magic mail, starting with the words

Hello,

We are delighted to tell you that your application to enter Pi Wars 2019 has been accepted and we would like to offer you a place in the Intermediate category on Sunday, 31st March.

Needless to say, there was much excitement in the house… Angus was so sure that I was going to give him the opposite message that he had already pulled apart his first attempt at Glitterator, mark III, but he’s already put it back together again, minutes after hearing of the acceptance. So now it’s down to some serious planning.

So… what are we thinking about this year?

Power

Unlike Angus, I maintained hope of acceptance for this year, and spent yesterday desoldering the LiPo shim from the Pi 3B+ that was Glitterator II’s “brains”. It worked fine, but I’d like a more elegant battery. So I think this time that we will try a Pi Juice HAT. They’d just had their first KickStarter production run at the time of the last competition, and they looked rather nice. We’ll stick with the LiPo shim for the pi zero though, as we were using smaller batteries for that that fit nicely into out modified LEGO battery pack:

Structure

We’re still using a LEGO-based design, but this year we’re planning a “cabin” to sit on top of that. This will provide a space for the Pi 3 (and I suppose we could have built something into it for the LiPo too… but hey, I want to try something new!). More importantly, this will provide mounting points for the sensors and “glitter”. Peter’s taking control of that aspect… I’d really like to 3D print something, but he’d like to try shaping something out of mouldable plastic. We’ll see how it evolves 🙂 We’re aiming for a space buggy or planetary rover type look.

Space Invaders

Angus built a wonderful LEGO projectile launcher last year, but unfortunately it didn’t perform all that well on the day. I’m hoping he’ll still manage something LEGO-based this time, but using different projectiles.

Control

We had issues last year with the Rock Candy controller at the event. Too many of them were around, and they kept pairing with our robot. Or when that didn’t happen, our controller paired with another robot instead of ours! But the previous year, we had had a different set of problems with the genuine PS3 controller (using bluetooth), because it kept dropping out at crucial moments. It’s also a right pain to pair… So at this stage, I’m wanting to move away from the Rock Candy to something that will do a unique pairing, and I’m not aware of any wireless-based controllers that work that way. But we never pinpointed exactly what the problem was with the BT-based PS3 controller at the event, and I’m worried that it might recur whichever BT controller we use.

One thing I definitely plan to do though is to add buttons to trigger autonomous behaviour. We did that as beginners, and it worked. Then I decided to be “neater” last year and start everything using the remote control. The pairing problem mentioned above meant I couldn’t even get started on the maze, a challenge I knew we had solved! So I think we’ll add a button shim this year.

Definitely more research needed here!

Vision

We did really badly on this year’s “Over the Rainbow” challenge (now “The Hubble Telescope Nebula Challenge”). The challenge has been modified a bit, but I’m not sure that the changes will help us in any way. I’m definitely going to think all over again about how to approach this challenge.

Coding

The aim is to have all the hardware sorted at an early stage this year, so that we can focus more time on the coding. This is going to be particularly important because I hope that Angus will be doing significantly more of the coding this year. Right now, he needs to practise his Python… he’s started learning it, but has a ways to go yet. And I need to go through last year’s code and decide what should be reused and what we should start from scratch. Much of the code last year was very rushed, because our hardware built was considerably set back due to illness, and because of this it might be better to start clean with a lot of it, using more structured design.

And Other Stuff?

I’m sure there’s other stuff that needs to be added to this list. But we need to have a team meeting first and make sure that everyone’s on board with this lot (I think they are, we’ve discussed them in general terms), and also what they want to add to the list. So anyway, here’s to a few months of building and coding 😃

The Ongoing Journey

This is the family’s third attempt at Pi Wars.

Piwars-1-3In 2017, we were complete beginners, having played a little bit with Raspberry Pis – but only for desktop applications – and a lot with Lego (but not MindStorms). We learnt a lot along the way about robotics, Python, and most of all, FAILURE. But each time we failed, we picked ourselves off, dusted ourselves off, and tried again. In the end, we were very happy to come 5th in the beginners section, despite some problems on the event day. (Most notably, the controller dropping out during our first round of Pi Noon 😞) You can read about our efforts in the build up to that year’s event in this blog.

img_20180418_222724563.jpgThe kids loved the experience and immediately began planning for the next event, and so Glitterator mark 2 was born. This time, we decided we could no longer be classed as beginners, so entered into the intermediate section. And, perhaps foolishly, we started pretty well from scratch – although once again we used a Raspberry Pi and Lego based robot, we used different motor control, different motors, different remote control, and very little software from the previous effort. We had a severe setback because the entire family was extremely unwell over the Christmas break, meaning no progress during what we had expected to be two weeks of solid work, but again we pulled through. The robot wasn’t as polished as we would have liked, and certainly not as glittery as we would have liked, but it largely did its job on the day. The one big disappointment was again due to communication problems, this time meaning we couldn’t get the robot to start the maze. Particularly disappointing because we’d done well there the previous year, and had made significant improvements. Still, this time we managed to come fifth in the intermediate section, which again made us very happy. The trials and tribulations of that year’s competition build up are documented here.

Once again, the kids came out of the competition full of enthusiasm for the next one. I’m not sure I can say the same for myself though – the loss of two weeks’ work at Christmas meant that I was spending every free minute, and sacrificing sleep, in the lead-up to last years’ competition just to get the software running. Still, grand plans for the 2019 competition were underway immediately. All sorts of ideas were considered, and then the space theme was announced, which actually lead to even more ideas, and some of them very complex. Finally, after much heated debate (particularly between my husband and my son), I sat everyone down and raised the idea of building upon our previous experiences, rather than starting everything anew again. AND I made it clear that I expect my son to do more of the coding this year – I will support rather than lead the process. And it seems to be accepted. The biggest challenge right now is working out my daughter’s role – in previous years, she’s been happy to be largely an observer, but she’s old enough now to want to contribute, so we’ll need to find a place for her. Maybe she will code (with my support) one of the challenge solutions.

So there’s the first iteration of Glitterator, mark III in action (above). It’s using the same pi zero and motor controller (4tronix PZM Pi Zero motor shim) to control the motors, and just like last year, it will have a separate Pi 3 to be the “brains” for the autonomous challenges. But unlike last year, the tracks have moved back to a more flat design, as we had in the first year. (But they are hard segmented tracks, rather than the rubber ones we had then.) The ground clearance is better than the first year, but not as much as last year – the stability is much better though. The look of the body will evolve significantly. This is one area that we really want to address this year – getting it to look good as well as perform well. But the aim is to have the hardware side of things done by Christmas, so that we can focus on software development from there on (and driving practice).

And finally, the team!

img_20180623_133224-e1536486980287.jpgI’m Emma. In my day job, I teach computer science and software engineering at the University of Sheffield. Deep in dark history, my undergraduate degree is in electrical engineering, but I’ve had to learn a lot all over again while building robots for Pi Wars. I’m also a STEM ambassador, a school governor, and in my free time I play cornet (badly) in a brass band. (That’s where the pic comes from… I don’t have many pictures of myself!) Well, in the free time I have after I dabble with Raspberry Pis. Oh, and I’m also about to launch (in two weeks time) the Sheffield Raspberry Jam.

img_20180422_194021633-e1536487019205.jpg
My husband, Peter, is a researcher in natural language dialogue systems. In his spare time, he likes building stuff. Just about any stuff. In his deep dark history, he completed an apprenticeship and worked in fitting and turning, before turning to academia.

 

IMG_20180317_095300069My son Angus has just started secondary school. He got a Kano computer for his 9th birthday and hasn’t looked back. He used the Kano’s tutorials to learn Scratch, then started using it to write his own games. With our involvement in Pi Wars, he’s been learning Python, and he’s also picked up a bit of Java along the way. I’m hoping that he will do the bulk of the coding this year.

IMG_20180630_114250598My daughter Erin is in junior school. She started with a Kano computer at a much younger age than Angus (keen to copy him) and is dipping her toes into programming now. She’s really keen to be more seriously involved in the team this year, so as I said previously, I might work with her to develop a solution to one of the challenges.