Using ROS to Play Checkers with a Robot

Northwestern Master of Science in Robotics (MSR) student Maurice Rahme talks about what he learned teaching a Baxter robot to play checkers.

Maurice Rahme talks about what he learned teaching a Baxter robot to play checkers.

Embedded Systems in Robotics is one of three required courses in Northwestern Engineering's Master of Science in Robotics (MSR) program, and one of the primary goals of the class is to teach students the Robot Operating System (ROS).

Maurice Rahme recently took the course and developed a new appreciation for ROS and all that can be done with the system. He learned about ROS as he worked to teach a Baxter robot how to play checkers. Afterward, he took the time to reflect on the experience and the importance of trying something new.

In a few sentences, how would you describe what your project was?

My team set out to program Baxter to play a game of checkers with a standard-sized board and as few deviations from the real deal as possible. This required a cohesive blend of motion planning, computer vision, and artificial intelligence all tied together by a state machine in ROS. We also designed and printed grippers that would maximize our chances of grasping a piece in case of small errors in the vision-to-motion planning pipeline.

What were the biggest challenges you faced?

The motion planning aspect of the task definitely required the most tuning and tinkering because of Baxter's large seven-degree-of-freedom arms trying to manipulate small checkers pieces. It's still not perfect, but we managed to average around three mistakes per 30-minute game. I had the option to use pre-existing Python libraries for inverse kinematics and motion planning or to use Movelt, a ROS package I had no previous experience with. I chose Movelt because I wanted to learn something new, and looking back, I'm glad I did! I think with a little more digging, Movelt can help me bring my motion planner's failure rate down to zero.

What were the most important lessons you learned from the course?

I really enjoyed this course's approach to ROS. My peers and I expected it to be a standard-format course where you only learn what you are explicitly taught. Instead, Prof. Elwin showed us how to learn ROS on our own, which is so much more valuable in the long run! I was able to implement a state machine using the smach package and to call my motion planning methods using my own action servers, which made my code cleaner, more reliable and easier to debug. Neither of these nor MoveIt was taught explicitly, but since I was shown how to navigate ROS documentation and forums, I was able to pick them up fairly quickly.

How do you think the final presentation went?

The presentations were a lot of fun! It was exciting to see everyone's projects working after weeks of struggling together. I was really impressed with the creative solutions my classmates implemented and I learned a lot from them. Our professors and TAs from other courses also came to watch the demos and ask questions, which gave us an opportunity to practice describing technical concepts to others. The questions they asked also gave us a lot to think about in terms of improving our projects.

What do you hope other students can learn from the work you did?

I hope that future students tackle their project ambitiously and push themselves to learn new skills. My belief is that if you do something that's slightly too hard for you, then you can't lose. At the very least, you'll end up learning something.