PiWars 2020: Collision warning!

A major cause of the disasters that International Rescue get called out to are caused by collisions. Whether its a fuel tanker hitting a rock slide, or an experimental jet crashing into the ground, it usually results in a large explosion (regardless of how explosive the objects involved actually are). So when running autonomously how do we avoid Thunderbird 2 running into things? (Obviously in a manually controlled environment nothing is going to stop us crashing !).

Boom!

The answer is to add sensors that are capable of detecting how close it is to an object. Generally these are referred to as 'distance sensors', which come in a variety of form factors and types, and tend to work by 'firing' something outwards, waiting for it to bounce off a surface, return to the sensor and then measuring the travel time to determine how far away it is. This process is similar to working out how far away an object is by making a loud sound and listening for the echo.

Popular choices are ultrasonic sensors, which uses sound waves to determine distance, Time-of-Flight sensors, which use lasers, and some camera based systems (which use magic... or possibly maths).

Sensors!

My requirements for Thunderbird 2 are that the distance sensors are small enough to be hidden behind the 'air intakes' for the jet engines, and that multiple sensors can be used at the same time. This rules out the ultra sonic sensors, as the sound waves they fire out could get picked up by multiple sensors, giving an invalid reading, as well as the camera based systems. Instead I'll be using several VL53L1X Time-of-Flight sensors.

There are a number of different models of the VL53L1X sensors, all built around the same core module, and which one you select depends on your requirements. In this case I wanted a module that had a small physical size, and exposed all the control pins.

The VL53L1X  sensor communicate via I2C. This is a protocol that allows multiple devices to be connected to the same physical bus (i.e. The communication pins are all connected together), which greatly simplifies the wiring as it allows you to chain multiple I2C devices together instead of needing each one to be directly connected to the Raspberry Pi.

All connected to the same I2C bus.

To talk to an I2C device you need to know its address, similar to how you specify a house on a street by its number. According to the VL53L1X  datasheet its default address is 0x52 (82 in decimal), which we use to make sure our post (the commands) reach the correct house.

Unfortunately if all the sensors share the same I2C address then the postman is going to get very confused about where these messages should be delivered to. Luckily this particular sensor allows its I2C address to be changed, by sending a command. This could be considered a bit of a chicken or the egg issue, how do you tell a sensor to changes its address when you can't send a message until the addresses have been changed?

Luckily the designers of the VL53L1X  sensor did consider this and provide an extra PIN, called XSHUT, that can be connected to a GPIO which turns on or off the sensor. Allowing us to turn on one at a time, reconfigure it,s address and move to the next. Now not all ToF sensor models expose this PIN, so this is another item we need to check for,

After a bit of searching around, and measuring of space, I found one produced by Pololu that looked like it would meet all the criteria. Purchasing one to double check the fit, always a sensible idea before you commit, before getting all 4.

It fits!

I initially connected the sensors via jumpers leads, but quickly decided this was too bulky and inflexible to fit inside the case, especially as I had four to connect up! Taking advantage of the ability to chain I2C devices I switched to ribbon cable, a thinner and more flexible cable, along with some 1x7 connectors. This worked at first, but when I came to chain two I managed to get the cable a little twisted, mis-wired the connector, and managed to produce a 'burning' smell from a sensor... Ooops!
To avoid this in future I purchased some multi coloured ribbon cable, making it much easier to work out where each cable goes (Even later on I found the roll of rainbow colour ribbon cable I'd bought a year or two earlier...

Two sensors in a nice, neat, rainbow coloured line.

Repeating the setup on the other side I know have a full set of four sensors, two pointing forwards and one pointing to either side. This allows Thunderbird 2 to detect walls in front, and either side, in theory allowing it to safely navigate through the maze and the lava palava course.

Now all it needs is someway of actually moving! Which I plan on covering next time!

Leo

Pi Wars 2017 - Scaling things up

Whilst the robot I posted about in my last blog entry is reasonably compact and contains most of the components I'll be needing for the PiWars 2017 challenges, in practice it feels a little bit sluggish and under powered, and not something I'd be confident entering into the Pi Noon challenge. So I decided what was need was a slightly bigger robot.

Now as the robot is 3D printed I can just scale it up to the size I want yes?  Well, unless you have a fully working replicator, its not quite that easy. The plastic parts scale up nicely the motors and other electronics don't. The weight increases, so you need bigger motors, then bigger, however the batteries, and possibly a higher rated motor controller. Then you need to make all these bigger components fit on the robot and suddenly it feels like you have less space than you did before!

I stripped all the parts from my PiWars 2015 entry and went through several revisions of the scaled up chassis, trying to work out how to make everything fix together.  Eventually I did a spot of rewiring on the controller, cut off some pins and finally came up with the following.

Old vs New

The new Pi Squared chassis is considerably larger than the previous variant, as well as gaining a rear wing, just fitting inside the maximum dimensions allowed for PiWars. The front wing is now removable, allowing the chassis a bit more space on my 3D printer, and can be swapped out for the various different challenges, although the only one I have prepped so far is for Pi Noon.

Removable front wings

The downside to the increased size is it takes a lot longer to print. The chassis takes just over 20 hours to print, the rear wing 5 and the front wing another 2...So my printer has been running almost constantly for the past week!

The control method is my usual PS3 controller, with a simple python script driving the motors, making use of pygame and the GPIOZero library to keep everything simple. In fact the entire code is rather small.

import pygame
import os
import time
import gpiozero

os.environ["SDL_VIDEODRIVER"] = "dummy"

pygame.init()   

pygame.display.set_mode((1,1))

# Wait for a joystick
while pygame.joystick.get_count() == 0:
  print 'waiting for joystick count = %i' % pygame.joystick.get_count()
  time.sleep(1)
  pygame.joystick.quit()
  pygame.joystick.init()


j = pygame.joystick.Joystick(0)
j.init()

print 'Initialized Joystick : %s' % j.get_name()

from gpiozero import OutputDevice
from gpiozero import Robot
EN1 = OutputDevice(17)
EN2 = OutputDevice(6)
EN1.on()
EN2.on()
r = Robot(left=(27,5), right=(13,4))


try:
    # Only allow axis and button events
    pygame.event.set_allowed([pygame.JOYAXISMOTION, pygame.JOYBUTTONDOWN])
    left = 0.0
    right = 0.0

    while True:
        time.sleep(0.1)
        events = pygame.event.get()
        for event in events:
          UpdateMotors = 0

          if event.type == pygame.JOYAXISMOTION:
            left = j.get_axis(1)
            right = j.get_axis(3)

            r.value = (left, right)

except KeyboardInterrupt:
    # Turn off the motors
    j.quit()

Finally here's a quick view of the new and improved Pi Squared running around.

With only a week left until PiWars I still have a lot to do, sensors to attach, code to write, practising driving.. So its going to be a busy weekend and evenings for the rest of the month!

Leo

Pi Wars 2017- How to build robot?

Having considered the various challenges that will be present at Pi Wars 2017 next step is to give some thought on what type of robot I'll be needing to tackle them. Now the sensible approach would be to use my Pi Wars 2015 entry as a starting point, after all its a fairly solid base, improve on the returning challenges (e.g. the line following) and add additional functionality to handle the new challenges.

Of course that isn't the approach I'll be taking, although it will be the backup plan, instead I'm looking at starting afresh and putting together a new robot for Pi Wars 2017. To a degree this is because I have new ideas and new components I want to try out, as well as the fact that my Pi Wars 2015 entry didn't turn out to be all that interesting.

There are various components you need to put together a robot and, fortunately, in the run up to PiWars 2017 the MagPi Magazine has run a few articles, starting in Issue 51, on how to build a remote controlled robot suitable for Pi Wars.

Lots of wheels and motors.

So what do we need? Well I will be going for a wheeled robot once more, either a two or four wheeled variety, and I'll be aiming to reuse some of the motors and wheels from previous robots. At last PiWars I took a selection of wheels but ended up not swapping them out for specific events as the motor connections were a little fragile, so that's an area I want to improve this year.

As far as the motors go I want to investigate using stepper motors to try and get a bit more precision in some of the autonomous challenges. I have a set of four from a 3D printer, as well as a couple of larger ones salvaged from an old Laser printer.

Motor drivers

Next up is the motor controller. Here I have a choice of reusing the motor driver from last year as well as using some of the other's I've purchased over the years. The final choice is liable to be determined by the motors/wheels I end up using, and indeed I may need more than one motor driver, especially if I want something to propel the skittle or golf ball at a high speed.

Batteries!

A robot won't move without power, and once more I'll be going with Lithium Polymer ones for their high power in a small package. I've not yet had one explode on me... however there have been a few sparks, so you need to be careful handling these.

Pis!

Next is the brains of the robot, last time I used a Raspberry Pi A+ for its mix of smaller size, reduced power consumption and camera connector. This year I'm currently using a RPi 3B for its additional power (In case I do image processing) and its built in WiFi and bluetooth. Although I'm also planning on using some PiZero for supporting roles.

Toys!

Boxes and containers

Next up on the list is the chassis, something to fit all the above components into, along with the connecting wires as well as any extra sensors or components required. My first Raspberry Pi robots were based around the BigTrak toy and other people have has success with other large plastic toys (preferably ones that already have motors in them!).

Cheaper alternatives are empty food or packaging boxes (e.g. ice cream tubs, the CamJam EduKit box) as well as various project boxes available at Maplins or similar places. I used a project box for PiWars 2015, but ended up finding it to be a little restrictive in getting all the components connected to it, and overall ended up with a fairly plain looking robot (especially when compared to my Pirate ship from the first PiWars!).

Luckily I have a much more flexible option this year, a 3D printer! Allowing me to, in theory, print out the exact shaped chassis I want.  Of course that is entirely dependant on me being able to design it in the first place....


I've only created fairly basic objects to print before, so I thought I'd have a little practice by creating a chassis for a simple ZeroBorg based robot using 4 of the little micro metal gear motors to drive around. This took a few iterations but I generated a simple chassis that looked like it was going to work... apart from one small detail I missed.

Yes... I forgot to allow space for batteries to drive the motors.... I ended up balancing a 9V battery pack on top of the PiZero, but that wasn't exactly ideal...

So it was back to the drawing board to come up with something a little better looking for PiWars and, after quite a few more iterations I've come up with the following (Which takes over 4 hours to print if I want it good quality!).

Still needs more work but its a Raspberry Pi 3, with camera, along with 2 motors, a LiPo battery and an AdaFruit PowerBoost 1000C to allow the LiPo battery to be charged without having to remove it, or interrupt power to the Pi3. There are liable to be many more iterations (It needs sensors/attachments for some challenges, maybe bigger motors/batteries too), but I'm hoping to keep to this general shape for the final event (only a month away now!).

So that is how I'm planning on building my robot! More or less.. Obviously I have a lot more work to do, but already its looking nicer than my last attempt!.

Leo

PiWars 2017 - Autonomous challenges

Its the autonomous challenges at Pi Wars that separate the robots from the radio controlled cars, requiring one or more sensors on the robot to collect information about the real world, process it and make decisions on how to react in order to successfully complete the task at hand.

To add to the complexity you are competing against a whole raft of other robots, so you have to balance between going slow and steady or quick and fast. Do you concentrate on completing the course without any penalties, or risk pushing things to get a good time?

Of course the first step is working out how to approach each of the challenges and get a working, reliable system up and running, before trying to push things to the limits!

Line following

A returning event for Pi Wars 2017, the robot needs to follow a black line on the ground, following it around a twisty course as many times as possible within the time limit provided.

My attempts at line following in the last Pi Wars didn't go so well... In testing the night before the Arduino controlling the line sensor started triggering the watchdog and restarting, clearing the calibration data and causing the robot to lose the line, so on the day I only got about a quarter of the way around the course. So this time around I want to take an approach that uses just Raspberry Pis, partly to try and avoid this issue in future, and partly due to the fact it is a Raspberry Pi based event! 

The first approach would to re-use the line sensor from last time, connecting it directly to a Raspberry Pi instead of an Arduino (something I've successfully done before using the pigpio library). Due to Raspbian not being a realtime OS it can take a lot of CPU time to ensure no data is lost, so for this approach I may have to use a dedicated Raspberry Pi to do the sampling, and send the data to the 'master' Raspberry Pi for processing.

An alternate approach is to use the Raspberry Pi camera to do a spot of image processing to determine where the line is, and where it is going. I've not done image processing since University, so this would require lots of investigation, research and learning. As I like using these events to learn new things, I'll definitely be giving this approach some serous consideration.

Straight line speed test

Another returning event, the robot has to drive in a straight line as fast as possible along a 7.28m long trough. For Pi Wars 2017, however, the straight line speed test has been revised to be autonomous only, whereas previously I've only attempted this when under manual control (Attempts to use the compass on the Sense HAT having proven unreliable!).

A few approaches spring to mind for this event... Utilising feedback from motor encoders to try and ensure the robot is maintaining a straight line, using a sensor to ensure the robot stays a set distance away from one wall (probably reusing the range sensor from last Pi Wars) or utilising the Raspberry Pi camera to try and detect where the walls of the trough are and ensuring the robot stays in the middle.

Using the range sensor sounds the most feasible, but it would be nice to get something working with the camera.

Minimal maze

Another new event for Pi Wars 2017, the robot has to navigate its way through a maze, without touching the walls, to reach the exit. The walls will be of various colours, providing information the robot could potentially use to determine where in the maze it is.

Initial thoughts on this challenge are that I could use a variation of the speed test solution, using a range sensor to keep the robot following the left or right wall, combined with a second sensor on the front to work out when a corner is coming up. Alternatively I could use a single range sensor and start out following the 'right' wall, then when the right wall turns blue (A camera being used to determine this) switch over to following the left wall. Hopefully avoiding hitting the outer wall as the direction changes!

The maze needs to be completed twice, with the times combined for the final result, so can we be a little sneaky and use the first run through to 'map' out the maze? Then use this map on the second run to zoom through it? You'd need to get the starting point spot on for the second run, but it certainly sounds feasible!

So those are my thoughts on the autonomous challenges... Do they sound good, bad, very bad? Is there enough time left to implement all of these?

Leo

PiWars 2017 - Manual challenges.

Its been a busy few months since I was accepted as a competitor for PiWars 2017, unfortunately very little of that time has been spent on PiWars itself. Work has been especially busy, culminating in a sudden business trip to Taiwan where I had access to shops with all the connectors, cables and components I'd need for a robot, but with no idea what I needed yet!

So in this post I've decided to jot down my ideas for the various manual challenges, as most of them have similar requirements, and its considerably easier to manually control a robot compared to telling it to deal with things itself.

My general approach will be similar to last PiWars, a four wheeled vehicle with tank style driving, controlled via a joystick, but with some improvements. Whilst I had the option on my previous robot to change the motors and wheels it ended up being too fiddly to do on the day and led to my robot being defeated by the 'humps' at the start of the obstacle course due to still being on small wheels. So this is an aspect I want to review and improve upon this time.

Obstacle course

As the exact details of the obstacle course won't be known until the day itself I have to make some assumptions about what will be required based on previous events. I would expect certain parts of the PiWars 2015 course to be reused (especially the rotating table) with a few new elements added. As such I'll be needing a setup with good ground clearance and fine controls. A high top speed won't help much here, with the marble obstacle from last year requiring the robot to drive slowly in order not to dislodge any and occur a time penalty.

All the above is subject to change of course, the marbles may be swapped out with a gravel pit and I'll be wanting chunkier wheels to cope with that.

Pi Noon

Having gotten to the final of Pi Noon last time (with a lucky win or two I must admit) there's probably not much to change here. I'm tempted by the mecanum wheels that Triangula was sporting last year, but I would need quite a lot of practise to be good at using them, something I've never ended up having much time for in previous events!

Skittles

Skittles was a little hit and miss last time, with my robot knocking down more skittles during the practice run than it did in the official attempts. Due to time issues I ended up just pushing the ball for PiWars 2015 which, unsurprisingly, proved to be very unreliable.

Possibly approaches to it this year could be a motorised launching system (a spinning wheel or two to get the ball up to speed), a catapult type system (pulling back and releasing an elastic band), a spring loaded system or maybe something that picks up the ball and rolls it. In theory anything that can propel the ball forwards in a straight line should work out okay for skittles, whereas the next challenge potentially requires a finer degree of control.

Slightly Deranged Golf

A new challenge for PiWars 2017 is golf, and apparently a slightly deranged variant of the game. As such its a bit of an unknown, with only the details of the challenge to base things on. The game is just a single hole (No 18 hole courses here!) and the robot is only allowed to push or hit the ball to get it around the obstacles. What those obstacles are we don't know (sand pits?) and whether its better to hit or push the ball won't be known until the day itself.

The traditional approach would favour having a mechanism that can 'hit' (or propel) the ball forwards at different speeds, allowing the robot to progress through the course, changing directions to move around obstacles and eventually reach the hole. However this does sound like quite a complicated approach, as each time you need to judge how far to hit the ball, chase it with the robot, line up the next shot etc.

A simpler approach maybe to push the ball the entire way, potentially lowering a cup over the top of it to ensure the ball doesn't get away from the robot, leaving you to just drive to the hole and drop it in. This, of course, assumes the course is flat and there is enough space between obstacles for the robot to drive through. If not the ball could escape and you'd be stuck trying to capture it again.

So that's my current thoughts on the manual challenges, next up will be the autonomous ones!

Leo