Robot Bugs

This section contains bugs for all parts of the robot, including the chassis, gripper, camera, and laser. First the chassis: As mentioned earlier, sometimes either the left or right tire would attempt to go over the electrical outlet in the floor and would stall. This became a very large problem as the project went on. Towards the end of the project, though, we found a workable solution to this. We placed shoeboxes on top of the outlets and the outlets would appear as obstructions that could be avoided on the robot map. The shoeboxes were also small enough not to be major obstructions.

Second, the robot’s gripper facility had some bugs. The first problem we had was in adjusting the gripper height. The height could only be adjusted when moving up. The problem came in moving the gripper down. The gripper had to be lowered all the way to the bottom of its range and then raised to the desired height. While this was a hardware problem, it was also an API problem as it was controlled by software.

Third, the camera had some issues as well. The camera can only handle approximately 30 frames per second, and the code on the robot runs much faster than that. Also, due to varying lighting conditions in the room, it would not pick up the markers on the chair or it would pick up reflections from the lights on the floor.

Fourth, the laser also had some problems. The laser has a wide range (180 degrees, 90 left of center and 90 right of center), but no objects can be seen behind the robot. This can be a problem because nothing directly behind the robot or to the rear quarters of the robot is seen.

API Bugs

In the development process, our team found many subtle bugs in the API not only for the robot chassis, but also for the subsystems of the laser, the camera, and the gripper.

First, the laser software bugs. The included programs such as the Markov Localization Module and Gradient Path Finding worked very well. Unfortunately, we were unable to use these included modules when it came to the point of pushing a chair. The Localization and Gradient Modules considered the chair in the robot’s gripper an obstacle that had to be avoided. Extensive research and development on this point yielded no major success. Due to this problem, we developed our own obstacle avoidance using the getClosestBox function along with our own algorithm. (Please see Coding Algorithm Design Document for details). This function returns an integer although all of the ActivMedia documentation and compilers claim it returns a double. This led to many problems in initial testing and, in the end, led to many erroneous warnings being generated at compile time.

Second, the gripper software has bugs. The gripper software has a feature to allow it to tighten its grip on an object. The more common way of doing this in robotics involves adding more pressure to the paddles of the gripper. Not so with ActivMedia. To do so with the robot’s gripper requires a function to be called and the parameter to that function is the number of milliseconds for the gripper to keep pressing inward. Unfortunately, there is not a constant for it to keep pressing.

Third, the camera had a few bugs as well. For the most part, the camera served the project very well. However, there were some problems with the pan and tilt features of the camera. In many cases, it would seem to randomly change these values.