|
The complete system met most of the original objectives. Firstly lock-on was achieved at a distance of 1 meter. The receiver was placed within the field of view. The system was able to scan the complete area and locate the receiver, send a 6bit data word and receive an acknowledgement. The whole process took around 1.5 minutes allowing for the scan time and the slow processing speed of the computer equipment available. The program was also modified and the brightness adjusted to be able to perform lock on and transfer at a distance of 16 meters. This was much greater than the original target.
The system was also able to track a moving target using a modified version of the area scan code which just looped in the receiver tracking part of the code. Unfortunately Matlab is not a multi tasking environment, therefore it was not very straightforward to have the code track the target and pass data when needed. In C++ or C# this would be easier to achieve, one thread would be dedicated to tracking the object and the other could pass data to it as required. All the other main objectives were achieved, building and integrating the parts to the complete system.
One area which didn’t work as well as was hoped was the IR communication. During testing is was discovered a large amount of devices interfere with the receiver. This interference causes the receiver to think it has received something when it has not. All the errors encountered however could be corrected by developing the communications protocol further and possible implementing a different one. It should be said that IR is still a good choice over lasers as it offers the possibility of quicker scanning and also cheaper implementation, both of which could be important if the technique is to be used commercially.
The methods chosen generally worked extremely well and should be considered in future development. The one area that created the most problems was the image processing side, mainly because it was so dependant of processing speed of the PC and also partly due to the lack of time left towards then end of the project. One definite alteration that would resolve this is to either use a dedicated image processor, either by creating one for a FPGA, or making use of an off the shelf one such as the Wii’s image sensor.
The project was a great success, with most of the original objectives being met, and also exceeding an objective. Several issues were identified and are listed in the following sections. There is also plenty of scope for follow on work, both by developing the system discussed in this report and also making alterations and considering other options.
Several major problems occurred along the way. The biggest was perhaps the issues with getting the laser communication to work. This was planned from though from an early stage, and when it became an issue, it was possible to switch to using the IR techniques in place of the laser. In hindsight more time should’ve been spent on developing the laser communication link. The problems here were centred on modulating the laser since its characteristics were unknown and also due to the extremely small beam size.
Once the method was switched to IR, the major problem which kept occurring was interference. This was narrowed down to the source of the laptops in the room. The result of the interference was that the receiver kept resetting and data that had been received successfully was overwritten with incorrect data.
It was also found that the speed which Matlab captures frames was fairly slow, only being able to capture around 15 a second. Possible solutions to this would be to capture a batch of frames and then post-process, or implement a real time controller on a FPGA or dedicated image processor.
Much of the other problems experienced were typically programming errors possibly caused by inefficient code, inaccurate delays or the wrong algorithm.
One of the key limiting factors of this project is the reliance on the host PC performing some of the calculations. Initially it was attempted to have the processing done on the controller and only have the host issue commands, e.g. find receiver. This means the host PC must have Matlab installed. The program also requires to be run each time data is needing sent. It should really just run and keep the link active and when data needs to be sent, transmit it.
Another major limitation is the low data rate of the communications link. A commercial modulation scheme was chosen to implement since development time was limited. Since the project was only intended to transmit small chunks of data, this was fine. For a faster speed link a different modulation technique should be used, perhaps simply extending the length of the RC5 message.
There are still plenty of areas in this project suitable for future work. One of the main would be to get the laser communications channel working. This could be as simple as swapping the IR transmitter for the laser and building a receiver and modulator.
Another key area for development would be to switch the image processing to hardware. Due to the limitations of Matlab and PC processing speeds, the software would function much better if ported to a FPGA. The software could also be ported to a language like C++ or C# with support for threading. One thread could be dedicated to the communications link, sending data when required. The other thread would maintain the link, moving the transmitter and always keep it in line.
Following on from this a possible development could be to use the image processing chip from the Wii remote control. The chip has an I2C connection meaning it could be implemented into the system by simply reading the LED co-ordinate values straight off the chip.
Aside from these, since so much of the software used was new and designed for this project, much of it is still buggy. In order to improve the reliability and success rate of this project, these small errors should be corrected. There is plenty of small alterations discussed throughout the development sections which could be made.
The pan and tilt head could also be improved. Currently its field of view is limited as the servos used only move 90˚, it is possible to get servos that move 180˚ possible with reduced resolution. A possible alteration would be to use a stepper motor for the pan as this would give complete 360˚ rotation allowing it to locate a receiver in any direction. A good alteration would be to having the receiver transmit some sort of identifier or address so the transmitter could scan a large area with a number of receivers, and be able to pick out the specific receiver required.
|
Publications
