Lessons learned?

So given that my last post said “that’s it, no further development before the competition,” it seems a good time to reflect upon what we have learned this year. It was a very different experience to last year, when we were true beginners, having to work out the ins and outs of raspberry pi robotics as we went. This year, we had a decent lot of experience from last year (and other projects that we worked on over the summer), which changed things considerably.

Let’s start with the chassis.

LEGO based chassis are great… and horrible.

This one will probably get me in trouble with Angus, but I’m somewhat jealous of the teams who had the flexibility to use laser cutters and 3D printers to design their chassis, not to mention choose from a wide range of motors. Our decision to go with a LEGO-based chassis again this year constrained our options, but also meant that it was quick to implement and easy to modify. (Especially given Angus’s extensive LEGO collection.) I really don’t like the tracks though, and the motors are uneven. (To the extent that I have limited the motor on one side at the software level so that it will drive in a straight line.) Angus wasn’t aware of this, because he’s been practising remote-control driving extensively, for months, and focusing on manoeuvrability for the obstacle course and pi noon. However once I had the course set up for straight line speed test he tried to complete this using remote control and was surprised just how hard it was – and so more impressed by the autonomous code to do it.

Planning is essential.

I don’t think I ever explicitly blogged about it, but right from the start, we had a plan of what needed doing, with several milestones along the way. That’s part of the reason that I had the colour detection working months ago, but only completed the driving for the Rainbow challenge this week: colour detection had been identified as a subtask that could be completed before we had a working robot chassis, so that gave me something to do while the hardware was under development.

We lost about two weeks of serious development time because both Peter and I were seriously ill over the Christmas break, but thanks to the plans in place this wasn’t a total disaster and we were able to claw back to having something that mostly works. I did take an extra three days off work, but much less than the full two weeks we both lost.


Straight-line speed test

We might have been better off with a vision-based solution to the straight-line speed test, but I’m not sure. It works using the ToF sensors, and while it’s not particularly fast, I think that that is a hardware limitation (primarily due to unreliable grip on the tracks and uneven drive from the motors) rather than a software one.

Minimal maze

Again, it’s not fast, but it works. And once I made the decision to add a second sensor to both sides, I think the solution should apply to any simply connected maze (i.e. one with all walls connected to each other and the maze’s boundary). So I’m happy here.

Over the rainbow

This is where I would really like those two missing weeks back 🙂  We didn’t have a full test course to try this out, so I’m not sure how it will perform on the day. On the other hand, I was extremely happy that when I put together the colour detection I’d done months ago with the basic algorithm I chose for visiting the balls (briefly described in a previous blog post, I think), it seems to work. We’ll see just how well on Sunday…

And more generally

It’s taken a while, but I think I’m slowly beginning to feel comfortable with Python. It’s strange, I’ve used many programming languages over the years, and in many cases had to become proficient in them in very short time frames, but Python just seems to try to do too much. So you can do pretty much anything with it, but you can also do pretty much anything in (at least) 10 different ways. And it’s rarely clear which the best way is. And I don’t like that!

On the hardware side, I’m a lot more comfortable working with hardware now. Many years ago, I studied electronic engineering, but I moved into software as soon as I graduated, and went on to do a PhD in computer science. Having to solder yet another header is now a minor annoyance rather than a major stress, and deciding which sensors, or drivers to connect them, or how to “hack” some hardware to do what I want is actually quite fun. And I love my crimping tools. 😁




Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s