It is truly unfortunate that I had to lose all of my school files when I had trouble moving data over from my last computer, since I don’t have all the CAD files and pictures that I took for this project now. The project was done as part of the Robotics class, which is an technical elective in the RIT curriculum. We were able to create our own project idea that could accomplish any objective as long as the project as a whole demonstrated separate search, test, operate, and home-finding phases.
Shortly before the class, I had taken a Table Tennis wellness class as a required add-on to the curriculum, and in the class I was amazed by the little ping pong ball collecting devices, which simple consisted of a clear plastic tube that was cut at 45 degrees at one end and had an elastic band strung across this opening using two holes. The idea was that you just found a ping pong ball (on the floor, which there are hundreds there when people are learning ping pong) and press the angled end down on the ball. The ball passes the elastic band and then can’t fall back through, since it doesn’t weigh anything. A truly genius device to say the least. A link to this item can be seen below.
Now there are other devices that can be used to do the same thing, but this concept was very easy to implement using a servo mechanism, and it could be easily tied to the project objectives listed above. Also, the robot had some practically, which helps in writing up all of the paperwork that is associated with the project. My randomly assigned partners on the project, Stu and Will, were not very interested in the project because they were both in Senior Design during the same quarter, so I was able to go ahead with the idea.
In the end, I ended up building a Lexan chassis that I machines all of the mounting holes into after laying everything out in ProE. It was the first time I had ever used a solid modeling program to diagram where everything would go, and it did take a significantly long time to make all of the models and the assembly. However, in the end I was very impressed with how well it came out in the model, and how easy everything went together when I machined the parts accordingly. I can definitely see how it is worthwhile on higher budget projects. And the CAD work was quite fun once you got into it.
A ping sensor was used for object detection, two QTI’s were used for line following, continuous servos connected to wheels with small casters in the rear were used for the locomotion, and an additional QTI was used to detect the presence of three balls in the tube. The tube came from a pack of ping pong balls I bought at Dick’s, since it obviously had precisely the right diameter for the application. Elastic string from A.C. Moore was run around four holes at the bottom of the tube in a square array to accomplish the ping pong collector mechanism. A hole was also cut into the top using a Dremel tool for the QTI. The power system for the robot ended up being some old NiMH 8.4V battery packs from an RC car I once had, which worked surprisingly well even though they barely held a charge. Finally, the whole robot was run on a Stamp microcontroller, since that was what was taught in the class. I am now part of a group working on changing the curriculum over to Arduino to catch up with the 21st century, but one step at a time.
The project had its own problems to overcome, though they were relatively minimal in comparison to those encountered by some of the other groups in our class. From what I can remember, we first had the problem of using a Ping sensor to detect items at ping pong ball height, which meant a very low mounted sensor that would detect many of the imperfections in the floor. This was corrected for by angling the sensor slightly more towards the ground (long trial and error process), along with developing a re-scan function in the code triggered by a counter if the sensor happened to still get a false reading. This was about the time we also found that the batteries we were using were being drained fast, and that this low voltage was making the sensor malfunction. That’s when I decided to change to the RC batteries. Originally, we also tried using a micro switch to test and see if the tube was full of ping pong balls, but we found that often prevented the balls from dumping out of the tube, Hence the replacement with a QTI sensor. The chassis had to also be supported in the middle where the slot was cut for rigidity, and the QTI sensors had to be moved to be on axis with the servos so that the wide wheel base could line follow. Finally, floors are really dusty. So much so that servo wheels with rubber bands around them for traction commonly slip when trying to move around. This makes nearly everything difficult, and we never did find a workaround to this besides repeatedly cleaning the floor. So lame.
A video of the robots operation can be seen below, which is notably more edited because it was used in our class presentation. To sum up the operating concept, the robot basically starts somewhere in the course, spin 360 degrees scanning for ping pong balls, then moves a distance if it does not see one. If it does see one, it starts moving towards the ball using a routine that keeps the ping pong ball on the edge of the conical detection range of the Ping sensor. When the ball gets to within a specified range of the ball, the robot then executes a specifically measured turning maneuver and pressed the tube down onto the ball. It the returns to the search algorithm. If the robot encounters a line while moving, it goes through a turning maneuver depending on which QTI (right or left) encountered the line first, keeping it inside the playing field. A counter was added to this aspect so that it would not speed long periods of time scanning the same area of a corner. When three balls were successfully collected, the robot would then drive straight until it located a perimeter line, at which point it would go through the overly complicated but notably robust line mounting sequence so that each QTI would end up on either side of the line for the robot to follow the perimeter in a counterclockwise direction. The whole time it followed the line it looked for an object at a short distance, in this case the collection container. When it finally reached the end, it would execute a turning sequence that ended in dumping the balls into the container.
A bit on the complicated side? You betcha. Practical? Debatable. Educational? Extremely. Robust? Surprisingly. Since I was so “gung-ho” on keeping the project moving forward, we actually were done a week or two early and had time to refine the code to run faster and deal with all the extreme causes encountered in line following. We found that there was a way to have the robot mess up its line mounting algorithm if it hit a corner in a certain way, so we thought outside the box and cut the corners off of the box. We also worked out a way to get around if the robot somehow just caught the tape near the opening that led to the collection container. So ignoring dust on the floor, a bulletproof project. I even demonstrated it Imagine RIT that year. Kids really like to watch robots.
TSouth Projects 