This is more of a note to self than anything else:
Using FFT's, and also assuming that as there is motion in the visual field of our robot;
As blobs move relative to each other, there will be a point of interference where once occludes another. These points can be used to determine the edges of the blobs more accurately than a simple color based edge detection scheme, since the pattern behind the occlusion edge will be more dynamic that the other edges.
Removing the motion component:
Added to this, we can detect the fundamental frequencies on the surface of a blob. These frequencies could then be used to generate a new bitmap that contains the characteristic frequencies of the different areas of the bitmap, and may be able to better detect the boundaries of objects than using these simple color based techniques. Sudden transitions from one frequency to the other should be easily detectable because of the sudden change in the characteristic frequency. Slopes in 3-space should also be easy to detect based on the Gradual shift of the frequency of an object.
Another idea:
What if the frequency map is in fact a pair of frequency maps, where one is the actual fundamental, and the second is composed of RELATIVE frequencies, meaning that the harmonics are analysed, and the relations of the frequencies to each other determine wether they are the same object. To use a musical analogy, you can slide a minor fifth chord up the scale slowly, but it is still clearly a minor fifth. This way, slopes of an object could be determined to likely be parts of the same object, despite occlusion/discontinuities in the target image. This map would need to have a way of mapping these relationships in a manner that is not storage space intensive. Perhaps a stack of harmonic #'s paired with their relative amplitudes, and a limit on the number recorded harmonics (8 maybe?)
As yet another idea, we could use 2D FFT to determine velocities of target objects, and their actual distances based on the scale of their patterns.
All of this would need to be implemented in an FPGA of course, but that is not the kind of obstacle that it used to be.
Posted by Enki at October 14, 2004 12:32 PM | TrackBack