When we started building D.A.R.T. we made up a block diagram to see how the various parts of the system would work together.  This diagram can be found here.  As you can see, we have a fairly linear flow of information from the camera clear to the wheels.  Our task was to now make this diagram a reality.

The first step in building D.A.R.T. was assembling the necessary parts.  We had already been given the Handy Board and RF transmitter/receiver, we found a suitable piece of aluminum in the supply room, we got the motors we'd ordered, and David even found a big sheet of Foamcore for us to use.  All that was needed now were some wheels and the supplies necessary to connect everything together.  To get the wheels, Dan found a suitable pair on a toy truck at Deseret Industries for only two dollars.  These wheels worked perfectly and were well worth the price.  All the rest of the nuts, bolts, washers, cables, and vel-cro were purchased as needed.  The image of the final assembly of all these parts into a working robot can be found here.  A picture of the underside of D.A.R.T. can be found here.

While building D.A.R.T.  we discovered ways to improve on the design.  Originally information had to be passed from the RF receiver to the Handy Board through a serial adapter.  That process was a mess and we seemed to get a lot of errors between the transmitter and the Handy Board.  However, Zach found a way to pass the signal directly from the receiver to the Handy Board.  This seemed to both increase performance and make the design more elegant.  We also noticed that a Foamcore padding on the front of D.A.R.T. didn't seem to increase ball control.  Instead, we attached some real foam that was cut at a 60^o angle.  We found that this greatly increased D.A.R.T.'s ball control.  One problem with the added foam, though, is that it made D.A.R.T. too long, so we had to cut off a little of its tail.

The last addition to D.A.R.T was a Foamcore shell.  We wanted the shell to help improve D.A.R.T.'s looks as well as give us the cushioning we wanted on it sides.  A photo of D.A.R.T. with its shell, along with our mascot Wilimina, can be found here.  The shell was constructed with five pieces of Foamcore and held together with vel-cro and straight pins.  Overall, we didn't need to change our design much, and it seems to meet our criteria.

As stated in the Body-Of-Knowledge section, the programming of D.A.R.T. was a major part of this project.  D.A.R.T.'s program had to be able to read in and interpret data from the overhead camera, decide the best course of action for D.A.R.T. and then send the instruction to the Handy Board.  To help consolidate the programming, we decided early on that all the real brain work would take place in the computer while all the Handy Board did was power the motors according to the directions it received.  To try to figure out how to make this happen, we came up with some basic algorithms to manage the offense, the defense, and error correction and control.

Now, these algorithms had to be turned into real code.  David was the one who was the most responsible to make this happen.  The program he wrote had to main parts to it:  one reads the information from the vision system into the computer, and the other part decides which instruction to send to D.A.R.T.  Flowcharts that show how the final programs reader.c and vision.c are found respectively here and here. The Actual code can be found here.

Once the programs were written, then came the tough part, debugging them.  During this time it looked like the weakest links in our flow of information was the output from the camera and then sending instructions over the RF link.  While we did find ways to improve the program over time, the biggest obstacle that kept us from getting to where we wanted was the vision system.  Despite spending many hours trying to get it to work correctly, we would consistently get bad information.  We eventually came to the conclusion that our algorithms were good, but they just couldn't get reliable data.  As for the RF link, the best we could do was add parity checking.  This seemed to help somewhat, but we still didn't get the dependability and responsiveness we wanted.  Hopefully these problems will be able to be dealt with in future projects.

Requirements and Specifications
Design Criteria
Body-Of-Knowledge
Evaluating Alternatives
Selected Design
Schedule
Building and Programming
The Competition
Conclusion
Meet the Team
Images
Links