Build, Test, Document
Table of Contents
At this stage we've began to build and develop our project. This page will contain details relating to the first initial build, assembly, and development and any issues, tests, or otherwise that occurred during this phase.
Build, Test, and IntegrateOur plan for project development can be seen on our project management page here.
Sub-Component Test Plans & Test ResultsAs each subsystem is built, it is tested as detailed is the document and marked off.
PCB Test ResultsPCB testing consisted of first debugging each of the major circuits shown. Each circuit was found to pose its own set of challenges between choice of components, soldering skills (and equipment), and trace impedance. As it was discovered, the 12V (buck-boost converter) was determined to generate the most noise of any of the circuits.
Each circuit was tested individually, and then loaded to see the range of tolerances that could be accepted. The chart below shows each circuit, with the gauge, or battery status indicator LEDs hooked up in parallel (as will be seen in the finished product).
Unfortunately, due to flaws within the layout and design of the board, it has proven to be unreliable for the ultimate scope of our project. Although each circuit was able to function and load individually, not all circuits could function and load collectively.
The 6V and 9V circuits appeared to be functioning, and were thoroughly tested powering the micro-controller and the servo motors. A test program showing the full function of the motors (moving 0-360 degrees and back) was running on the micro-controller for several minutes before it was noted that the 6V regulator chip was disintegrating. This was likely caused by an over-current condition, not accounted for in the design. Servo motors stop through use of an electromagnetic brake, which yields for a spike over-current condition at both the beginning (initial movement) and end (final movement [stop])of their movements.
The fatal flaws within the board could be related to many factors. One factor could be attributed to the "loop" of each circuit not being kept close together for the board layout. Rather, two of the circuits were severely intertwined within each other, which may explain why there was so much noise present on the output of one circuit. Aside from that, an auto-router was used to route the board, and unfortunately this was not as efficient was previously thought and caused for traces to be routed in unsuspecting ways. Also, using high frequency switching regulators naturally generate a lot of noise and are dependent upon feedback current. During testing, failures of the board were seen simply by leaving the outputs unloaded. Lastly, although through-hole components were mostly selected to be an easier soldering job, the regulator IC's were not. Although it was easy to change a resistor, it was nearly impossible to change the regulators, simply related to their size (this also may have caused a failure by having a chip improperly, or poorly soldered to the board).
In any case, ultimately all or a combination of all of these factors have given the electrical engineers in this project the conclusion that this board cannot be used as was originally intended. As a backup plan, the 9V and 6V regulator circuits were actually able to be replaced by simple DC/DC buck converters from Keedox. The board will still be used for 12V regulation for the Geo-PNT and the battery status indicators.
Battery Test ResultsThe battery testing simply consisted of testing charging time, as well as draw time - hence one cycle of the battery, from full charge to nearly dead. Since the PCB was designed to account for a range of voltages, the battery should give the team more than ample time to complete a constant multiple-hour, continuous time test, as evidence by the data below.
The charge time was comprised of two separate trials, and since the charging time takes more than 4 hours to fully complete, the battery was not entirely charged for the second test. This was deemed a passable test however, because the battery was able to still give off enough voltage for a significantly large, and constant current draw.
Once the battery was fully charged, it was cycled using a 1.5A constant current load, comprised of seven, 10-Watt resistors - ultimately giving a resistance of 7.647-ohms. The battery was able to provide ample voltage throughout the entire 3-hour test, as seen in the chart below.
From the test data acquired, it's safe to say that this battery should supply more than enough voltage and current for an entire duration of running our system. Since our system shouldn't be running much longer than 3 continuous hours, and our current will be variable, with currents mostly seen to be much less than 1.5A, the conclusion can be drawn that this battery will be a suitable and sustainable fit for our project.
For a raw view of the data acquired through testing of the battery and the PCB, follow the link below.
Mount Test Results
- Motion Test
The mount was first verified for matching the angle, or pointing direction of the mount to an associated angle. In the test data file below, it was verified that there is about a 1.299 degree change per tick in the servo motor for the tilt motor and a 1.481 degree change per tick in the servo motor for the horizontal motor.
Also, a mapping from degrees-to-bits was required to develop the control signal to send to the servo controller. Essentially each degree needs to mapped to a number of bits for pointing the camera in the desired direction. The home position of the horizontal motor was set to be when the tilt arm is at the rear of the lid, as shown below.
As the image above shows, by having the tilt arm in the home position at the rear of the lid, the camera is pointed to 0 degrees.
Likewise, the tilt motor was also mapped to degrees, as shown in the image below.
As the image above shows, the tilt motor was also mapped to degrees. It's important to note that the tilt motor will not be exceeding 180-degrees, since objects that we will be tracking will not be below the mount and enclosure.
Once the degrees determination for the mount was determined, it was then necessary to convert this into a byte mapping to point the camera at the desired angle. The mount operates using a 3-byte signal with the following format:
In the 3-byte address format above, the first byte identifies a motor control signal, while the second byte controls whether it's for the horizontal or tilt motor (1 for horizontal and 2 for tilt), and the third byte is for range of motion. The test data file below shows a mapping for the third byte range of motion into degrees.
- Motor Backlash Test
- Stall Torque Test
Geo-PNT Test ResultsTest data / results for the Geo-PNT can be seen in the file below:
Camera Test Results
In order to convert pixels to degrees for the computer vision program that will be used to determine error, each pixel had to be correlated to an amount of degrees for each level of zoom.
- Water Resistance Testing
It was important that the electronics enclosure and mount be water resistant. If caught in the rain during testing, we would want to make sure all components would be protected.
By visual inspection, no water was found on the inside of the enclosure and the pan/tilt mount functioned normally after the test.
- Vibrations Testing
There were two major things that needed to be concluded from this test; 1) that no components inside of the enclosure would break and 2) that the footage acquired from the camcorder atop the pan/tilt mount did not shake too much.
Through visual inspection, no damage to components was seen. The camcorder footage by visual inspection was concluded to be minimal.
System DemonstrationAfter all of our sub-components were tested, the system was integrated and general functionality was tested. The video link below shows a test program written by our computer engineers that demonstrates control of our mount. (For a complete system demonstration, check the Publications & Presentations Page)
The system was then taken outdoors to verify the equations of motion and conduct object tracking - testing. For each target location, the microcontroller had to be re-programmed with the target location, thus it was held outside of the enclosure so that re-programming could easily occur.
Overall System Results
Our overall system results were obtained upon the entire system assembly. With the system fully assembled, and each sub-component tested and verified, we were able to finally test our entire system. Compiled results for our subsystems can be found below.
Although we have custom developed an error measurement program, we have decided to manually determine our error at this stage of the project until our tracking improves. We executed an example tracking test, the video of which can be seen below.
This video was then manually analyzed and the results of this can be seen in the file below.
The concept of tracking our error is represented in the image below. By measuring how far off from the center pixel of the screen, we can validate our system. As of now, this concept is still a work in progress and may not be necessary because we have the ability to manually validate our error.