Searching \ for '[PIC]: Video Motion Detection on a PIC?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/displays.htm?key=video
Search entire site for: 'Video Motion Detection on a PIC?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Video Motion Detection on a PIC?'
2002\06\11@125551 by Hazelwood Lyle

flavicon
face
Hi All,
I have watched many topics through this list, and
I'm often amazed at what people are doing with PIC's.

I have wondered more than once if a PIC could be
used for video signal motion detection. I assume
that a sync separator and NTSC(or PAL) to RGB conversion
would be handled by dedicated chips, but could
a PIC go from the resulting RGB signals to
some kind of motion detector output?

I understand that this is most often done in
PC's by keeping a copy of the previous video frame,
and comparing it to the current frame. Blanking
of certain areas and an overall sensitivity
adjustment are also useful. Obviously, a bare
PIC could not buffer a full video frame. It is
also unlikely that you could resolve all the
information in a current frame at the full speed
of the incoming signal.

Some method of mathematically "hashing" the video
as it streams into the PIC, even if only every
2nd, 3rd, or 4th pixel is sampled, might provide enough info for the program to detect change.

Of course, a certain amount of background noise
may be present, even on a "dark" signal, so some
sensitivity adjustment will be needed.

This is all just wild ideas at the moment. Has
anyone else ever considered something like this?

Thanks,
Lyle Hazelwood

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\06\11@131315 by mike

flavicon
face
I don't think there would be a sensible way of hashing the video data,
but if you had an external one-frame delay, you could probably do
something pretty useful by looking at the sum of the differences
between current and delayed data on a byte-by-byte basis. This would
greatly simplify the buffer RAM addressing - you'd only need a counter
and a pretty simple read-old/write-new  scheme. In addition to the RAM
for the frame delay, you'd probably need an FPGA,  but not a
particularly big one. You might just be able to get the PIC to handle
some or all of the summing and masking, and some of the control &
timing though.
On Tue, 11 Jun 2002 12:51:35 -0400, you wrote:

{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\06\11@173643 by M. Adam Davis

flavicon
face
It wouldn't be too hard to pick 16 or more points on the video image and
watch them (store their value in a register), waiting for a large sudden
change.

You would need either an external ADC or sampler, as the internal ADCs
do not have the bandwidth to test less than several pixels of information.

Alternately you can use an external opamp configured as an integrator.
Reset the integrator at the beginning of each line, then use the
internal ADC to get its value during the retrace or next line.  You can
get any particular line you wanted, and could make it more complex by
choosing areas of the screen (lower right quarter screen, etc)

The system would likely not be as accurate as a full-frame algorithm
(some of which are very complex), and wouldn't take into account color,
but it would certianly be useful for a great many things.  You could
make a killing selling little camera add on boards that would turn VCRs
on when movement is detected - the device could reside near the VCR and
use IR to start and stop reording, or reside near the camera and send
low frequency IR signals over the video coax to the vcr.  Shouldn't be
too much more work to add a date/time stamp to the outgoing video as well...

Probably would want to go with the 18f devices for the extra speed and
flexibility.  Designing such tight timing code inside a slower PIC is
only fun for the first few minutes...

-Adam

Hazelwood Lyle wrote:

{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\06\11@174312 by Peter L. Peres

picon face
Implement a sample & hold with the sample keyed by H and V sync related
windows, then digitize the signal (using PIC ADC). On the next frame
compare this to what you stored previously. The S&H does the 'hashing' in
the form of integration. You could add a peak or through detector before
it do detect dark or light objects better.

The simplest such thing uses a photodiode in a black vacuum suction cup
stuck to a monitor screen and a window comparator to detect changes.

Peter

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\06\12@024402 by Andrei B.

picon face
One other way is go even lower with the integrator.

Build an integrator that will integrate an entire frame and then watch
it's output.  It is the simplest one possible, but with lower
sensitivity.

I've seen such a motion detector done with transistors only.

=====
ing. Andrei Boros
Centrul pt. Tehnologia Informatiei
Societatea Romana de Radiodifuziune

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\06\12@044647 by Alan B. Pearce

face picon face
I guess if you wish to have a window area detector you could have two video
ram buffers, one storing a digitised image to be used as a reference, and
the other being actively filled with digitised video from a camera. A PIC
could then be reading out the digitised values from both buffers and
comparing them. If two port ram is used then the video store operation will
not affect the PIC readout operation.

The PIC could then keep track of which parts of the image are inside the
desired detection window, and look only at those ram locations.

It may be possible to dispense with the active video buffer and have a
digital comparator comparing the incoming digitised video with the
appropriate ram location in the reference buffer, and signal the PIC if they
are different by more than say 2 bits to allow for noise. The PIC could then
select the window by timing from the sync pulses, and if the difference
signal occurred inside the window area then raise suitable alarm signals or
whatever.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\06\14@094713 by Roman Black

flavicon
face
Hazelwood Lyle wrote:
>
> Hi All,
> I have watched many topics through this list, and
> I'm often amazed at what people are doing with PIC's.
>
> I have wondered more than once if a PIC could be
> used for video signal motion detection. I assume
> that a sync separator and NTSC(or PAL) to RGB conversion
> would be handled by dedicated chips, but could
> a PIC go from the resulting RGB signals to
> some kind of motion detector output?
>
> I understand that this is most often done in
> PC's by keeping a copy of the previous video frame,


Even doing this with minimum speed PIC and very little
ram is possible, average the video per line into an
RC filter, then into the PIC analogue input and do one
sample per video line. You only need one ram unit per
line, or less if you share the ram and do some lines
each frame. I also suggest turning the camera 90'
(sideways) so movement (walking for instance) is from
one line to the next rather than across a line.
Seems like a very do-able proposition for a cheap
camera and any analogue PIC. :o)
-Roman

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2002\06\14@114355 by John Waters

picon face
>Hazelwood Lyle wrote:
>
>Hi All,
>I have watched many topics through this list, and
>I'm often amazed at what people are doing with PIC's.
>
>I have wondered more than once if a PIC could be
>used for video signal motion detection. I assume
>that a sync separator and NTSC(or PAL) to RGB conversion
>would be handled by dedicated chips, but could
>a PIC go from the resulting RGB signals to
>some kind of motion detector output?
>
>I understand that this is most often done in
>PC's by keeping a copy of the previous video frame,
>

I've done something similar before using a PC with a frame grabber card. I
used my system to detect motion of objects outdoor, the project was not very
successful because the system was easily influenced by changes in
environment, e.g sun light intensity changes (a cloud blocked the sun), the
wind blew and made the leaves of a tree suddenly move, the object passed the
camera too fast, two objects passed the camera together and recognised as a
single one, the color of the object too close to background and get hidden,
shadow of the object recognised as another object, etc...  My conclusion
was, I could only use my system indoor under a well controlled environment,
e.g. just detecting passing objects through an narrow entrance, but this can
easily be done by any conventional motion sensor, there is no point to use a
camera. Anybody get comments?


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...