Help with a camera controlling sequence

[joshzstuff]

Hello, I'm starting a video surveillance camera project and I would really appreciate your input as to direction and methods.

Here are the details:

-The camera I am using will be activated by a Passive Infrared sensor (PIR) (or also possibly a sound detector)
-The camera must be turned on and started by the sensor, then it must be shut off in the absence of sensor feedback.

Here is how the camera operates normally:

Cam has 2 buttons, 1) ON 2) Start/Stop

- ~2sec After the "ON" button is pressed the "Start" button can be used.
- When the "Start/Stop" button is pressed again, the video will stop & Cam goes into "STANDBY" mode for 65sec
- in "STANDBY" the "Start" button will start recording, but after 65 sec the Cam auto shuts off
(and must then again be turned "ON" before the "Start" can be used.)

Below is the sequence I devised to run the Cam off the motion sensor(s):

I will need to break into the buttons to send the pulses to the camera.

I am considering 2 paths to execute this sequence:
1) Discrete components (i.e. retrigerable monostable vibrators)
2) Programing a microcontroller

This would be my first microcontroller project, but if I do go that route, it appears the Micro could be very basic.

Any suggestions will be appreciated, thanks for reading.

P.S. What line diagram programs do you use?
I did this one in a paint program and I know there has to be a better way!
Thanks.

 

[(*steve*)]

Using a microprocessor would give you a lot of flexibility without having to change component values to change timing.

As usual, my recommendation is to look a the PicAXE chips for your first project as they are very simple to program and use.

Whatever solution you use, you will need to determine how to actually trigger the camera.

For the type of diagram you've produced, the tool you've used seems fine.

There are specialised tools for circuit diagrams and PCB layouts and stuff like that, however this isn't one of those

 

[davenn]

There's probably no real reason why you cant do what you want to do.
BUT in real world video suveillance its the recording device that switches on and off for motion detection. so for an example you may have 4 cameras being controlled/monitored by the DVR (digital video recorder) and its the software on the DVR that turns the recording mode on and off within the DVR. That way the cameras are always working and cam be contineously viewed in real time regardless of if the DVR is doing a physical recording to HDD or not. Its probably a heckl of a lot easier for you to impliment that what you are planning.
You can go to hobby (etc) electronics shops and buy cards to plug into a PC along with the software package. You can display single camera full screen or multiple cameras on the screen concurrently. you can select various cameras to for eg.
record contineously, between set hrs of the day, motion detect etc etc
the systems are VERY versatile

Yet another one of my many and varied job descriptions

cheers
Dave

 

[joshzstuff]

There's probably no real reason why you cant do what you want to do.
BUT in real world video suveillance its the recording device that switches on and off for motion detection. so for an example you may have 4 cameras being controlled/monitored by the DVR (digital video recorder) and its the software on the DVR that turns the recording mode on and off within the DVR. That way the cameras are always working and cam be contineously viewed in real time regardless of if the DVR is doing a physical recording to HDD or not. Its probably a heckl of a lot easier for you to impliment that what you are planning.
You can go to hobby (etc) electronics shops and buy cards to plug into a PC along with the software package. You can display single camera full screen or multiple cameras on the screen concurrently. you can select various cameras to for eg.
record contineously, between set hrs of the day, motion detect etc etc
the systems are VERY versatile

Yet another one of my many and varied job descriptions

cheers
Dave

Thanks for your reply Dave,
I realize the advantages of purchasing a conventional surveillance solution, however for several reasons I like this route to develop myself. Plus it's a good opportunity to learn micro-controllers and other related devices!
Thanks again for the advice.

 

[joshzstuff]

Using a microprocessor would give you a lot of flexibility without having to change component values to change timing.

As usual, my recommendation is to look a the PicAXE chips for your first project as they are very simple to program and use.

Whatever solution you use, you will need to determine how to actually trigger the camera.

For the type of diagram you've produced, the tool you've used seems fine.

There are specialised tools for circuit diagrams and PCB layouts and stuff like that, however this isn't one of those

Thanks Steve,
I plan on triggering the cameras by sending a pulse to the cam buttons ether to simulate a button press, or to use a semiconductor to 'short' the button contacts.

I've decided to take your recommendation of a PicAXE controller.
I've done some research on all of the options available, and I thought it best to sink into this one rather than let my head spin on all of the info and controversy regarding controller choices!

Can you move this thread to the 'Microcontrollers' forum MOD?
or, should I start a new thread?

Thanks

 

[(*steve*)]

The good thing about using a (reprogrammable) microcontroller is that you can start simple and add features to your program as you go.

As such, I would advise you to start really simple. Perhaps just flashing a LED attached to one pin. Then change it to do whatever is required to simulate a press of a button and see if that works. Then add features as you go.

 

[joshzstuff]

The good thing about using a (reprogrammable) microcontroller is that you can start simple and add features to your program as you go.

As such, I would advise you to start really simple. Perhaps just flashing a LED attached to one pin. Then change it to do whatever is required to simulate a press of a button and see if that works. Then add features as you go.

Yep, I hear you steve, I've been working my way up to this program.
I've got the blinking lights going
I know too, it's good to do as much research and development on my own, so that I can ask good questions in the forum. I've been doing that.

I have a hunch that I may have to switch chips because of the programming though, unless I'm seeing this wrong:

I am trying to program the "re-trigger" portion of my circuit.
(This appears to be something simpler in discreet hardware than on the 'basic' micros.)
I was hoping to pull this off with a PicAXE 08M however I don't think it supports parallel processing.
I have a PicAXE 18M2 coming, and the 'M2' versions are supposed to support parallel processes.

I think I know just what to do if I can use a separate (parallel) sub-command . . . However, I would much prefer to use the smaller chip.
(I've read that I may be able to use a pwm peripheral, however I don't think I want to go that route either)

So my question is:
Does this re-trigger option for the 'wait' command require the higher chip, or does anyone know a way I can do it with the PicAXE 08M?

 

[(*steve*)]

The trick is not to use wait, or to use much smaller waits.

Let's say instead of 1 long wait, you have 1000 smaller ones. At the end of each wait you decrement a counter. But if a button is pressed, you set it back to 1000. When it hits zero, the timing loop is over.

I can't imagine it's too much for an 08M.

 

[joshzstuff]

The trick is not to use wait, or to use much smaller waits.

Let's say instead of 1 long wait, you have 1000 smaller ones. At the end of each wait you decrement a counter. But if a button is pressed, you set it back to 1000. When it hits zero, the timing loop is over.

I can't imagine it's too much for an 08M.

ahh, I see steve! Thanks!
Probably one every .5 sec should do I think, I'll have to see how sensitive the PIR sensor is.

You got me thinking, perhaps for a similar solution I could use a pulse count command lasting for .5 sec in a increment or decrement.
Might this be a possible measure against nuisance false positives from the sensor . . . ?

 

[(*steve*)]

It is best to debounce your sensor by looking for the same result several times in a row. That way a spike caused by noise won't set it off. If you check 1000 times a second you can decide how many mS the signal has to be true before you react to it.

This technique is ofen used for switch contacts tto prevent you from reacting to the multiple on/off states you can see when a switch changes from on to off or off to on. It can also be applied to other types of noisy signals.

Remember that if you scan the input only twice per second that an activation shorter than 1/2 of a second may be missed.

 

[joshzstuff]

grown out of your suggestions

Well, it took me a while to get up and running, but I completed the PicAXE program that fulfills my flow chart!
Now I'm working on something similar to what you suggested :

It is best to debounce your sensor by looking for the same result several times in a row. That way a spike caused by noise won't set it off. If you check 1000 times a second you can decide how many mS the signal has to be true before you react to it.

This technique is ofen used for switch contacts tto prevent you from reacting to the multiple on/off states you can see when a switch changes from on to off or off to on. It can also be applied to other types of noisy signals.

Remember that if you scan the input only twice per second that an activation shorter than 1/2 of a second may be missed.

Probably not exactly what you had in mind, but the PIR sensor has fairly coarse triggers, and my target is nuisance trips that are quickly cleared.

Problem:
I ran into a snag where the chip won't do what the simulator does . . . I'll explain below

Here is the basic program that corresponds to the flow sheet:

 symbol StSt = b1  	'Start/Stop button
symbol Power = b0	'Power button
symbol sensor = pin3	'PIR sensor 

let dirs = %00000011

main1:
wait 2
goto main

Main:

	if sensor = 0 then goto main
	if sensor = 1 then high Power  'turn Cam ON
	pause 300
	low Power  
	
	pause 2900
	
	high 1				'start Cam
	pause 200
	low 1
	endif 
						'Changed 'gosub' to 'goto'
	goto startagain			'STACK ERROR- > nested gosubs
	


startagain:  
for w1 = 1 to 800
  pause 10
   if sensor = 1 then startagain 
next w1 
high 1
pause 300
low 1

Standby:
for w2= 1 to 5100
		pause 10
	if sensor = 1 then high 1
	pause 300 
	low 1
	goto startagain endif    	'Changed 'gosub' to 'goto'
					  	'STACK ERROR- > nested gosubs
'	
	next w2
	
	pause 3000
	
	goto main

The new program adds some features from the old:
- It starts the cam at first run "cam priming"
- has safety 'resets' encase the cam and the picAxe & cam timing goes out of sync (sometimes temperature affects this) "heartbeat" "safety"
- I included the principal of Technical's code with an inc that determines if the PIR is tripped by a 'nuisance' signal "nuisance"
- if the 'nuisance' condition fails the recording goes to a shorter recording first "shortRec"

I tried to label the significant parts of code, sorry if it's more complex than it needs to be (but I'm open for any criticism)

(Sorry for the lengthy code, the relevant section is "CloseRec")

symbol Power = b0		'Power button
symbol StSt = b1  	'Start/Stop button
symbol Time = b2
symbol detect = b3
symbol ready = b4
symbol retrigger = b5
symbol heartbeat = b6
symbol Ncount =b7

symbol sensor = pin3	'PIR sensor 

let dirs = %00000011

							goto start 	;@sim@

main1:
wait 2				'Program delay

high 1				'diagnostic sequence
pause 200
low 1
pause 300
high 1
pause 600
low 1
wait 4

high Power				'Cam priming sequence
pause 300
low Power

pause 4500

high 1
pause 300
low 1

wait 4

high Power
pause 2000
low Power

wait 3


goto main

Main:

	high 1			'safety reset
	pause 200
	low 1

for heartbeat= 1 to 5600					
	pause 10
	
	if sensor = 1 then goto Start
	
next heartbeat 
	
	high 1			'safety reset2 (heartbeat)
	pause 200
	low 1
	goto main


Start:
	
	high Power			'power cam
	pause 200
	low power	
	
		let Ncount = 0
		let detect = 0		
for Time = 1 to 10		'nuisance prevention
	pause 350
	if sensor = 1 then inc detect endif

	if detect > 4 then inc Ncount endif 'sensitivity setting
next Time
	
	;pause 3500
	
	if Ncount > 0 then high 1	'nuisance pass
		pause 300
		low 1
		goto startagain endif
	

goto ShortVid				'nuisance fail

ShortVid:

high 1
pause 300
low 1

for retrigger = 1 to 4;00						'@sim@
 		 pause 10
 		 
   	if sensor = 1 then startagain 
next retrigger 
goto CloseRec	
	
CamStart:				'start Cam
	high 1			
	pause 200
	low 1


startagain:  
for retrigger = 1 to 8;00						'@sim@
 		 pause 10
   	if sensor = 1 then startagain 
next retrigger 

CloseRec:				'close recording
high 1			
pause 300
low 1

	pause 2550			'restart buffer
	

Standby:
for ready = 1 to 5;100 							'@sim@
		pause 10
	if sensor = 1 then high 1
		pause 300 
		low 1
	
		goto startagain endif    'Changed 'gosub' to 'goto'
					 'STACK ERROR- > nested gosubs
'	
next ready
	
	pause 3000			'restart program buffer
								goto start 	;@sim@
	goto main

The problem lies in the "CloseRec:" (or before it)
It works perfectly in the simulator, but it won't work on the chip

The camera will start, but it will never close again.

feel free to critique the code, I'm sure a stepped all over convention when programing it

 

[(*steve*)]

You appear to have made an excellent start. There are some problems with the indentation of the code, but I expect that's a cut and paste problem.

I'll try to take a look at this later today, but I'm leaving in about 8 hours for several weeks of holiday, so I may not be able to get back to you.

Does the camera work correctly when you apply voltages, etc manually?

It sounds like your problem is that the camera's lens opens up, but doesn't close down (is it one of those compact cameras with lenses that fold away flat?). Is that right?

 

[joshzstuff]

Compair with working code . . .

Hello Steve

You appear to have made an excellent start. There are some problems with the indentation of the code, but I expect that's a cut and paste problem.

Are you referring to the "goto start" toward the beginning of the program?
If so this was intentional for simulation purposes. I use a " ;@sim@ to show me what to change during simulation so as not to wait for the INC and DEC of code.

(but this gives me a new area to look into from the simulation being more successful than the chip . . .)

It sounds like your problem is that the camera's lens opens up, but doesn't close down (is it one of those compact cameras with lenses that fold away flat?). Is that right?

Think video camera.
To take video requires 3 steps
1) power the cam on (1st button) "power" [output 0]
appropriate pause
2) start the recording (2nd button) [output 1]
after desired recording time
3) close the recording (2nd button) [output 1]

*note also intervening are the re-trigger times if sensor activates or restart while cam is in standby (see original post for flow chart)

** note2 also in the code below are provision if the cam goes out of cycle with the chip to re-sync via "heartbeat" and "safety reset"

Does the camera work correctly when you apply voltages, etc manually?

Absolutely, and it's bulletproof with my original code. However I've seemed to have broken it somehow.

The tough part about debugging it is that it's NOT broke in simulation . . .?
(EDIT: I know it's in the program because I have led's to indicate my outputs and the cam works with the earlier revision of code.)

I will post the "bulletproof" working code at the end of this post.

I'll try to take a look at this later today, but I'm leaving in about 8 hours for several weeks of holiday, so I may not be able to get back to you.

Enjoy your vacation Steve!
(They would make us take our laptops over here in the states if we go away that long )

Here is the working code to compare if it helps.
You can ignore all of the stuff before Main:
I cut it out below (I should have cut out the irrelevant parts above, sorry)

symbol Power = b0		'Power button
symbol StSt = b1  	'Start/Stop button

symbol sensor = pin3	'PIR sensor 

let dirs = %00000011


Main:

	high 1			'safety reset
	pause 200
	low 1

for w3= 1 to 5600 		'heartbeat rate
		pause 10
	if sensor = 1 then goto Start
	
next w3 
	
	high 1			'safety reset2 (heartbeat)
	pause 200
	low 1
	goto main

Start:
	
	high Power			'power cam
	pause 200
	low power	

	pause 3500
	
	
CamStart:
	high 1			'start Cam
	pause 200
	low 1


startagain:  
for w1 = 1 to 800
 		 pause 10
   	if sensor = 1 then startagain 
next w1 


high 1				'close recording
pause 300
low 1

	pause 2550			'restart buffer
	

Standby:				'standby to restart
for w2= 1 to 5100
		pause 10
	if sensor = 1 then high 1
	pause 300 
	low 1
	
	goto startagain endif    'Changed 'gosub' to 'goto'
					 'STACK ERROR- > nested gosubs
'	
next w2
	
	pause 3000			'restart program buffer
	
	goto main