Design

Our primary design goal was to have as few changes as possible needed to accommodate the sawyer. We wanted to use normal game pieces with no special tracking tags on a normal board and be able to play a game of chess. Beyond this overarching goal the design was rather flexible, so long as it didn't feel too dissimilar to playing another human we would consider it a success.

Chessboard

We had a few different options for how we would design the game board. We had an idea to 3D print the game pieces and use ar tags for piece identification and tracking or to use a unique color to identify pieces. However, each of these had tradeoffs we were not satisfied with. They both sacrificed either our core design goal of not modifying the core game itself or had issues in their reliability. 

For the AR tags, we did not like how this would hinder the human player. It would make it confusing and difficult to play as the human and would be hard to follow as a spectator. For the colors we found that they were far too dependent on lighting and positioning on the board to be reliable and would have required a very custom set of chess pieces. 

In the end we settled on the travel sized set that uses disks with icons on the top to represent pieces. We liked this design for how it accommodated both the human player and the Sawyer. It allowed for somewhat simple piece detection using template matching on the icons, but did not require any truly special care that might hinder the human. All while using a standard off the shelf chess set that you could run into normally.

Movement

We were considering using a custom PID controller to improve the robot's piece pickup/place accuracy. But we decided that the Sawyer's default controller was accurate enough given the correct coordinates, after a few hardcoded piece pickup/place tests. In other words, the pickup and place would work perfectly if the piece/chess tile camera localization works. While we ended up struggling with this a bit, the robot still worked with chess tile locations calculated relative to fixed points in the 3D space. The tradeoff allowed us to use the time spent writing and tuning a PID controller to make our overall piece detection and system integration stronger.

A key design choice was also in determining how the robot would approach movement. When we were first getting a feel of the Sawyer's movement and capability of moving pieces on the board, we had many issues with the integrated IK Solver, in which it would either give a quite dangerous trajectory or crash, being unable to solve for the joints of the desired position. After further testing we realized that the robot worked perfectly if the Sawyer's joints are kept in a consistent manner that made it easy for the IK Solver to provide the ideal joint positions. This is why we rely on the "tuck" so much in the movement, if the robot tucks and resets its position after every move, it won't create any dangerous trajectories when given the next position to move to, since it's joints are poised in a natural state. This does come at a tradeoff for pickup/place speed, but we figured that with the downtime created by the human choosing their next move, this concern was negligible.