eski
12-25-2007, 09:16 PM
I was contacted by somebody who suggested I should enter our senior design project here. Seeing as how we found and used the AX-12 (http://www.trossenrobotics.com/bioloid-dynamixel-ax-12-robot-servo.aspx)s from Trossen Robotics, I figured this would be a great place to post.
This project was our senior design, a semester long course that requires a team of electrical and computer engineering undergraduates to design, order parts for, build, and program a piece of their choosing. We figured that, since we knew we'd be locked up in the senior design lab anyway, we should at least do something at least mildly entertaining. We were given about a $500 budget from the school. Before I get any further, I'll go ahead and post the video for a visual of how it all works:
zPbp8RHTf50
Now a top-down explanation:
The ball and all opponent players are tracked visually with a webcam hooked up to the computer. Both are unique colors, so tracking becomes a trivial task. In order to increase the processing speed, trajectory prediction is used. This allows the ball to be localized to a "most likely" position, around which, individual pixels may be searched. The advantage to using a visual system is that it's more true to the way humans play. We wanted to create a robot that played the game as much like humans do as possible. An alternative method would be to either implant a locator in the ball or furnish the table with an array of sensors. One additional advantage is that webcams are CHEAP compared to any other system. Finally, by using a visual system, we can track any number of objects, none of which need to be "specially outfitted." We can track each trajectory and there is little to no ambiguity of what those objects are. In a time-crunch situation, it's also nice to know that it's very easy to interface a webcam to a PC (simple USB connection). The software on the PC was all written in Java, utilizing the Java Media Framework (JMF) (http://java.sun.com/products/java-media/jmf/). Contrary to popular opinion, the lag from the webcam and the processing time on the PC are so minimal they can easily be adjusted for in software.
Since this is a robotics website, I will get down to the guts and glory of what most of you are probably intested in: the servo motors. We used 2 different types of servos for this project, though in retrospect, I would probably go about the project quite differently in some aspects (I'll revel in that a little later in this post). As I already mentoned, we did use th AX-12s for 4 of the 8 motrs (1 for each row). These provided the lateral motion. The beauty behind them is how eeeaaasssyyyyy they are to program! They provide great torque, are individually addressable on a single serial link, have tons of built-in features (torque overload detection, heat overloads, etc), and they're relatively inexpensive. By using a larger external gear, we were able to convert that high torque into a higher lateral speed.
http://img338.imageshack.us/img338/6299/servo20assembly20explodgb4.jpg
To kick the ball, we used 4 smaller, faster, and even less expensive Hitec HS-81 (http://www.trossenrobotics.com/store/p/3286-Hitec-Servo-HS55.aspx) servos. Because they require their own set of PWM signals, we used a set of PIC-12s from Microchip to generate the pulse-width-modulated signal required for each kicking servo. Pieces of medium density fiberboard (MDF) tie the servos together while allowing them to move independently.
A single master servo control board is run mostly by a PIC-18 microcontroller, again, from Microchip. A schematic for the entire control board and sub-control PWM boards can be found here (http://www.eskibars.com/projects/foosball_robot/images/schematics/servo%20schematic.jpg). All of the control board costs amount to less than $40, and can be found from most major electronics distributers.
http://www.eskibars.com/projects/foosball_robot/images/demo%20pictures/demo_pic2.jpg
As some people read this, they may be scratching their heads about wh we did it the way we did -- and they would be right to be doing so. We weren't mechanical engineers and we were pressed for time and money. Often our design decisions were based only on simplicity to speed development or cost because we had so little money to work with. So the last thing I would like to go over is some of the changes we would do if we had the time and money to do this again. First, probably the biggest problem was the speed of the motor/gear system. Bigger gears would help, but in reality, a belt-based system would be the way to go. Additionally, I would probably choose to use DC motors with an H-bridge for kicking, in order to increase the kick speed. We ran into a lot of problems expecting the webcam to be true to its specs, which turned out to be a bunch of smoke-and-mirrors, manipulated in drivers. The resolution and FPS as listed on the webcam were nothing but falsifications. So a huge change would be to redo the entire system on an FPGA with a direct connection to a CCD. We could then just cut out the entire motor control board and have direct connections to the servos. Finally, given a little more time (and the other changes), a more advanced AI that implements "learning" would be the next step.
More information on the project, including downloadable source code and write-ups are available on our group website (http://www.ece.gatech.edu/academic/courses/ece4007/07fall/ece4007l01/group04/) or my personal website (http://www.eskibars.com/projects/foosball_robot/).
This project was our senior design, a semester long course that requires a team of electrical and computer engineering undergraduates to design, order parts for, build, and program a piece of their choosing. We figured that, since we knew we'd be locked up in the senior design lab anyway, we should at least do something at least mildly entertaining. We were given about a $500 budget from the school. Before I get any further, I'll go ahead and post the video for a visual of how it all works:
zPbp8RHTf50
Now a top-down explanation:
The ball and all opponent players are tracked visually with a webcam hooked up to the computer. Both are unique colors, so tracking becomes a trivial task. In order to increase the processing speed, trajectory prediction is used. This allows the ball to be localized to a "most likely" position, around which, individual pixels may be searched. The advantage to using a visual system is that it's more true to the way humans play. We wanted to create a robot that played the game as much like humans do as possible. An alternative method would be to either implant a locator in the ball or furnish the table with an array of sensors. One additional advantage is that webcams are CHEAP compared to any other system. Finally, by using a visual system, we can track any number of objects, none of which need to be "specially outfitted." We can track each trajectory and there is little to no ambiguity of what those objects are. In a time-crunch situation, it's also nice to know that it's very easy to interface a webcam to a PC (simple USB connection). The software on the PC was all written in Java, utilizing the Java Media Framework (JMF) (http://java.sun.com/products/java-media/jmf/). Contrary to popular opinion, the lag from the webcam and the processing time on the PC are so minimal they can easily be adjusted for in software.
Since this is a robotics website, I will get down to the guts and glory of what most of you are probably intested in: the servo motors. We used 2 different types of servos for this project, though in retrospect, I would probably go about the project quite differently in some aspects (I'll revel in that a little later in this post). As I already mentoned, we did use th AX-12s for 4 of the 8 motrs (1 for each row). These provided the lateral motion. The beauty behind them is how eeeaaasssyyyyy they are to program! They provide great torque, are individually addressable on a single serial link, have tons of built-in features (torque overload detection, heat overloads, etc), and they're relatively inexpensive. By using a larger external gear, we were able to convert that high torque into a higher lateral speed.
http://img338.imageshack.us/img338/6299/servo20assembly20explodgb4.jpg
To kick the ball, we used 4 smaller, faster, and even less expensive Hitec HS-81 (http://www.trossenrobotics.com/store/p/3286-Hitec-Servo-HS55.aspx) servos. Because they require their own set of PWM signals, we used a set of PIC-12s from Microchip to generate the pulse-width-modulated signal required for each kicking servo. Pieces of medium density fiberboard (MDF) tie the servos together while allowing them to move independently.
A single master servo control board is run mostly by a PIC-18 microcontroller, again, from Microchip. A schematic for the entire control board and sub-control PWM boards can be found here (http://www.eskibars.com/projects/foosball_robot/images/schematics/servo%20schematic.jpg). All of the control board costs amount to less than $40, and can be found from most major electronics distributers.
http://www.eskibars.com/projects/foosball_robot/images/demo%20pictures/demo_pic2.jpg
As some people read this, they may be scratching their heads about wh we did it the way we did -- and they would be right to be doing so. We weren't mechanical engineers and we were pressed for time and money. Often our design decisions were based only on simplicity to speed development or cost because we had so little money to work with. So the last thing I would like to go over is some of the changes we would do if we had the time and money to do this again. First, probably the biggest problem was the speed of the motor/gear system. Bigger gears would help, but in reality, a belt-based system would be the way to go. Additionally, I would probably choose to use DC motors with an H-bridge for kicking, in order to increase the kick speed. We ran into a lot of problems expecting the webcam to be true to its specs, which turned out to be a bunch of smoke-and-mirrors, manipulated in drivers. The resolution and FPS as listed on the webcam were nothing but falsifications. So a huge change would be to redo the entire system on an FPGA with a direct connection to a CCD. We could then just cut out the entire motor control board and have direct connections to the servos. Finally, given a little more time (and the other changes), a more advanced AI that implements "learning" would be the next step.
More information on the project, including downloadable source code and write-ups are available on our group website (http://www.ece.gatech.edu/academic/courses/ece4007/07fall/ece4007l01/group04/) or my personal website (http://www.eskibars.com/projects/foosball_robot/).