Augmented Reality Control of the Telerobot 2003
Download 6.79 Mb.
|
- Navigate this page:
- Module 1: Image Capture Hardware and Setup
- 1.2 Implementation
- 1.3 Final Specification
Functional Block Diagram
Figure 6 Module 1: Image Capture Hardware and Setup1.1 Initial SpecificationThe Augmented Reality interface is based upon captured images that are up to date and as such, would require images that are captured on request. This image would be of the whole grid, such that all corners can be seen. The image would then be saved for sending over the Internet, which would be implemented in the future. This required that images would be captured through the use of the Matrox Meteor II frame-grabber and the Pulnix TM-6CN cameras currently setup on stands around the robot. The cameras would also be setup around the grid as shown below. 
Figure 7 Details of the original equipment are given below. T  he Pulnix TM-6CN captured high quality images and was designed for use in high precision applications.
T  he Matrox Meteor II is a low-cost frame-grabber that supports multiple cameras. A Matrox Imaging Library was provided at cost for use in programming such that image capture could be done to the specifications required by the program. While old, it could still meet the requirements of modern day applications.
1.2 ImplementationAfter extensive searching, the documentation for using the Matrox Imaging Library was found. Unfortunately, the cameras were old, and were subject to disrepair before any programming could begin. As a result, acquiring additional image capturing hardware and connections between the hardware and computer was required for image capture. One of the options considered was repairing the current cameras. However, these cameras were extremely costly to repair or replace. Prices for these cameras were around $1000. These cameras also interfaced with the computer through the use of a frame-grabber, the Matrox Meteor II. The Meteor II itself had little support for use in LabVIEW. Capturing an image would require the use of calling on its dll file. While there was code available for the Meteor II in LabVIEW, this would cost about €6353 after delivery costs. Furthermore, the images to be captured needed to take minimal disk space to minimise traffic when sent over the Internet. This meant captured images of such high quality were not necessary as images would need to be downsized for Internet transfer. This, combined with the disadvantages of the current camera, lead to the conclusion that it was time to overhaul the current image capture setup. The alternative of the use of the current analogue cameras was the use of more modern digital web-cameras. There were three interface connection types available - parallel, network and USB. However, while web-cameras with parallel connection interfaces did exist, these could no longer be purchased and were no longer supported by their manufacturers. Network interface cameras such as those by Axis Communications were also available but would cost in excess of $1000. Modern web-cameras interfaced with the computer through a USB connection. This would require a new server as the current server lacked a USB connection. However, given the cost of network cameras and lack of support for parallel cameras, the most feasible option was to use a USB camera. Given the need for quality and support for the camera, it was decided to focus on the larger companies that produce web-cameras. These were Creative Labs and Logitech. A basic comparison between their suitable cameras is shown below.
I  t was decided that the Logitech QuickCam Pro 4000 would be the camera used. This camera allowed for high-resolution images to be captured. While the Logitech cameras cost significantly more than the Creative cameras, the Logitech cameras made use of Charged Couple Device (CCD) sensors. While more expensive and demanding more power than Complementary Metal Oxide Semiconductor (CMOS), CCD sensors produce much higher quality images, as the sensors have greater fidelity and light sensitivity. CMOS sensors are also more vulnerable to noise.
Another reason behind choosing the QuickCam Pro 4000 was that Logitech provided a Software Development Kit. Other methods of capturing images, such as through Microsoft Video for Windows, would support use of a single camera only. Furthermore, it was thought at the time that this would make it easier to produce software that would meet the objectives stated earlier. Unfortunately, Logitech had discontinued support of the SDK before the QuickCam Pro 4000 was released without any notice on their developer website. The QuickCam Pro 4000 also uses a different low-level interface protocol that makes the SDK incompatible with the camera. As a result a different approach was required for the software component of image capturing. This will be discussed further in module 2, Image Capture Software. After obtaining a series of quotes from various computer and electrical stores, it was found that Computer Cash and Carry supplied the cheapest cameras at $189 each. Harris Technology supplied the cheapest extension cables at $9 for a 5m cable. However, none of these suppliers had stock of the respective items. While work could be completed without the cables, the cameras were required immediately. As such, the cameras were bought from Trinix Computers, based in Welshpool. Due to the flexibility of the camera calibration module, it was not required that the camera remain in a certain position and orientation. However, it was preferred that the cameras be attached to the current camera platforms to minimise how often calibration must be done. The camera itself lacked an area suitable to clamp to the camera platform. The stand with which the camera was the only suitable part that could be attached to the platform without opening/reshaping the camera itself. This stand is not rigid and the camera is free to move about the stand. Even the platform is free to move. This should not pose a problem as the setup is surrounded by a light curtain and would not be entered frequently. Should the cameras be moved out of position, it would be a matter of positioning it correctly such that the grid was in full view and the image would be recalibrated. In order to avoid damage to the case of the camera, it was decided that the stand be attached to the platform using wire ties. The cables were also another issue that needed to be resolved. With the current position of the server, it was found that approximately 25m of extension cables would be required to connect the cameras to the server. Only after the cables were ordered was it found that the USB cables are limited to 5m without the use of a repeater. Repeaters are integrated within some cables but for the current cables, a hub would be necessary to allow for daisy chaining of the cables to the current camera positions. 1.3 Final SpecificationThrough a series of unexpected events, this module was more involving than originally planned. A single camera is currently setup and could be connected to a computer closer to the robot area. The other camera remains in storage as limitations of the current software allow for only one camera to be used. A more permanent setup involving the cameras is recommended and repeaters will be required to connect the cameras to the robot server computer. 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:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
