The project concluded with the team meeting most of our goals, but still just shy of being able to play checkers. Here's what we got done, what we didn't get done, and lesson's we've learned along the way. At the bottom is a collection of images of our robot from various angles.
Here's an image of our original design:
And another of the final robot as we created it:
To sum up the ability of the robot, it is capable of visually analyzing the board, making moves and maintaining a game, and navigating around the checker board.
- Computer vision can detect the state of the checkerboard.
- Given a decent image (taken in proper lighting) and camera-to-checkerboard orientation, the robot could reliable place all checkers on the board.
- Computer vision algorithm used color segmentation, requiring several consecutive pixels in order for a positive ID.
- The 80x60 pixel image captured from the camera was successfully converted into a 64 (8 rows x 8 cols) element array, from which the checker playing engine could make move decisions.
- Artificial Intelligence
- The robot could make decisions on game moves, and could make moves repeatedly.
- The AI could make single jumps, and remove the jumped piece.
- The robot could make complex moves by constructing instruction lists that were later translated by the navigation engine.
- Moved the robot using very simple fusion of sensor data, including IR sensors, wheel encoders, and a digital compass.
- The digital compass could be calibrated, and that calibration stored, for different indoor environments. While not pointing at true cardinal directions, using the calibration settings allowed the robot to successfully orient itself with high repeatability.
- In software, the robot could move itself from any checker square to any other checker square.
- A PCB was designed for the robot, which contained the processor, wireless modem, servo connectors, and sensor connectors.
- The PCB fit into a rail in the chassis, which held it quite firmly.
- The wireless modem allowed for on the fly debugging and quick program updates.
- The 3D printed chassis was quite solid and many critical dimensions were accurate.
- 3D printing allowed many motor and sensor mounts to be in correct locations.
- The camera mount allowed us to place the camera and calibrate it's mechanical orientation and angle as needed.
- A rail allowed the PCB to be inserted into the center of the bot.
- Checker Piece Gripper
- The gripper could capably pick up, hold, and drop pieces.
- The gripper was mechanically sound, and extremely easy to accurately control in software.
- The propeller could be turned to any direction needed.
- Given all calibrations were satisfactory, the bot could turn without touching any checker pieces.
What limits the robot from playing a full game of checkers is its inability to adapt to environmental conditions and poor navigational accuracy. While the following may sound like a long gripe list, this is a big picture view of what still should have been completed in order for us to have been personally satisfied.
- Computer vision algorithm was not advanced enough to reliably detect board state, and failed given even slightly different lighting conditions and board to camera angles.
- This is partly due to the fact that the selected camera does not have accessible brightness control, and has an unpredictable internal brightness leveling mechanism.
- The computer algorithm didn't search for the boundary of the board
- Checkers on the far side of the board from the robot were generally darker and fewer pixels were available to determine if a checker was present.
- The algorithm was unable to deal with fluctuating ambient light levels, such as were seen in the testing room, the Kelley atrium.
- The camera mounts were difficult to transport, and had trouble holding the camera angle constant after transportation.
- Connectors were put in positions where they were difficult to access and, in some cases, impossible to mount directly to the board.
- The PCB was slightly wider than the chassis rail, and possibly pushed bowed the chassis a little.
- The IR sensors in the front didn't match up directly underneath. They probably should have been designed to install using a header, which would have allowed board removal if necessary.
- The crystal was mounted in an area that conflicted with the grabber, causing the grabber to be 1/8" lower than it could have been otherwise.
- Motors were difficult to control.
- Resistors with 5% tolerance were used to replace the servo pot, which controls the servo stop position.
- Servos may have been damaged when modifying them for continuous rotation. In particular, the motors occasionally bound up and appeared to be skipping teeth occasionally.
- Drifting calibration values may also be due to varying battery voltages.
- Given these symptoms, closed control loops should have been added in software to maintain speeds and distances at nominal values.
- Given that the motors did not share calibration values, they moved at different speeds. The speeds were not equal, making hairpin turns difficult and imprecise (the bot would move out of the square it was supposed to stay over).
- Wheel encoders occasionally had problems. The best solution, albeit not perfectly implemented, was to use break-beam style encoders.
- Wheel mountings were not sufficient to keep the wheel moving straight. Therefore, the distance from sensor to wheel was variable.
- The original IR reflectance sensors had very poor resolution due to the fluctuating wheel distance.
- The replacement encoders, which used a blocked-beam approach, had slots cut into the wheel to allow the beam through that were not properly aligned with the encoder wheel teeth.
- Noise may have played into the sensor readings due to longer than originally planned for, unshielded wires.
- Both sensor styles were susceptible to ambient light.
- Wheels were not mounted properly.
- Rubber bands were used to increase friction, and frequently fell off. They also extended around the edge of the wheel, which caused them to grip and pull the bot up and over checker pieces instead of pushing them out of the wheel path. A track of rubber embedded in the center of the wheel would work better.
- Motor mounts were not centered, causing the wheels to occasionally rub both the inside and rear of the wheel well.
- Wheels were difficult to mount to the motor shaft. Final solution wasn't sufficient.
- Wheels were loose, and had considerable lateral wobble.
- Chassis did not have sufficient features, and had a few dimensional errors.
- Motor mounts were at incorrect location.
- Battery pack need to have placement on the chassis, not placed as an afterthought.
- Propeller mount needs to be fortified, possibly have location corrected (it broke, so we can't tell).
- Gripper assembly would have been easier if it had been integrated into the chassis.
- Propeller alignment was unreliable, software was lacking.
- The original propeller shaft was weak and frequently broke.
- The metal replacement propeller shaft had >30 degrees of slop at the connection with the motor shaft.
- A potentiometer was selected as propeller position sensor. It was selected because it could give absolute position rather than delta position, but this was grossly inadequate and should have been a high resolution encoder instead.
- When turning, software wasn't properly linking bot rotation with propeller rotation. It should have been closed loop.
- Due to lame software, the propeller would only rotate right three times and then left three times.
- Navigation was poor and lacked sufficient intelligence.
- When the propeller did not have two point ground contact, the bot was tilted. The compass needs to be held flat for repeatable accuracy, and this would cause the bot to point as much as 20 degrees off of it's intended orientation.
- When moving forward towards squares on the edges of the checkerboard, the robot would frequently put the propeller beyond the edge of the board, snagging it and sometimes causing it to break. This should have been fixed by having the bot back into edge spaces, and rotate away from edges.
- There were still a couple of known bugs in the navigation routines that would cause the bot to turn incorrectly, causing mass disruption of checker pieces (think King Kong and Tokyo skyline).
- Gripper occasionally dropped pieces.
- The gripper size was just a little too big. The foam inside wore away too fast. This may also have been because of a loose servo connection point. Other than that, it worked quite well.
- It would have been much easier to integrate parts of the gripper into the chassis.
- Non-permanent attachment (cotter pin or equivalent) should have been added to keep top platform, which held the gripper open/close servo, in place at the top of the tube.
Proposed solutions to deficiencies¶
- Computer vision
- Add a more complicated algorithm that finds the location and orientation of the checker board in the image.
- Use full blob detection algorithm or average square color value algorithm instead of just adjacent color pixel counts.
- Adjust settings based on readings from known empty squares
- As to the directly related PCB problems mentioned above, it's not critical to redo the PCB because all problems above have fairly simple workarounds. However, fixing them with a new PCB would ease wiring and serviceability issues.
- Adding an LM293D would allow us to drop the servo control circuitry and control the motors (with the servo gear train still intact) directly.
- Add a large reservoir/filter capacitor, up around 3300uF.
- Consider separate batteries, possibly Lithium Ion, for motors and electronics.
- Motor control
- Could remove servo control circuitry and wire servo motor directly to an LM293D dual H-bridge to remove calibration issues.
- Try modding a few more servos, which would let us pick one that doesn't skip teeth, "feels" best, etc.
- Add position (not velocity) PID control loops, using wheel encoders as feedback.
- Wheels and encoders
- We should design and machine our own wheels, either 3D printed or milled aluminum. The encoder disc would be integrated directly into this wheel, removing potential for misaligned encoder teeth, allowing us to embed traction in the center of the wheel circumference, and integrate a more accurate mounting method.
- Optionally, use commercial encoders.
- Camera mount should be integrated into the chassis, not an afterthought. It should be removable so it and the camera are safe during transportation.
- Motor mounts need to be corrected so wheel doesn't hit sides and back of wheel well.
- Mount for battery pack needs to be added.
- Propeller mount needs to be fortified, possibly have location corrected (the mount broke, so we can't tell).
- Gripper assembly would have been easier if it had been integrated better into the chassis.
- Compass needs a mounting location away from motors and high-current wires, and must be perfectly level with the ground.
- Shaft, if 3D printed again, should be larger.
- Shaft shouldn't go through a connector, but have mounting holes for bolts directly on the end of the shaft.
- The entire propeller should be bulked up significantly with fillets between branches and between branches and shaft.
- The propeller should be either milled out of aluminum or 3D printed again (and reinforced) with these fixes.
- A quadrature encoder should be used instead of a potentiometer as prop location sensor.
- Needs better logic to determine where it's at. Trustworthy wheel encoders will make a world of difference.
- The compass shouldn't be necessary, but if kept adding a cheap accelerometer will help correct it for tilt. Again, tilt shouldn't happen if the propeller gets fixed proper...
- Needs more testing, and deliberate debugging to track down cause of known bugs and fixes for them.
- Add more logic to the path planning functions so that the bot doesn't put the propeller near or out past the edge of the checkerboard at any point in its travel.
- Gripper occasionally dropped pieces.
- Add proper gripper servo connection point (something better than a bent wire).
- Add cotter pin (or equivalent) to top of tube.
- Determine whether to add foam or change software constants for the gripper servo so that it closes the gripper more.
There were a lot of things we learned along the way, mostly the hard way. The best way to make the project successful is to plan things out ahead of time better. We had fairly decent plans, but as time wore on and we ran up against deadlines, we started throwing out our original plans. Part specifications that should have been kept and met were systemically degraded and replaced for easier solutions that could be put together quicker. The culmination of this practice led us to the point where our robot was such low quality that it was impossible to fix in software.
The biggest lesson is spec early, spec clearly, and spec so that all components in your system play well together. Hold each other to high standards upon component completion, because if you don't no one will until the end of class and it's too late.
We also used many techniques that were unfamiliar to us. For the fact that we picked a very difficult project for the 8 weeks of the term we worked on this design, we didn't play it towards our strengths. We used a microcontroller and many electronic components that our ECE guy hadn't used before, and we 3D printed parts, which the ME guys had never done before. In order for us to have successfully realized this project, we should have realized that we needed these bases covered before the project began because there was little room for error for the amount of development that had to happen for a successful, checker playing robot.
We started with this project design because we felt it better met the "user requirements", and we still feel we're right. Our fundamental question was: If someone was actually going to buy and use a robot like this, how would they like it? Portability, battery operated, ease of use (no laptop/computer skills required), and safe for children to play were our primary specifications. However, we failed to weigh this against the resources we had. In the end, given enough time, we believe our approach would be the most economically viable approach to the problem. It is cheaper in component cost and easier to manufacture. However, the business guys would have busted us, because in the end we put three times as much work into our project than most teams. All in all, we put over 400 man hours outside of class into the project (about 20 hours/wk per person). Consider in earnest if you have that much time between you and your team mates.In summary, we would recommend for anyone in future Applied Robotics classes who may be considering a project of significantly higher caliber compared to the normal approach to weigh these factors better than we did:
- Do the team members have strengths in the areas requiring extra effort?
- How much time do you have?
- Are you willing to put everything else on hold?
And, if after a week's worth of planning and designing you're not actively convinced, be willing to back off and use plan B. Best of luck!
Pictures and Video of our Robot¶
Here are a list of links to video of our robot:
- Best video of it almost working
- Comp-U-Comp 1
- Comp-U-Comp 2
- Comp-U-Comp 3
- Comp-U-Comp 4
- Comp-U-Comp 5
Here are some images of our robot from various angles: