Notifications
Clear all
Topic starter
2023-02-14 11:17 pm
I started with a new Raspi 3B+ (hostname Raspi6) and an ArduCam 16MP Autofocus camera. I used rpi-imager to put Raspian OS on a 32GB SD, and enabled ssh, VNC Server, I2C, GLAMOR and GL(Full KMS). I installed Filezilla, VNC Viewer and idle3.
With Raspi6 connected directly to my monitor I followed the instructions in the dronebotworkshop video “Raspberry Pi Autofocus Camera and libcamera.” Afterwards libcamera-hello worked as expected.
I wanted to incorporate a motion detector to take pictures. I set up a HC-SR312 AM312 sensor between 5v and GND and connected the output lead to pin 17 in Raspi6.
Using the code: “camera_motion_Raspi6.py” (below) and running from the terminal everything worked as expected: a picture was taken every time I moved near the sensor,but not when there was no motion.
Then I wanted to run Raspi6 headless, which required a minor change in the code (Addition of "--qt-preview" in front of "--vflip"). I connected a Raspi 3B+ to my monitor and entered “ssh -X @192.168.1.123">pi@192.168.1.123” to connect with Raspi6, and ran this code from the terminal.
This time a picture was taken within a minute of starting the code, and another picture was taken exactly 60 seconds later, and every 60 seconds thereafter. All with absolutely no motion near the sensor.
I shut everything down and connected Raspi6 directly to the monitor, exactly as previously, and ran “camera_motion_Raspi6.py” again. This time it behaved like when it was run headless: a picture was taken every 60 seconds with no motion near the sensor.
I have not been able to escape this “every 60 seconds” behavior. I can’t imagine its source, and it prevents me from using my setup to take pictures of wildlife in my yard. I hope someone can figure this out and rescue me.
I should add that this procedure is successful using a Raspi 2 B V1.1 and the legacy camera. The code differs in using “raspistill” in place of “libcamera-jpeg.” No preview of the picture is provided, however.
camera_motion_Raspi6.py
import os
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM)
GPIO.setup(17,GPIO.IN,GPIO.PUD_DOWN)
import datetime
import time
time.sleep(2)
print("Waiting for motion detection...")
while True:
if GPIO.input(17):
timestamp = str((datetime.datetime.now()))
timestamp = timestamp[5:19]
print("Pin 17 is high")
os.system("libcamera-jpeg -o "+timestamp[6:15]+".jpg --vflip --hflip")
print("Image captured at ", timestamp)
time.sleep(3)
print("Ready")
time.sleep(3)
else:
time.sleep(3)
camera_motion_Raspi6_ssh.py
import os
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM)
GPIO.setup(17,GPIO.IN,GPIO.PUD_DOWN)
import datetime
import time
time.sleep(2)
print("Waiting for motion detection...")
while True:
if GPIO.input(17):
timestamp = str((datetime.datetime.now()))
timestamp = timestamp[5:19]
print("Pin 17 is high")
os.system("libcamera-jpeg -o "+timestamp[6:15]+".jpg --qt-preview --vflip --hflip")
print("Image captured at ", timestamp)
time.sleep(3)
print("Ready")
time.sleep(3)
else:
time.sleep(3)
Neither of my two codes had proper formatting after following the instructions. I managed to correct the first but I can't seem to correct the second.
2023-02-15 12:17 am
@emeyeraway Instead of SSH, why not use VNC. Do NOT change the code, just start the VNC server on the Pi and use VNC viewer on either your PC or MAC. If it was working correctly then you made a change for X it's obviously the change for X that is causing the problem. You could spend a few hours to find something on the net that says to the effect, using X makes the camera take a picture every 60 secs but it is very likely it's not going to get fixed for a while.
As far as formatting, the Help method does not always work, instead, select the <> icon then when the text box opens paste your code into that. Yes, color coding is missing, it's been assigned over a year ago I think, welcome to open source!
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.
Topic starter
2023-02-15 7:32 am
I had tried what you are suggesting and it doesn't help. The real mystery here is why the code works initially, 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! The code itself hasn't changed visibly, but it has somehow changed in a way that makes pin 17 go high every 60 seconds. Nothing I have tried eliminates this "60 seconds" phenomenon once it happens. Surely someone out there can explain it.
2023-02-15 12:39 pm
Hi @emeyeraway,
When faced with strange behaviour that seems 'impossible', the implication is that something is not behaving in the way that you expect - the detective work is to discover what.
...when you have eliminated the impossible, whatever remains, however improbable, must be the truth?
borrowed from https://en.wikiquote.org/wiki/Sherlock_Holmes
......
This is a case of systematically 'disbelieving' on a 'one at a time' basis that each component, software line, wire, connection point, etc. is doing what you expect it to do. Of course, most will be behaving as you expect ... the trick is to find the one that isn't.
I am not familiar with the system you are using, but as you suggest:
The code itself hasn't changed visibly, but it has somehow changed in a way that makes pin 17 go high every 60 seconds.
Dissecting this statement:
The code ... has somehow changed in a way that makes pin 17 go high every 60 seconds.
Leads to the questions:
- Is pin 17 actually going high every 60 seconds? If you have an oscilloscope, can you capture the pulse?
- If so, is the software code driving it high?
- Or is the motion sensor driving it high? What happens if you disconnect the motion sensor input to pin 17? Does it still trigger once per 60 seconds?
- What happens if you use different pin for the motion sensor input?
- Try commenting out as much of the code as possible, so that it doesn't fire the camera .. just prints the "Pin 17 is high" message .. does that still appear at 60 second interval?
This list of questions is not meant to be complete, but hopefully gives an indication of how you might approach the enigma. Please extend and adjust the list until you find a clue.
Good luck with your quest. If you find something interesting, then try reporting it back to forum.
Best wishes, Dave
2023-02-15 4:35 pm
@emeyeraway Given how simple your code is it is likely a bug in libcamera, so perhaps you should pose your question to that team. You also might get more users who are familiar with the product over on the arducam support site (I assume there is one)
My personal gut feel is that the 60 seconds is connected to the headless aspect and the camera will always take an initial picture. To test that, just remove the headless part then wait a few minutes while leaving the room so as to not trigger the camera now look at the output to see how many images were captured.
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.
Topic starter
2023-02-15 4:48 pm
Hey, Dave!
First off, thanks for the time you put into your reply. It is reassuring to know there are folks out there who want to help.
In response:
I don’t have an oscilloscope and wouldn’t know how to use one.
I disconnected the sensor output lead from pin 17 and connected it to a voltmeter, and it is definitely outputting 3.3V every 60 seconds. I don’t know what is telling the sensor to go high, but it is the source of the high to pin 17. I have tried using the HC-SR501 sensor with the same code and observe the same 60-second behavior.
I have tried using a different pin for the sensor output, but I get the same behavior.
I have eliminated “import datetime” and all lines of the code that use it but still get the 60-second behavior.
I have tried putting the line that forces pin 17 low immediately before “Ready” as well as at the beginning of the code but that doesn’t help.
I tried your suggestion to comment out firing of the camera but pin 17 still goes high every 60 seconds.
I’m afraid it will take someone more creative than I to solve this dilemma.
2023-02-15 5:01 pm
@emeyeraway I am confused by one thing, when you say
I disconnected the sensor output lead from pin 17 and connected it to a voltmeter, and it is definitely outputting 3.3V every 60 seconds.
Is the output wire from the sensor going HIGH, or the pin 17? If it's the output from the PIR, then the PIR itself is the source of the 60 second signal.
I think I have one of those in my starter kit so will hook something up later today but that will be C code.
If you can change your code to C you will get a lot more help as not many of us here know Python and with such a high level language much is hidden.
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.
Topic starter
2023-02-15 5:05 pm
It's the output pin from the sensor that goes high. I don't know C, but I'll try to rewrite the code in C.
Thanks for your input!
2023-02-15 5:05 pm
@emeyeraway We need to see what your device looks like, there are some that work the way you say and is 'normal'.
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.
2023-02-15 5:09 pm
@emeyeraway What position is the 'retriggering' jumper in?
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.
2023-02-15 5:15 pm
@emeyeraway Does your device look like this
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.
Topic starter
2023-02-15 5:18 pm
The fact is, the very first time I used the setup and code it worked perfectly. I'd call that "normal." It somehow gets "contaminated" by using it headless and then going back to the original setup. So I know the code should work; I don't know what the "contamination" is.
2023-02-15 5:19 pm
@emeyeraway I think your sensor is working normally. Have you ever noticed that some security sensors cycle on and off? You must test these with no IR source nearby, perhaps cover the sensor business end with something like a piece of aluminium or mylar foil.
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.
Topic starter
2023-02-15 5:20 pm
No, I'm using a Raspberry Pi 3B+. I described my setup in my first post.
Page 1 / 9
Next