MAIN DESIGN CONCEPT
In
order to accomplish our goals we needed to come up with a mechatronic
design that addressed the need to store and load balls, launch balls,
and track targets.
Regarding the need to store and load balls, our initial approach was to use a simple hopper to use some other device to ensure only one ball travels to our firing mechanism at a time. However, upon investigation, we determined that this design was unreliable since it was prone to jamming. After evaluating a few other designs we settled upon a rotating carousel ammo repository. A triangular block is placed on top of our carousel so that balls do not prematurely fall into the hole leading to the firing mechanism and so that balls that are stacked on top of each other will not pass through to the hole, i.e. only one ball will fall through the hole with any given 60 degree rotation – the ball on top will be blocked and will either fall on top of the next ball in line or fall into an empty ball slot. Notice that our ball slot design ensures that the balls within the slots do not touch the walls of the carousel. This is advantageous for us because we previously discovered that the friction between the balls and the carousel wall was great enough that it would either cause our motor to fail or make an incomplete rotation. We decided upon using a stepper motor to drive our carousel because stepper motors require no feedback and are easy to rotate precisely. The only disadvantages of using stepper motors is that they are typically weaker than DC motors and while they are being turned the computer program controlling the entire system cannot continue to run until it stops rotating the stepper motor.
Regarding the need to launch the ball, we’ve first considered many different options. We chose not to use a mechanism that relied on a spring-like material since we knew that extended usage/testing would cause wear on the material and thus provide different results. We also figured that using such materials would result in a high reload time since spring-like materials strong enough to launch Nerf balls 10 feet would be difficult to compress or extend. We chose not to use compressed air as a means to launch the Nerf balls because we thought that pressurized air would be difficult and dangerous to work with. We also figured that using compressed air would necessarily result in a high reload time. The third major approach that we considered and ultimately went with was to launch balls by feeding them to a spinning wheel, much like how automatic baseball pitchers work. A typical automatic baseball pitcher uses two side-by-side wheels to launch balls, but our design only uses one wheel. There are a few reasons behind this decision. First, we did not want to worry about the possibility of having two different speeds on the wheel. Second, with one wheel positioned beneath the ball we can apply backspin to the ball. We figured that we could use backspin to our advantage and increase the horizontal range of our firing mechanism. We were worried that the spinning wheel method of launching projectiles would be inaccurate and/or imprecise, but after we researched existing projects from other universities we learned that it is indeed possible to have accuracy and precision with a one wheel shooter.
Regarding the need to track targets, we had several options for computer vision available to us. One approach would have been to use a CMU Cam device, but we chose not to use this approach since the CMU Cams were not available until halfway through the semester and we wanted to start working on the vision aspect of our project earlier. The CMU Cams were also too expensive for our tastes. Another option was to use a webcam and a powerful microcontroller/microprocessor to utilize open source OpenCV code to detect targets. We decided against this approach for several reasons. First, none of us had any prior computer vision experience and we were afraid that this task would be beyond our capabilities. Second, we did not want to use a complicated microcontroller/microprocessor just for the sake of computer vision. We wanted to use an Arduino since it is easier to work with and would thus reduce the probability of human error. Our last option (and the one we ultimately went with) was to hack a Wiimote camera. The Wiimote camera has the smallest field of view compared with the other options and it can only detect sources of IR light, but we decided that the Wiimote was the best approach for our needs since it had a fast response time and, most importantly, it was capable of doing all necessary computer vision calculations by itself and output the positions of up to four sources of IR light as x and y coordinates. Detecting the targets would necessarily involve illuminating them with IR light, but we felt that this would not be a significant issue down the road. Another advantage to the using the Wiimote is that the Wiimote camera, unlike the other options, is not affected by regular ambient lighting (with the exception of sunlight) and does not require recalibration every time the lighting conditions of our environment changes.
Our system also needs to be able to hit targets of varying height. To address this need, most teams decided to implement a tilting mechanism to change the angle in which they launch their balls. We did not implement this approach because our carousel/chute design relies upon gravity and momentum to have balls roll uphill into our barrel. Changing the tilt would mean we would have to have a flexible chute and we would have different input velocities for the ball entering the barrel. In the end, we decided upon keeping our launch angle constant and to vary the projectile’s maximum height by varying the speed of the spinning wheel and thus the output velocity of the projectile.
Another design decision we made was to attach our camera directly on top of our panning base. This was necessary since we relied upon our camera’s data as feedback for which direction our system is facing because our panning motor did not have an encoder. Our panning motor did not have an encoder because motors with built-in encoders were too expensive and we physically did not have enough space to add on our own encoder. One drawback to this approach is that depending on where our system pans we sometimes lose sight of several targets. This is undesirable because our camera cannot tell by itself whether the system is pointed to the right half of the target range or the left half. This is a problem because then the system does not know which way to pan to search for other targets. This problem was ultimately solved through software.
Regarding the need to store and load balls, our initial approach was to use a simple hopper to use some other device to ensure only one ball travels to our firing mechanism at a time. However, upon investigation, we determined that this design was unreliable since it was prone to jamming. After evaluating a few other designs we settled upon a rotating carousel ammo repository. A triangular block is placed on top of our carousel so that balls do not prematurely fall into the hole leading to the firing mechanism and so that balls that are stacked on top of each other will not pass through to the hole, i.e. only one ball will fall through the hole with any given 60 degree rotation – the ball on top will be blocked and will either fall on top of the next ball in line or fall into an empty ball slot. Notice that our ball slot design ensures that the balls within the slots do not touch the walls of the carousel. This is advantageous for us because we previously discovered that the friction between the balls and the carousel wall was great enough that it would either cause our motor to fail or make an incomplete rotation. We decided upon using a stepper motor to drive our carousel because stepper motors require no feedback and are easy to rotate precisely. The only disadvantages of using stepper motors is that they are typically weaker than DC motors and while they are being turned the computer program controlling the entire system cannot continue to run until it stops rotating the stepper motor.
Regarding the need to launch the ball, we’ve first considered many different options. We chose not to use a mechanism that relied on a spring-like material since we knew that extended usage/testing would cause wear on the material and thus provide different results. We also figured that using such materials would result in a high reload time since spring-like materials strong enough to launch Nerf balls 10 feet would be difficult to compress or extend. We chose not to use compressed air as a means to launch the Nerf balls because we thought that pressurized air would be difficult and dangerous to work with. We also figured that using compressed air would necessarily result in a high reload time. The third major approach that we considered and ultimately went with was to launch balls by feeding them to a spinning wheel, much like how automatic baseball pitchers work. A typical automatic baseball pitcher uses two side-by-side wheels to launch balls, but our design only uses one wheel. There are a few reasons behind this decision. First, we did not want to worry about the possibility of having two different speeds on the wheel. Second, with one wheel positioned beneath the ball we can apply backspin to the ball. We figured that we could use backspin to our advantage and increase the horizontal range of our firing mechanism. We were worried that the spinning wheel method of launching projectiles would be inaccurate and/or imprecise, but after we researched existing projects from other universities we learned that it is indeed possible to have accuracy and precision with a one wheel shooter.
Regarding the need to track targets, we had several options for computer vision available to us. One approach would have been to use a CMU Cam device, but we chose not to use this approach since the CMU Cams were not available until halfway through the semester and we wanted to start working on the vision aspect of our project earlier. The CMU Cams were also too expensive for our tastes. Another option was to use a webcam and a powerful microcontroller/microprocessor to utilize open source OpenCV code to detect targets. We decided against this approach for several reasons. First, none of us had any prior computer vision experience and we were afraid that this task would be beyond our capabilities. Second, we did not want to use a complicated microcontroller/microprocessor just for the sake of computer vision. We wanted to use an Arduino since it is easier to work with and would thus reduce the probability of human error. Our last option (and the one we ultimately went with) was to hack a Wiimote camera. The Wiimote camera has the smallest field of view compared with the other options and it can only detect sources of IR light, but we decided that the Wiimote was the best approach for our needs since it had a fast response time and, most importantly, it was capable of doing all necessary computer vision calculations by itself and output the positions of up to four sources of IR light as x and y coordinates. Detecting the targets would necessarily involve illuminating them with IR light, but we felt that this would not be a significant issue down the road. Another advantage to the using the Wiimote is that the Wiimote camera, unlike the other options, is not affected by regular ambient lighting (with the exception of sunlight) and does not require recalibration every time the lighting conditions of our environment changes.
Our system also needs to be able to hit targets of varying height. To address this need, most teams decided to implement a tilting mechanism to change the angle in which they launch their balls. We did not implement this approach because our carousel/chute design relies upon gravity and momentum to have balls roll uphill into our barrel. Changing the tilt would mean we would have to have a flexible chute and we would have different input velocities for the ball entering the barrel. In the end, we decided upon keeping our launch angle constant and to vary the projectile’s maximum height by varying the speed of the spinning wheel and thus the output velocity of the projectile.
Another design decision we made was to attach our camera directly on top of our panning base. This was necessary since we relied upon our camera’s data as feedback for which direction our system is facing because our panning motor did not have an encoder. Our panning motor did not have an encoder because motors with built-in encoders were too expensive and we physically did not have enough space to add on our own encoder. One drawback to this approach is that depending on where our system pans we sometimes lose sight of several targets. This is undesirable because our camera cannot tell by itself whether the system is pointed to the right half of the target range or the left half. This is a problem because then the system does not know which way to pan to search for other targets. This problem was ultimately solved through software.
SYSTEM OVERVIEW
 |
| Figure 1. System Overview |
SUBSYSTEMS
Base Housing
 |
| Figure 2. Base Housing |
The base housing is comprised of two half-inch thick acrylic sheets, four hexagonal aluminum extrusions, and electronics. There is an Arduino Mega Microcontroller, three motor control boards, a stepper motor board, and a custom-made power board. The main PC power supply, which powers our system, is also located in the base housing. The custom-made power board can be thought of as a tunnel for all power and input/output signals. All the boards connect to the power board in order to receive power from the PC power supply. The boards also connect to the power board to transmit data and signals to the Arduino. There is also a DC motor mounted to the bottom of the upper acrylic sheet. This DC motor controls the panning system. In order to aid in panning, a bearing turntable is mounted to the top of the upper acrylic sheet. The turntable will be further explained in the next section. Figure 2 shows the base housing.
Shooter Assembly
 |
| Figure 3. Shooter Assembly |
 |
| Figure 3a. Custom Spinning Wheels |
The Shooter Assembly is the main firing mechanism used to launch the balls towards targets. Figure 3 shows the Shooter Assembly. An acrylic ramp is secured onto black acrylic sidewalls and serves as a path for the Nerf balls. The black acrylic walls are constructed as a rectangle with side holes for mounting a motor. Combining the black acrylic walls and ramp serves as a "chute" for the balls to travel through. There are flat acrylic pieces also attached to the top of the black acrylic walls. There are acrylic pieces, called Modified Acrylic Ramp Supports, that provide suport to the ramp as well as to the rest of the shooter assembly. The Ramp Supports are secured onto the panning base as well as to 80/20 bars in the back. In order to prevent vibrations and unwanted motion from the motor, motor supports were fabricated. These motor supports mount to the 80/20 pieces as shown in the figure. Combining these motor supports with cork reduces unwanted vibrations while adding stability support to the motor. When the spinning wheel makes contact with a ball and compresses it, there is an applied force to the shaft which would cause the motor to translate vertically. Figure 3a shows the different revisions of the spinning wheels used throughout this project. Different wheels were created to experiment with the effect that different wheels had on our launch speed. These custom wheels were created out of different pieces of acrylic using a laser cutter. One assembled, the spinning wheel is then mounted onto the motor using a custom hub. The shooter assembly itself also has a support panel that supports it underneath. The support panel can be adjusted to different heights which causes a change in the launch angle. While the height adjustments only change the launch angle by a few degrees, it is enough to vary the height of the projectile trajectory by a few inches at the distance of ten feet. The whole shooter assembly is attached to the panning base which is then secured onto a turn table. The panning base is also mounted to a panning hub that is connected to a DC motor as described in the previous section. The turn table has bearings which reduce unnecessary stress and moment on the DC motor shaft. There is also a reduction in friction which allows the panning base to rotate more smoothly.
Wiimote Assembly
 |
| Figure 4. Wiimote Assembly |
Figure 4a. Wiimote IR Camera Circuit
Carousel Repository
 |
| Figure 5. Carousel Repository |
Alex Shie (ECE) - Electronics, System Integration, Control, Vision, Testing
Chan Sik Kim (ECE) - Motion Prediction Code
Chloe "WooJoo" Shim (ECE) - Electronics, Circuit
Juan Carlos Oliveros (MechE) - Mechanical Design, Fabrication, System Integration, Video Editing, Testing
Chloe "WooJoo" Shim (ECE) - Electronics, Circuit
Juan Carlos Oliveros (MechE) - Mechanical Design, Fabrication, System Integration, Video Editing, Testing
No comments:
Post a Comment