We shouldn't be surprised that the project didn't work out as expected - in hindsight, it would have been a shock if it had. Throughout the process, we encountered several problems and nuances, and sometimes we encountered their solutions. There were disappointments, but the occasional moment when something actually worked were enough to keep us going.
Electrical Aspects
Unlike with mechanical devices, where you can easily see when something works or doesn't, electrical systems aren't so obvious. One example of this is with the photosensors. Originally we got emitter-detector pairs, and planned on having a sensor which is tripped when a ball rolls through the path of the emitter-detector. We spent quite a while trying to get this to work, and eventually found out while the emitter emitted infrared, the detector seemed to respond to visible light as well, meaning the system wouldn't work unless it was completely dark. Simpler was better here - we just used the photoreflector sensors in the lab, and since we already knew the circuit for the component from class, wiring it was easy.
The scoreboard was the source of numerous problems as well. At first we thought it would be nice to have an actual scoreboard constructed with the 7-segment LED displays we found in the lab, but it turned out to be more complicated than one would think. Fortunately there was another group doing something similar, so we were able to get some help from them to learn how to correctly drive the displays. Building the scoreboard took several hours of prototyping on the breadboard and reading datasheets until we got the wiring correct, and once we soldered the circuit to a board it worked perfectly. However, when we tried using it in the final project we ran into another problem - current. We found that when the scoreboard and ball return motor were both plugged in, the motor apparently wouldn't get enough current and did not output as much torque. Also, when the motor ran, the scoreboard displays changed seemingly randomly. Our theory is that the Handy Board couldn't provide enough current for both. However, this occurred even with the scoreboard powered with a 12V DC adapter - the only part plugged into the Handy Board were the signal lines for clearing and incrementing the digits. The scoreboard must have been drawing some current from these output pins most of the time, even if we weren't explicitly using them, which slowed down the motor.
Output pins were another problem, namely, the lack of them. The Handy Board, as we found out, as 16 analog and digital inputs, but these are not bidirectional - they cannot be used as outputs. Since our scoreboard required digital outputs, things did not look good. Fortunately, we learned that there are 5 pins on the Handy Board that can be configured as digital outputs, which served our purposes.
Mechanical Aspects
The mechanical aspect of the project probably took the longest time because only one person was actually handling it. It would have been better if the rest of the team members also took part in the shop training so as to divide up the load and finish faster.
In hindsight, we should have used a servo motor instead of a stepper for the ball return wheel. We figured that the stepper would work fine, and we tested it out, but apparently underestimated the amount of weight it would be holding. As the automatic ball return Was one of the main features of our project, it was kind of disappointing to see that it didn't work as planned. A servo would have given a lot more torque, as well as the position control required. Unfortunately, by the time we got the idea of using a servo, it was too late to order one, and no nearby stores had cheap servos. We were stuck with the stepper, and getting it to work consistently was a challenge, though as described above, it seems that the sporadic behavior was due to current problems. We had to run the stepper very slowly to get the required torque, but that caused it to shake back and forth on each step, which didn't look very good.
The launcher went through several design changes, but in the end turned out quite well. Originally we planned on having a paddle attached to a torsional spring, which was connected to the shaft of a motor. When the motor was running, it would wind up the spring, and when the player pressed a button, the paddle would be released, kicking the ball towards the holes. We found out early on that this method would be very difficult to get working properly, and we couldn't find the right springs to do the job. Consequently, we went with a pinball plunger launcher. It would have been nice to have some sort of electronic launching device instead of the manual control that we had, but we couldn't find any easy way to implement this, so we stuck with what worked.
Software Aspects
The programming was probably the easiest part of the project - the code was straightforward to write, and even when we did have problems, code is a lot easier to test and redo than electrical or mechanical systems. If we had gotten everything working earlier, however, it would have been nice to use the extra time before the due date to add some extra features to the program.
Advice
We learned a lot from this project, and one important thing we learned was that other students are a great resource for help with your project. Along those lines, here is some advice for future mechatronics students:
- Start early - something is almost guaranteed to go wrong, so make sure you have plenty of time to design and test.
- If you are having unexpected electrical problems, check if you might be drawing too much current from the Handy Board.
- Try to make your project active, not passive - active elements are cooler.
- Keep in mind that the Handy Board is designed more for inputs, not outputs.
- For actuation that uses motors, be sure you use the appropriate type of motor - stepper, DC, or servo.
- Look at other student projects for ideas - sometimes a group has created just the circuit you need.
Disappointments aside, this was a great experience. It was great to see a finished (almost) project that was practically built from scratch. Thereís nothing better than seeing your invention do what itís supposed to do, even if it only does it sometimes. The mix of mechanical and electrical design and programming made this project challenging. Having to get it done in just two weeks was strenuous, but quite an experience.
It was nice that we used almost everything we learned in class into practice on the project. That does help to keep the info in our heads for longer than a week. The final product may not have been what we intended, but the process was a lot of fun. Looking back, maybe a game wasn't the best idea - it's hard to add active elements to a game, whereas some sort of invention with a function is mostly active. In any case, if we ever get a chance to do something like this again, things should go smoother.