|
The pan and tilt head was found to work extremely well. Full swing from full left to full right was extremely quick. The only small drawback was that due to the camera being heavy compared to the pan/tilt head, it carries a lot of inertia. This caused there to be slight overshoot when moving from position to position. This was observed by viewing the live feed from the camera and moving the head around with the test controller. The effect could be seen with the image displayed jumping around. It was not considered much of a problem as the effect decays rapidly however to prevent this causing any problems it could be overcome with a small delay after a move to allow the image to settle. A video example of this is available on the attached CD.
The controller functioned extremely well, over the complete project not a single command sent was misinterpreted or resulted in an error. One issue which was not clear to start with is that the move left, move right, move up and move down commands (x++, x--, y++, y--) can cause a slight undesired action. If say the x position is 255 (Maximum) and X++ is called the position will rollover to 0, meaning if the camera attempts to pan beyond its limit, it will move to the opposite position. Ideally it should produce an error warning or stop.
The IR filter on the camera was a key part of the system as it was required to make the beacon stand out from all the background light. The filter blocked out a large amount of visible light, the effect of which is best demonstrated in the images below:
Figure 38 - Visible & IR image (36lux)
Generally the filter functioned extremely well however in direct sunlight or with a large amount of external light, errors were happening, where the scanning system would lock onto a patch of light rather than the IR beacon. This was solved by restricting the amount of external light. All the work was generally carried out with the blinds closed to minimise background light.
A number of example images were captured to investigate the properties of light reaching the camera, and these are shown below. To measure, the camera captured an image while the light meter was placed beside the camera to measure the light intensity reaching the camera. It is important to note that Lux is a measure of human brightness perception not IR light[xxviii] which humans cant see.
The results are expected. With the lights off and window closed there is minimal illumination and little IR light however with the lights on, or the window open there is much more illumination. From these experiments we can see that there is more IR light from the sun than fluorescent lights. We can also see that having lights on is less of an interference than sunlight.
Another key area which was affecting the results of the system was the brightness of the receivers IR led beacon. Initially this was setup to work at a distance of 1m by viewing the feed from the camera and adjusting the variable resister till the brightness level is appropriate. However when adjusting the brightness for greater distances, an ammeter was placed in circuit with the beacon LED to measure current drawn. It was found a current flowing into the LED of 1mA was appropriate for a distance of one to three meters, however for distances greater than this 10mA was chosen. An important consideration here is that the PIC can only supply 25mA maximum. This needs to be monitored when setting the brightness.
Figure 42 - Beacon Led 1mA (Left) & 10mA (Right) @ 1m
Tests were carried out to determine the success rate of the system actually achieving lock and data transfer at a distance of 1 meter. This was carried out by setting up all the equipment with the required software and repeatedly running the main AreaScan program on the controlling PC. By Incrementing the transmitted value each time it was possible to determine the success rate of the communication system and also the success of the receiver locating part of the system.
Since the initial objective was to function over a distance of one meter, this was chosen as the initial distance for testing. During the process of testing however, it was soon discovered that the system could potentially function over distances of greater than 1 meter. Therefore complete scanning tests were carried out over a distance of 16 meters. This distance was chosen as it is the maximum distance possible due to the dimensions of the final year project lab. The brightness of the IR LED was adjusted to compensate for the extra distance. The capture card for the scanning system was installed on a fixed PC therefore it was not possible to move it to another room or area.
The tests were carried out in a controlled environment, the final year project lab, with all the ceiling lights turned off and all outside light blocked. The only sources of light in the room were the computer screens and a small desk light used to illuminate the work area. This was positioned to cause almost negligible light interference by positioning behind boards and away from the cameras field of view. Before carrying out the experiments, the light levels were checked by previewing the live feed from the camera and scanning the whole room.
Table 6 – Results
Acknowledgement Data
sucess1m : [31 28 27 30 29 26 28 24 27 30 30 29 27 25 30 29 26 29 29
29 28 28 29 23 29 24 28 30 29 27 25 30 28 19 23 28 22 ]
sucess16m : [26 28 28 27 28 30 28 26 31 28 28 29 26 29 30 27 27 28 31
29 28 30 26 28 28 25 29 30 26 29 ]
Figure 43 - Histograms of Acknowledge lengths at 1m (Left) & 16m (Right)
The results obtained were extremely good. Out of the 80 recorded tests and countless unrecorded tests not a single data string was misinterpreted. The change of achieving successful lock on at a distance of 1 meter was greater than 90% even for such a small sample size. Due to time constraints it was not possible to collect a larger sample size which would’ve generated much more accurate success rates. As a result The 3 fails that occurred during the experiments were caused where the camera lost sight of the beacon for one frame. This error could be resolved by re-trying the capture-locate process to negate any single frame glitches.
The success rate for the distance of 16meters was also very high, 75%. A key observation of the data is that there is a greater chance of errors at higher distances. This is what we expect, as there’s a higher chance of interference the further we move away from the transmitter. At the distance of 16 meters, 4 out of 40 failed. A further 6 attempts resulted in the correct data being received by the PIC but no acknowledge was detected. The PIC was verified as outputting the correct signal, therefore the error lay with the image processing part of the system. By debugging, it was determined that what was happening was that Matlab was detecting that the beacon went low before it actually had, this meant the maximum/minimum count was being returned. Again this problem could be solved by checking the beacon a second time to ensure that the beacon is definitely there or not there, rather than assuming that the first attempt to locate the beacon is correct.
The other way the reliability and success rate could be improved is by modifying the GetSignal function. At the moment this function works in much the same way as the FindBeacon function and simply creates a matrix of values 1 where the brightness of the pixel is greater than 80% of the maximum and 0 where it is not. The function then returns the value of this matrix at the coordinates of the last sighting of the beacon. What the function does not do is check the brightness is close to the expected brightness of the beacon. If a picture with no beacon present is captured and this function executed on it, there could be a small patch of lit area that stands out as the brightest in the scene (no where near the brightness level of the beacon pixels), if this area is where the LED was then it could be wrongly interpreted. This should be corrected in future work by extracting the expected brightness from the FindBeacon function.
The difference in lengths of the acknowledge highlight a key disadvantage of using Matlab to process the video stream that is the processing speed varied depending upon the current load on the operating system. As we can see there is a great difference in the amount Matlab counts in the fixed 2 second period.
Another effect was discovered during testing which is that sometime a false signal is detected by the receiver caused by a stray burst of IR radiation. This caused the receiving PIC to begin decoding the signal however since it is a small burst, all the data bits will be zero and the PIC will believe it is a valid command. What this caused in practice was that a correct signal would be received and the data displayed, then a short time later the data would be reset. Although the results show a small number of these errors, a large amount were observed during the project in unrecorded testing. One of the principal causes is believed to be IR signals emitted from laptops and mobile phones in the room, as the effect almost disappeared when care was taken over laptop positioning. A solution to this problem would be to have the receiver PIC verify the second start bit to ensure it is definitely a command being received, not noise.
A final problem observed during testing was that should the brightness of the beacon be too high at close range then reflections can appear on the lens and be detected by the system, even though the camera is not looking directly at the beacon. This was solved in practice by lowering the brightness at close range, however the problem could be solved by having the program continue scanning if it is lost once. Checking the frame twice would also solve it.
Figure 44 - False sighting caused by reflection on lens
|
Publications
