Augmented Reality Control of the Telerobot 2003
Module 2: Image Capture Software
Download 6.79 Mb.
|
- Navigate this page:
- 2.2 Design/Implementation
- 2.3 Testing
- 2.4 Final Specification
- 2.5 Documentation
Module 2: Image Capture Software2.1 Initial SpecificationSoftware was required in order to capture images, save the images and import them for use within LabVIEW. After it was decided that the imaging hardware would include the QuickCam Pro 4000, image capture and manipulation would be done through the use of the QuickCam SDK. 2.2 Design/ImplementationIt was later found that the SDK could be used using a different a different class file. This was the Hydra Video Portal Class present within the hportal.dll file found in the twain_32 directory under the windows directory as opposed to the older Video Portal Class found in the vportal2.dll file under the QuickCam SDK directory. The methods in this class and their use were identical to that in the Video Portal class. However, due to time constraints, use of this class was not fully explored. Due to problems with the SDK and time limitations, it was decided to use a set of VIs developed by a third party. First and foremost, it should be acknowledged that Peter Parente produced the majority code. His code is available from http://www.mindofpete.org/labview_webcam.shtml. This code was available as LabVIEW VIs that could be used immediately the final code. However, this code was not without it’s limitations. It was only able to work with a single camera, as the dll file included with it made use of Video for Windows. Furthermore, it could only capture images at 320 x 240. This resolution was far too low for the requirements. The image captured was also mirrored. All images were captured in a 4:3 width to height ratio. There was also a problem with an image not being captured. Instead it would return a black image. This was resolved by increasing the time delay after initialisation from 0.5s to 0.7s. As a result, some code was created to increase the image size by a whole number zoom factor z. An algorithm was also required to mirror the image back to its original state. These two operations would be run in the Capture VI. It was determined that image data was in the form of a one-dimensional array which had 3 times more elements than the number of pixels. It was assumed that this would represent different colour channels for each pixel: red, green and blue. In order to enlarge the picture, each pixel would take up z2 number of pixels. The example below shows what occurs if the zoom factor is two.
This was done through the use of nested for loops. The algorithm takes a sub-array representing each pixel and repeat them z times across, before selecting the next pixel. This would be repeated until the row was completed. This row would then be repeated z times also. Then, the next row in the original image data array would be selected and the process repeated until the image is completely processed. As the image data was one dimensional, there was no true row number. Instead the element would be: 
The mirroring process was also required so the robot would be sent to the correct coordinates and to eliminate any confusion. This process involved working with individual rows. If the pixel started at element i, the pixel would then be moved to the (width – i) position in the row.
Because there are actually three elements for each pixel, each pixel would begin at element 3i, the actual process along each row would be: 
In order to take into account the row, in a flattened array, the first element number of the row would be subtracted before manipulation and added back after manipulation. This mirroring process was completed before the enlarging process to minimise the time needed for the entire process. 2.3 TestingExamples of some tests carried out on the zooming and mirroring algorithms are shown below. Note that to save on room, each array has been broken up in rows and numbers 10-36 have been replaced by A-Z respectively. 2.3.1 Zooming x 2
2.3.2 Mirroring
2.4 Final SpecificationThe final specification is far from the original specification. Due to the original cameras failing to work and the subsequent unexpected absence of A/Prof James Trevelyan, the time to develop appropriate software was diminished. The final code used does not meet all of the functionality objectives. Instead, only a low-resolution image was captured and increased in size for testing of the overall application. 2.5 Documentation
Figure 10 This VI, created by Peter Parente, initialises the camera ready for use. The wait time at the end was increased from the original value.
Figure 11 This VI was originally created by Peter Parente and was modified to include mirroring and zooming for use within the Augmented Reality code.
Figure 12 This VI was created by Peter Parente to close down the image capturing session.
Directory: Information Information -> Management and Marketing Information -> Computer Science 101 October 13, 2016 Information -> Student athlete handbook Information -> Table of Contents Page Information -> Policies and Procedures 40 – Eligibility Information -> Procedures for Implementing and Managing the All-University Policy on Mobile Communication and Information Devices (Mobile cids) Policy University of Kansas Medical Center Information -> Policies and Procedures 40 – Eligibility Information -> Cacc director’s council may 24-25 2010 12 noon caesar’s, Atlantic City, nj Download 6.79 Mb. Share with your friends:
|