Goal
Let Baxter play Sokoban
Design Criteria
There were several actions that we need to perform:
- The USB camera must be able to read the map by detecting AR tags.
- The code must be able to generate a game map and store it at txt file.
- For playing manually:
- The code must be capable of catching the input on the keyboard.
- The code must be able to check whether the input movement is valid or not.
- For playing automatically:
- The code must be able to return the available best paths.
- The code must capable of converting the planned paths to transforms.
- The Baxter must be able to detect the origin of the map and return its transforms.
- The code must know how to compute inverse kinematics and return the appropriate coordinates.
- The Baxter must have the ability to move to the specific box, grip it and take it to the destination position.
Our Design
Map Building:
Manual Control:
Automatic Control:
- We elected to use solid wood cube attached with paper AR tags for the boxes and the walls. We build the actual map grid on paper cardboard. We overlaid the map with smaller cardboard pieces representing the gripper starting point, destination 1 and destination 2. In order for the computer to be able to distinguish between the items, different AR tags represented boxes, destinations, barriers, gripper stating point and map origin respectively.
- We would use USB camera to capture the AR tags and send them to Ar_track_Alvar to be detected.
- We would then modify our subscriber and use it to echo the transforms of each AR tag, to the map frame, and store them in txt file.
Manual Control:
- We want to code a Python file to control the gripper directly by pressing forward, downward, left, right to move the gripper, and special grip and loose keys to control the grabbing and dropping capabilities of the gripper.
- We create a rule function which knows the current map and stops illegal moves. It then returns a warning.
Automatic Control:
- We create a search function to search the available best paths.
- We process the path to a transform from the coordinate frame of our origin, to each child frame.
- We do some fine-tuning, adjusted hyper-parameters after a lot of cross validation on training data.
- We use the MoveIt package to return the move by computing inverse kinematics.
- We elected to use the left-hand gripper to grip the box and left right hand to be stationary and read the AR tag on our map.
Trade-offs:
We had to decide among several trade-offs when finalize our design:
USB camera versus Head camera versus Hand camera:
When building the map:
We choose to use USB camera. Because the head camera of Baxter far from our map and small AR tags and both the left-hand and right-hand cameras are in poor camera resolution.
When echoing the coordinate transforms:
We choose to use right hand camera. Though the left-hand camera is clearer than right one, since we use left hand to grip the box, which shakes heavily when moving the box, we are not able to do enough camera calibration to make the input image clear.
Computing IK versus MoveIt or another IK package:
We choose MoveIt package. MoveIt package analyze Inverse Kinematics randomly which will generate some weird planning path, but we use it at last by split each individual move to several pieces to reduce the possibility of returning a strange path.
USB camera versus Head camera versus Hand camera:
When building the map:
We choose to use USB camera. Because the head camera of Baxter far from our map and small AR tags and both the left-hand and right-hand cameras are in poor camera resolution.
When echoing the coordinate transforms:
We choose to use right hand camera. Though the left-hand camera is clearer than right one, since we use left hand to grip the box, which shakes heavily when moving the box, we are not able to do enough camera calibration to make the input image clear.
Computing IK versus MoveIt or another IK package:
We choose MoveIt package. MoveIt package analyze Inverse Kinematics randomly which will generate some weird planning path, but we use it at last by split each individual move to several pieces to reduce the possibility of returning a strange path.
Relation to Real-World Criteria
If this robot were used in a more real-world application, we would need to increase its robustness and efficiency. Below we outline areas that our robot was not robust, or efficient, and we outline some solutions in our Conclusion.
Robustness:
Efficiency:
Robustness:
- The movement of Baxter’s hands are not that accurate, we had to change our 3-inch boxes to 2-inch boxes to avoid Baxter’s gripper failing to grip the box.
- We drew out a specific grid on our map, and outlined specific places each box goes within each grid square, to ensure that the camera could detect the AR tags more accurately, and that the gripper would be able to grip the box.
- We had to add a small constant to the Y-axis of each coordinate transform to avoid the gripper knocking onto table.
Efficiency:
- Our search algorithm was somewhat brute force, could definitely improve ithad we implemented more binary searching algorithms.