ArduCam and libcamera

Posted by: @zander

↑

There is a lot more to learn, I have yet to see any code that works in any sensible way.

Yes, a lot to learn 🙂.  You start off with a sensible list of requirements.  A bullet point list is a starter.  When that is chewed over and refined,  you start the coding.  Diving straight in risks getting stuck in the mud.  Are you waist deep or just ankle deep in the mire.   

The example code the OP gave, and represented in the last code post  I made only needs a minor modification to remove the preview screen and transpose the picture to whatever you desire.  A couple more lines of code to control the number of pics taken with regards to the trigger event and duration of the trigger and you will have a basic setup you seem to desire.  

@byron The idea of a button driven preview is ok for the OP, not for my game cameras. I guarantee you being that close to a bear or cat or even a moose or elk is first of all unlikely but dangerous. I forget some of you folks don't get to encounter these beasties on an almost daily basis here in the colonies. If I go the PICO route I will not even have WiFi and that is ok.

@byron Pan tilt is wrong for many reasons. Flip and transpose does not correct for -90 AFAIK. It's still a problem even without a preview unless the sensor is square.

@byron When I said a lot to learn, it was my reaction to a bunch of parameters I had not heard about before. As I said, check the manuals, it works differently, not a state machine.

Posted by: @zander

↑

@byron The idea of a button driven preview is ok for the OP, not for my game cameras. I guarantee you being that close to a bear or cat or even a moose or elk is first of all unlikely but dangerous. I forget some of you folks don't get to encounter these beasties on an almost daily basis here in the colonies. If I go the PICO route I will not even have WiFi and that is ok.

The possibility of having a annoyed grizzly in the vicinity would indeed call for alacrity when setting up the field camera.  

I cant help think that a preview screen would mightily assist in getting the camera set up to take the snaps exactly where you want the camera to point at.   Look at the preview, tap the camera, up a bit, left a bit, tighten up its mounting screws, push the button to close the preview, disconnect the laptop and skedaddle out of there before a roving elk gets you.   

PS if you go the PICO route then make it a picoW and wifi is restored.

@byron Millions of guys deploy game cameras every year, I bet not one of them hauls a laptop along. WiFi and battery life are mutually exclusive. The cameras are wide angle, there is nothing to 'point' at, we just guess where game might show up based on long-established game trails or perhaps a feeding station (really just a few apples on the ground or corn)

@byron Millions of guys deploy game cameras every year, I bet not one of them hauls a laptop along. WiFi and battery life are mutually exclusive. The cameras are wide angle, there is nothing to 'point' at, we just guess where game might show up based on long-established game trails or perhaps a feeding station (really just a few apples on the ground or corn)

Posted by: @byron

↑

Posted by: @zander

↑

There is a lot more to learn, I have yet to see any code that works in any sensible way.

Yes, a lot to learn 🙂.  You start off with a sensible list of requirements.  A bullet point list is a starter.  When that is chewed over and refined,  you start the coding.  Diving straight in risks getting stuck in the mud.  Are you waist deep or just ankle deep in the mire.   

The example code the OP gave, and represented in the last code post  I made only needs a minor modification to remove the preview screen and transpose the picture to whatever you desire.  A couple more lines of code to control the number of pics taken with regards to the trigger event and duration of the trigger and you will have a basic setup you seem to desire.  

I was actually referring to some specifics, the attached pics should explain. There are a few parameters that can be set and I was surprised to find them as it does not fit my mental model. 

I do not plan on using a PIR as it is too easily fooled in the wild, but I will spend a little time looking into it just because I am curious.

Let me know if this is a surprise or not.

Posted by: @zander

↑

Let me know if this is a surprise or not.

No surprises.  Usually the defaults works fine, but useful to be able to tweak if necessary. (obviously you have to nominate the gpio pin.  I think the parameters are probably understandable for you, except you probably will not have come across the pin_factory before.

As you see this gpiozero module is one of several (and I gave a link to several docs on the various modules way back in the posting chain).  If nothing different is specified then the base class is the gpiozero model.  However the gpiozero higher level classes can sit on top of the older rpi_GPIO module (probably got the name wrong, but the one the OP was using in his first code post) or the pigpio library. (and I think one other, I forget but it will be in the docs).

So if you prefer a different module to control the GPIO pins then you can still use the gpiozero for a consistant interface.  Why use a different pin_factory I hear you ask.  Weill I think for very high speed use for example the pigpio module which is written in C and must have a daemon process running to use it could be used if very high frequencies are needed.  

@zander 

I should add that the gpiozero library is basically just a way of using the gpio pins with a few wrappers to make it convenient for those not so experienced.  For example it has a button class and a PiR class.  However, these are really all the same thing, a gpio pin is being initialised for input, but some of the default settings may be different.  For example the button may have a larger debounce setting from the PIR etc.  

@zander

Earlier this evening I was having a bit more of a play with picamera2.  A thought struck me on your remark 'you might even learn python to use a camera on your rpi Zero or rpi 4.

You can of course program the rpi in C or C++ and the following doc goes int some detail on how to use those languages to control the gpio pins.

https://www.ics.com/blog/how-control-gpio-hardware-c-or-c

and a bit of info on using c++ with libcamera

https://drive.google.com/file/d/1_OVpjTzcUJxYa72u4I5iHZQdKOVIKm86/view

Maybe you can keep in your comfort zone and will not have to go to the dark side 😀 

For my money using python with the picamera2 layer on top of libcamera API seems a lot easier , but you may well have a different perspective.

@byron Actually, in my heart I would love to learn a new language although I am really an assembler programmer at heart. Unfortunately, my brain does not want to cooperate. Also, as I said I am a hardware/assembler guy at my roots and I can't 'see' the relationship between a high-level language like C++ or Python and the assembler code the compiler spits out. That being said, I am hoping to use a PICO with a PICO UPS and an 'in camera' motion detecting system with an ArduCam camera. This will be a very high-level approach but I am comfortable with that. I will shoot raw and use the standard Adobe Lightroom software I use for all my photography to adjust contrast, brightness etc. My game camera is a very different beast from the OP's backyard critter grabber.

Thanks for the two links, I have filed them away for perusal later when I have more time.