Backwards and Forwards with Minesweeper

The initial plan for Minesweeper was to build a camera system that could see the entire arena at once.  We wanted to be able to see every mine from any of the other mines.  We planned to use an upward facing camera, with a curved mirror above it, mounted high on the vehicle.

Design One

We used Fusion 360 to create a design for a mirror, paying attention to the worst-case scenario (where the robot is in one corner and the diagonally opposite mine illuminates):

We then 3D printed a mould of the mirror shape and used this to vacuum form the mirror from a sheet of mirrored high-density polythene. The vacuum form process wasn’t perfect; we ended up with ripples around the edge. But once the excess was trimmed away, the mirror was adequate.

This was all built into a game attachment (with a dedicated Raspberry Pi) to fit onto the back deck of the robot, see below:

When we tested this, the results were not quite what we were hoping for.  Although it was possible to see the entire arena, items at the edge of the image appear “washed out”: they lose much of the colour information.  As a result, we weren’t that confident that the system would detect a distant “mine”.

Design Two

We then thought about various configurations with rotating cameras.  We considered suppling power to a Raspberry Pi via a “slipring”, but in the end, opted for an oscillating camera.

In this design, the camera is rotated back and forth, scanning the arena with each pass.  The tower includes a gearbox that converts the servo’s 300° rotation into a 360° camera movement.

We built this design but again, we were disappointed with the results.  The system works, but it’s pretty clunky and of course, decisions are delayed as the camera rotates and looks in the wrong direction.

Back to Design One

We decided to revert to the curved mirror.  Although the camera can’t resolve colours in the entire arena, we realised it’s straightforward to mitigate this in software as follows:

1. If the robot body obscures part of a mine, then the software stops the robot and waits.
2. If the robot can see an illuminated mine, then it drives towards it.  For this game, the robot uses mecanum wheels, so that it can move directly towards it’s target without altering it’s orientation in the arena.
3. If the robot can’t see an illuminated mine, then it drives towards the centre of the arena (from where it can see the entire arena).  If it detects a mine while moving to the centre then it changes course to the mine.  The robot knows where the arena centre is, based on measurements from the front and left facing time-of-flight (ToF) sensors.  The software also maintains the robot’s orientation within the arena using readings from the onboard inertial measurement unit (IMU), so that the ToF readings can be used reliably.

There is one more trick in the software.  When it drives to a mine, it aims for the centre of the mine, but stops short when only half of the robot is over the mine in both the X & Y directions.  This causes it to park at the intersection of four tiles, with a wheel on each of four tiles.  I believe this is advantageous for several reasons:

1. The robot covers four mines at once.  This gives it a 3 in 15 chance of already covering the next mine to illuminate, without the need to move (assuming that the same mine isn’t used for consecutive rounds).
2. The robot doesn’t need to travel the full extent of the arena.  Instead, it can cover just nine intersections.  This reduces the average distance moved.
3. Since the robot doesn’t move to the outer edges of the arena, it increases the chance that the next mine to illuminate will be within it’s view.