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