ArduCam and libcamera

@davee @emeyeraway @byron I think the attached pdf will help. The pulsed operation is normal for one of the two modes of operation called triggering or non-triggering. Within that is timings set by a couple of pots or possibly onboard circuit changes for older boards. I don't see how it gets to 60 seconds, but my foggy memory tells me one of my houses had these kinds of intrusion sensors and they pulsed a red led at about the same frequency so I am inclined to think it is normal.

Maybe look into radar sensors(RCWL0516), I have one working at about 15 ft through a wooden kitchen cabinet.

@davee His first post shows two sketches, the only difference in the 2nd is the addition of the --qt-preview option to the libcamera-jpeg command and of course going headless.

Hi Ron @zander + @emeyeraway @byron,

 Re: The pulsed operation is normal for one of the two modes of operation called triggering or non-triggering. etc ....

Thanks Ron for being a little more precise about the actual operation modes ... this supports what I have been pointing out through several posts. (The reference you have posted is the same Adafruit one we have both been referring to through much of this thread.)

Namely, it is possible to set the PIR sensor up to produce some kind of pulsing output, regardless of what the sensor is actually 'seeing'. Whilst it is in this mode, it is useless as a simple 'something moved' camera trigger. Hence, if it is to be used as this type of camera trigger, it must be adjusted to be in a mode that only gives a pulse when a moving object is detected .. not because of a timer function.

I haven't carefully studied the Adafruit notes, which at first glance seemed a bit confusing, but I would hope that someone with the actual unit in front of them could make sense of them and adjust their unit to give the required function.

Only after that has been achieved, is it worth even mentioning the microcontroller (Pico, RPi or whatever), camera and associated software.

So far as I can see the discussion about different software sketches and different microcontroller boards, etc.  is only adding noise and confusion at this stage - I have suggested that the PIR board settings may have changed between the first experience and subsequent experiences, but that is only insignificant speculation - the only thing that matters is the PIR board is useless in its present timer based pulsing condition, and it needs to be adjusted/modified to give the required function.

If it is not possible to adjust/modify it to give achieve the required function, then obviously a different sensor would be the only practical way forward, although I hope this is not necessary.

Best wishes all, Dave

@davee @zander @emeyeraway

I give the excuse of coming to this thread late in the day and did not read all the many previous posts properly. (ok a rather lame excuse)

I see the op said 

but after going headless and then returning to exactly the same initial conditions, the code now takes a picture every 60 seconds in the complete absence of motion! 

Which I now take to mean the original code also works no more.  So the PIR is probably knackered.  But I don't think the op has actually confirmed the PIR in use is the one Ron suggested.  I see there is also a much smaller 50cent variant on ali express without all those adjustments.   Whatever,  the PIR is in the dock, the jury will soon return its verdict and the sentence will be pronounced.  For PIR,s a death sentence has not been abolished.

@byron AFAIK according to his original post, he has the full-featured sensor although it is not the same as what Bill tested. Also, he posted the two sketches he used, the first (according to him) works, but the second does not. The only difference is the second has the preview option added to the libcamera command and is running on a headless Pi. The OP's claim is that the 'headless' operation is causing the sensor to fire constantly.

The reality as proven by the OP is that the sensor is constantly cycling as confirmed by a VOM on a standalone powered sensor, no Pi involved. As noted elsewhere this is normal operation for the sensor but influenced by the setting of one jumper and the setting of 2 pots.

The mystery is why does that NOT happen when not headless, is there some kind of blocking happening in python?

He needs to move the jumper to the H position which will at least reduce the number of state changes but may still not be what he wants.

@emeyeraway  

This post is probably not much related to your PIR issue, but as I have not played with my old rpi cameras since the good old raspian days I thought it was time to have a play with the rpi os and libcamera stuff especially as I currently have a rpi3 (with an rpi screen) on my desk I've been playing with and also have an old rpi camera taped to a stand alongside my desk.

I'm not sure if my camera is a V1 or V2 as its tucked in a small box I 3d printed (like a mini old box brownie) that also contains a camera ribbon to htmi connector and its all rather tightly packed in.  (The connector  facilitates using an htmi cable to connect up to the camera port on the pi via a similar connector at that end)  Anyway, after the usual flaffing about I got a far as getting it up an running with the libcamera command line, with a nice preview screen.   

This also worked on virtual screen via VNC connection.  Interestingly screen:0 that mirrors the rpi directly connect screen worked with the  ' libcamera-hello -t 0 '  put into the Terminal.  However when I used it on a VNC screen:1 that command would not work, but it did work OK with the ' libcamera-hello -t 0 --qt-preview ' command.  Also to take a picture on the screen:1 I had to use the ' libcamera-jpeg --qt -o test.jpg ' command (note the extra --qt)

I failed miserably with a sample program grabbed from the picamera2 github, but I've no more time to play with this new libcamera stuff yet, but I'm please to get some of the preliminary steps done.  

@byron @emeyeraway Thanks for trying, I also was going to give it a try but the steps required to get my Pi setup were a small learning curve on its own, plus I don't know if I have the right camera. In any case, it's all a bit of a smoke screen as we know that with the jumper in the L position that the trigger pin will cycle on and off at a frequency determined by the pot as long as there is any motion. AFAIK the device is working correctly, the only mystery is why did it not act the same way when NOT headless.

I don't know for sure how the Python statement

if GPIO.input(17):

works, but if it is triggered by a change from low to high ONE TIME (i.e. rising edge) then with the jumper in the L position and the pot set to 60 seconds, the behaviour in case 2 is as expected. Why it didn't do that for case 1 is a mystery to me. 

Now at least the OP knows to move the jumper to H, all that remains is to write code that responds to just the rising edge IF he only wants one picture per new movement. I can't test that as I don't know Python at all and have no idea how to test his sketches.

Another option is to set the jumper in the L position and set the duration pot to a much smaller value so a picture is taken every x seconds while there is motion. 

The following documentation explains how to make the adjustments for TX (a pot) and TI (soldering) not worth soldering I think, just adjust TX.

https://learn.adafruit.com/pir-passive-infrared-proximity-motion-sensor/testing-a-pir

In summary, position H will take one picture and as long as motion continues, no more, while position L will take a picture every x seconds as long as there is motion detected and x is set by the TX pot.

Posted by: @zander

↑

I don't know for sure how the Python statement

if GPIO.input(17):

works,

Yes that works, digital gpio pins return 0 for low and 1 for high (or 0 for False and 1 for True) so you would read that statement as 'if the pin reads high (or near 3.3volts) then do the indented statements that follow beneath. 

But our OP might like to look at the command

os.system("libcamera-jpeg -o "+timestamp[6:15]+".jpg --vflip --hflip") 

to be sure at to where the file is being created as I think the file name should be a fully qualified path such as /home/pi/filename.jpg

@byron Sorry, that isn't what I meant. Is the statement true WHILE the pin is high, so it could take dozens or more pictures while the sensor pin was high, or is it only true once for the transition from low to high? In other words, is it the state HIGH or LOW or is it the transition as in edge rising for instance? I am guessing it is only true for a transition from low to high otherwise it would be constantly true as long as the sensor stayed high which this one does.

No idea re path name, I assume the OP knows.

@zander  

The 'while True:' is the equivalent of the 'void loop() { }' in Arduino, an infinite loop.  So the program continually checks if the pin17 is high at that moment in time, and if so takes a picture and writes the jpg file to disk(and I dont know for how long this process will take), but if the pin is not high it sleeps for 3 seconds.

I don't know how long a motion sensor keeps its signal output high for, but clearly if its less than 3 seconds then the signal to take a picture could be lost.

It would be better to use an interrupt handler instead of continually polling the pin with a blocking wait time  for this scenario.  Also using the 'import RPi.GPIO' for the rpi has been superseded with the gpiozero library with makes this task easy.  From the gpiozero docs just do:

from gpiozero import MotionSensor
pir = MotionSensor(17)
pir.wait_for_motion()
print("Motion detected!")

then do the take picture stuff.

Consideration will need to be given as to how many pic's to take when motion is detected.  If pic's are being taken of a bird table with a pile of fresh birdy food for example, there could be continued motion detected for quite a while which, if not catered for, could fill up the SD card with snapshots rather quickly.

@byron I figured that was what while true did. My question was if the 'if GPIO.input(17):' was edge-triggered, or while HIGH or perhaps even an internally maintained state of change. However, your disclosure of a different/new/better approach using gpiozero sounds like the ticket.

The setting of the L/H jumper in conjunction with setting the TX and possibly TI settings will determine how many pictures are taken.

I am working on building a handful of game cameras so these discussions are of great interest to me personally.  I may even be tempted to use Python especially if I can get Python working on the Banana Pi Zero competitor cards.

Can you send me a PM on where you saw the info re gpiozero and especially the wait_for_motion info. Your assistance is much appreciated.

@zander 

I think I see what you are asking.  Checking if a gpio pin is True or False is not edge triggered as such, it just depends on what the pin voltage is at the very moment the check is made.  If the voltage is between 1.8 and 3.3 volts its high and below 1.8v its low

Links to various docs on python on rpi gpio libraries are: (I give them here instead of PM as it may be relevant to the OP, though apologies for branching a bit off topic.)

https://gpiozero.readthedocs.io/en/stable/
https://abyz.me.uk/rpi/pigpio/
https://pythonhosted.org/RPIO/

Not at all sure if those libraries will work with your banana thingy.  Doubtless is runs python but will it use rpi libraries, very doubtful.  But for a field camera how about controlling it with  a cheapie rpi pico.  You could put your pico in a Cytron Maker board for easy use of a SD card for picture storage and if is was a picoW in wifi range you could send a snapshot to your mac. 

https://thepihut.com/products/maker-pi-pico-base-without-pico

However I rather think you may well be rolling your own Interrupt Service Routines in C on a pico but heck, in case you get tempted to python, I give you a micropython snippet for your pico based field camera (will be slightly different for a rpi4 and python).

(a link to some info on linking a camera to the pico can be seen here: https://how2electronics.com/interfacing-5mp-spi-camera-with-raspberry-pi-pico/)

The snippet:

from machine import Pin
motion_signal = False

motion_pin = Pin(17, Pin.IN, Pin.PULL_DOWN)

def my_ISR():
	global motion_signal
	motion_signal = True

motion_pin.irq(handler=my_ISR, trigger=Pin.IRQ_FALLING)

def take_picture():
	# code to take picture...
        # code to save pic to SD card

while True:
	if motion_signal == True:
		motion_signal = False
		take_picture()

@byron That is what I was thinking, the test for that pin will return true every pass thru the loop that the pin is high. Since the time it's high can be extremely long depending on the jumper and setting of TX some sort of fine-tuning of the jumper, TX and TI settings are needed PLUS some sort of state machine type logic. The simplistic explanation is to turn it into a rising edge detector and ONLY take one picture then. UNLESS the end user wants a few hundred or more pictures in a short time frame. It's up to the user to add logic to the raw detector to create the app they want with the characteristics they want.

I have a couple of the Cytron Maker boards but they are too big for the camera. So far I have not found a camera that is similar in price to a Pi V2 or even cheaper is the esp32 cam boards. The problem with the esp32 boards is it's a very primitive 2MP camera whereas the cheapest Pi is 5MP with additional choices of 8MP and 12MP plus the 'pro' cameras. Then, of course, you have the Arducam lineup but they are more expensive although great cameras.

These cameras will be located in an area with no cell or wifi other than the AP on the board which is only a few yards. The cameras will be in the bush, perhaps a few hours drive by UTV from my apartment and many miles beyond any RF emissions of any sort, so gathering the pictures involves opening the case and exchanging the TF cards.

It is unlikely I will use a PIR since outdoor motion is fairly constant, but the same sort of issues exist with a radar detector like the RCWL0516 but even that sensor will be affected by leaves blowing in the wind. I was hoping the PIR sensor was more of an IR detector, but after doing some research on this question now see it is motion-based. I think there is a raw IR detector, I just need to find it.

No need for an ISR, the code is only involved with taking the picture when it 'knows' there is something in range. 

@byron 

The suggestion about gpiozero is new and interesting to me.  I have put together a simple setup that uses my sensor to light up an LED.  However, I cannot find anything in gpiozero documentation that tells me how to take a picture with my camera using gpiozero.  It looks like all I can do is send 3.3v out from another pin separate from pin 17.  In your initial suggestion re gpiozero you say “then do the take picture stuff,” but that is exactly what I don’t know how to do in gpiozero.  Can you help me do that?  

@emeyeraway 

The gpiozero library is just for controlling the gpio pins.  In your scenario its a good lib to use when attaching your motion sensor (or buttons, LED's etc) to a pin.   You will need to use the libcamera to control the camera.  To use libcamera in a python program properly without trying to use command line statements to control the camera you will need to have a look at the raspberry pi picamera2 examples.  

https://github.com/raspberrypi/picamera2

As I mentioned previously I had a play with getting my rpi camera working with a rpi3 I happens to have to hand and got the preliminaries working.   Like you I would want to use the rpi with a camera headless and I found the libcamera2 would work OK with VNC on my mac, but only with the screen :0  but, with what I think are called VNC virtual screens - screen:1 etc, the libcamera would not work. (also it would not work with my Microsoft Remote Desktop connection).  

But ok, it works with VNC screen:0 but that VNC screen was coming up in 640 x 400 resolution as it always has, but its no good for looking at some of the example programs for picamera2.  I was running an example program that showed to output of the camera, and I presume there are some on screen buttons to click to take a picture, but they were off screen and I could not see them.  Up to now this screen resolution has not been a problem, I just created a VNC screen:1 with a higher resolution and all was good.  

After a bit of research I found the way to get VNC screen:0 running on a higher resolution OK, but decided to transfer the setting up and testing of my camera, the libcamera and the picamera2 stuff to a rpi4 as its much better (much faster) for using a rpi headless with VNC etc.

I need to get an htmi port rigged up to a the camera ribbon connector so as to use my rpi camera with the rpi4. (this was already done on the rpi3).  I've found the necessary in my parts drawers and just before I read your email I had finished a small 3d printed tray on which to mount it.

The libcamera and picamera2 is all new to me (I've not played with the rpi camera since the raspian days) but I will be getting something up and running quite soon.  I'm rather liking the libcamera  and playing with picamera2 so I expect if you need some further assistance I will have some working examples in a week or 2.

In the meanwhile please can you give feedback on the issues and suggestions you received regarding your motion sensor.  I'm intrigued to know if your every 60 second pin high malarky has been sorted.