Story: Strike a Pose

Minimal Viable Product

End of June 2023 during our first team meeting we defined the Minimal Viable Product for the Minesweeper challenge.

 MVP:

• Camera + turning
• Odometry
• Pose awareness

Info: Walls 30 cm high

Approach

In July we found a possible quite minimal approach using only our wheel encoders and Raspberry Pi Camera Module 3 Wide camera for sensors.

The wide camera has a diagonal field of view of 120 degrees and horizontal 102 degrees. So we realized that if we were able to position the robot in the right pose, we might be able to:

1. Cover four squares at once.
2. Be able to see all 12 other squares, we’re not covering.

The name Magic Pose was coined immediately.

Only 4 Magic Poses, each near a corner of the arena, would be sufficient.

Determine current pose

Key element in the approach is being aware of the current pose relative to the arena all the time.

Although our odometry based on the wheel encoders is quite accurate, it may drift away from reality with every move we make. Plus we don’t know the exact pose at our start position.

So, every time we arrive at a Magic Pose the houghlines function is used, combined with the expected position of the center of the arena based on our odometry, to figure out the current actual pose.

At the start we just assume the robot to be in the middle of the ‘bottom, left’ corner square, facing the opposite wall and drive to the closest Magic Pose, where the actual pose will be determined for the first time.

Detect lit square

Do we need to be able which square is lit?

Given the robot is over four squares, we don’t need to detect if one of those lights up, but just stay put.

Further we only have three possible destinations, the other three Magic Poses, to drive to, so after determining the current pose, for each possible destination a mask is created that covers the four tiles for that Magic Pose.

Testing

No matter how good an idea, a reliable implementation needs to be proven by a lot of testing to validate assumptions and circumstances.

Of course we had to validate the right positions for the Magic Poses.

But we also did testing with:

• Different environmental lighting.
• Proved good to have some  light on the robot as well.
• Bright light may make (parts of) the black lines look white on the camera image.
• Different colors red for the squares.
• Should also not be set too sensitive.
• Different types of lights for the squares.
• Incredible how many shades of red exist.
• Different floors for the arena.
• The real white floor showed with quite some red pixels on the camera image when no square was lit.

Result

A month ago, this was the status:

Quite some improvements were implemented since than.

Although the execution  seems reliable now, even last Saturday, two weeks before competition, strange behavior during testing resulted in finding a bug in the code. Further the challenge arena and lighting in Cambridge will be a surprise for us.

So, you’re invited to join us on Sunday April 21 at Pi Wars 2024 – Disaster Zone in Cambridge to see the result.