QUOTE (tedstryk @ Jan 7 2005, 05:07 PM)
It seems quite difficult to imagine a rover picking such things out automatically. It took much processing of the Pathfinder images before dust devils were identified.
Actually, it's easier than you think.
It's Mathematics 101.
(1) Verify rover is stationary (otherwise, don't bother executing motion detect)
(2) Verify camera is stationary (otherwise, don't bother executing motion detect)
(3) Snap picture X
(4) Snap picture X+1 about 0.25 seconds later. (Or you could even do 1 second intervals)
(5) Do simple mathematics of subtracting the corresponding pixels of image X+1 from X
(Optimization: Do this only for every Nth pixel horizontally and vertically, say every 4 or 8 pixels.)
(6) Total up all the differences between the corresponding pixel values between image X+1 from X, from the above step.
(7) If this numeric total SPIKES (either positive or negative bias).... there's motion! Start recording immediately.
(8) If numeric total is pretty close to 0, keep repeating steps 1-7.
With the suggested optimization included, this is easily doable on a slow 10 megahertz radiation-hardened processor, even for 2 megapixel images, processed every 0.25ms, using simplified assembly language. And this still leaves plenty of CPU overhead.
If the motion-detect performance optimization is included, it may miss dust devils smaller than 4 pixels across, but it will catch dust devils bigger than that. (Adjust performance optimizations to suit the needs of the down-clocked radiation-hardened CPU used.)
Noise will affect results, but noise can be measured in advance, and be used as a cutoff value, between motion versus no-motion. (i.e. how far away from zero, before motion is declared and video is automatically recorded)
Memory will definitely need to be big enough to hold two uncompressed images, for doing mathematics with at sufficiently realtime speeds.
MER had more powerful processors than 10Mhz, as I understand it (20 MIPS). Plus, memory was most certainly big enough (Something like 128MB). So assuming MSL has better specs, it is well positioned to almost certainly include automatic motion detection software. Even at its slow speeds, MER definitely has a CPU and RAM powerful enough to do motion detection -- if it weren't for the very slow pancam frame capture rate.
Checking every 4th pixel of a 2 megapixel image (4-step horizontally and vertically) only checks 1/16th of the pixels. You'd only need to watch a scant 90,000 pixels of a 2 megapixel image, to detect motion of objects bigger than 4 pixels. (Variables do apply here like noise, how faint the object is, so the object may need to be bigger to compensate for the faintness and still be above noise threshold, but you engineers get the idea of what I am talking about).
At approximately only 5 instructions per pixel (pixel load from X, pixel load from X+1, subtract the two, add result to an accumulator, increment pixel counter to load from next pixel), required for motion-detection mathematics, that's only 450,000 instructions. Plus a few instructions for end-of-row loop counter, and finally the cutoff value check. Let's be generous and throw in a crazy codebloat of 300%, by programming it in C++ instead of assembly, or waitstates caused by radiation-hardened ECC-type memory, etc. That's 2,000,000 instructions. A 20,000,000 instructions-per-second CPU can easily do the math, the same CPU used in the MER's. (At 0.25 seconds, you've got time to execute 5,000,000 instructions.) You can easily see where I am getting at, the MER hardware have specs capable of doing motion detection - if the cameras were able to capture fast enough.
Experimentation will be needed -- you may need to poll the image at different intervals such as -- every 1 second instead of 0.25 second, because the dust devils may not have moved much in 0.25 seconds. This makes it an even easier load on a CPU -- you'd only need to execute 450,000 instructions once a second -- a CPU load of less than 3%. (Or less than 12% for the 'bloated-code' version). In fact, there might even be enough CPU left to execute simultaneous motion detection algorithms for slow and fast moving objects, so that recording begins more quickly for fast moving objects, but still being able to detect slow moving objects or fainter objects.Motion detection ain't rocket science -- even a high school graduate can do it.
Heck, even I can do it -- and there's no doubt the professional engineers will definitely do motion detection in MSL. It'd be stupid not to inlcude it, if you've got cameras capable of doing 10fps!
I programmed for an open-source realtime image video processor, at www.dscaler.org
so I can vouch for what I am saying here. I'm listed in the 'Authors' credits. Go check it out.