camera trap sensor zones - how much is hardware and how much firmware

Peter Apps

@Peter_Apps

Botswana Predator Conservation Trust

Groups

Sensors

Hello all

The passive infrared sensors on camera traps differ between makes and models and some of them are heavily biased towards movement in certain directions - Reconyx for example is strongy biased to movement across the bottom half of the field of view, which means that an animal can walk stright towards or away from a Reconyx camera and only be detected when it is less than 2m away.

Some of the detection zone arrangement depends on the hardware of the fresnel lenses that are moulded into the window in front of the PIR sensor, and the number and arrangement of sensors on the PIR (usually only 2 or 4 as far as I know - the fresnel elements make the heat image jump from one to another as the target moves smoothly across the field of view). To trigger an image capture there must also be some logic processing of the rising and falling signals from the PIR zones - does anyone know, for any camera trap, whether this is firmware (i.e. in principal it could be modified) or is it likely to be locked into the hardware of the chips ?

Thanks, Peter

Akiba

@Freaklabs

Freaklabs

I'm an engineer and product designer working on wildlife conservation technology.

14 March 2019 5:02pm

Hi Peter.

I can't speak for the more expensive camera traps but the cheap camera traps are generally based off a reference design that's provided by the main IC supplier. In many cases, this would be Sunplus, a Chinese chip fab. From my experience in manufacturing, I would say that the camera trap (trail camera?) supplier likely does not care about correcting across the differences between the Fresnel lens zones. What they do is copy the IC supplier reference design, possibly with some slight modifications, then have a test to see if the PIR sensor detects motion. If it does, then that particular test passes and if the other hardware tests pass, then the device ships.

Akiba

@Freaklabs

Freaklabs

I'm an engineer and product designer working on wildlife conservation technology.

14 March 2019 6:06pm

Hi Peter.

Not sure about the exact definition of standard components. For interfacing cameras to microcontrollers, the microcontrollers either need to support a MIPI high speed serial interface or a very specific camera parallel interface. Other than the the STM32 chips that suppor the Digital Camera Inferface Module (DCIM), you would need programmable logic (FPGA or CPLD) to interface a camera.

That's why there's not a lot of good open source camera traps. They're all somehow based on the Raspberry Pi which has a built in MIPI interface. The amount of electronics expertise needed to design a digital camera interface on a low power microcontroller is intense.

The commercial cheap trail cams use the Sunplus reference design. You can check out more info on that here. You can also check out trailcam specs here. There might be other chipsets that service the trailcam market but I doubt it. It's already quite niche and probably won't allow more than one low cost chip manufacturer survive.

In regards to other standard components, I agree. The PIR sensor, LEDs, and camera are all pretty normal electronics stuff. But the main innards to interface the microcontroller to the camera are where all the challenge is. At hackerfarm, we're investigating designing an open source custom logic device to bridge cheap microcontrollers with decent CMOS cameras for open source camera traps. It would be huge for us since we can finally see the animals that are near us and also formulate a strategy on the ones that eat our crops.

Akiba

Alasdair Davies

@Alasdair

Arribada Initiative

Director at Arribada, a UK-based conservation technology research & development organisation

16 March 2019 10:25pm

Hi Peter / Hackerfarm,

That is interesting indeed, as stripping cameras down will reveal a number of standard components. The reviewer may have been referring to a few specific vendors (Reconyx) as the bulk are certainly from standard components. I've been working with camera traps for about 11 years (co-founded Naturebytes that offers a consumer Rasp Pi version) and took a look at several brands and models a few years back, which revealed a very common SoC, with cheap variants using the SPCA1628. The mass-produced cameras nearly always copy or resell a standard design / firmware and you'll even see the same typos show up in interfaces etc (UWAY / ScoutGuard etc). The UM562 used the same cellular daughterboard as a number of other brands at the time. Reconyx certainly don't - there was at one time a schematic of their design, but I know for sure that a dedicated ViCAM®III is used to enable the rapid recovery / write that the cam is well known for. You pay much more, but that's a RISC processor providing up to 80mips.

In terms of PIRs, my experience is that quality differs immensely. From a cheap batch of 1000, it isn't uncommon to see 10% fail or produce poor detections during Q&A (HC-SR501 for example). Bushnell etc I believe use a good quality manufacturer, but because you're basically looking for a 1 or 0 signal change, zoning is the "cheap" answer that they all use, which is described in detail here (https://zslpublications.onlinelibrary.wiley.com/doi/pdf/10.1002/rse2.20).

Multi-zone and single zone fresnel lenses mask the detection to avoid sun glare, minimise one large heat source (hot wind) creating false positives etc, with Reconyx again known for multi-zone and less false positives than generic camera traps. Without a "middle ground" you can only trigger on or off with a PIR so the zones help, but firmware does control false positives / sensitivity. Usually this defaults to the "high / low" sensitivity settings, and to keep the camera's easy to configure there's no physical trimpot for a user to do this so it's done at the software level. Therefore to answer your quesiton, I'd say you are looking at a few different variables (make of IC, fresnel zones, firmware to tweak responses) but you could start with a Sunplus and get some different fresnel covers to experiment. There are good photos in the paper linked above showing the options.

Lastly - Hackerfarm. Lovely write up of the AudioMoth recently. I am Alasdair from Arribada (we manufactuer the AudioMoth using GroupGets for Open Acoustic Devices). Thanks for your detailed breakdown, I'll loop you in to AudioMoth 2.0 dev with Andy (if he wasn't already been in touch :)

Open source camera trap reference designs - yes indeed. Lots of progress in the EPS32 space at the moment, but getting a good resolution, fast writes, quick recovery and good IR illumination is indeed challenging without resource and time to do it well. I have been thinking of looking at this moving forward with my Shuttleworth Fellowship, so I'd be interested to see what you have in mind there too.

Cheers,

Alasdair

Akiba

16 March 2019 10:25pm

Hi Alasdair.

Thanks and nice to virtually meet you. I hear a lot about you and the Arribada initiative :)

Regarding the AudioMoth, it's actually an interesting conversation so I'd like to move it to the Acoustic Monitoring group, here: Audiomoth 2.0 Development

Regarding camera traps, thanks for your insight. It makes a lot of sense. I've worked with a lot of factories in China and what seems to be happening is that it's likely all the trailcams (or at least trailcam electronic assemblies) are made by one company off a generic reference design. That factory sells it to other companies that customizes the enclosure, camera, and sensors and those companies then sell it under their brand. It would actually be interesting to track down the factory that makes those trailcams and see if they'd be willing to make trailcams with specific feature sets for camera traps.

The zoning with the Fresnel lenses is fascinating. That's the description of how the PIR sensors work that I never knew I wanted to learn.

I didn't know that people were putting cameras on ESP32s. That's really interesting. For a Raspberry Pi based camera trap, I'm curious if the traps run into power issues. The RPi was never designed to be a low power device so people have to do a lot of workarounds to get it to work on batteries for long periods of time.

We've actually discussed camera traps quite a bit at hackerfarm before we found WildLabs. We wanted to use them to check what kind of animal population we have near our farm plots as well as where the deer and wild boar would come into the plots from. One idea that we tossed around was an open source camera trap based on a specific ARM Cortex M4 chip that has a unique feature, a digital camera interface. The Cortex M4 would be much easier to optimize for low power operation and it's possible to build a custom board specifically for the camera traps.

The other option we were thinking of was to take a low power programmable logic device (CPLD or FPGA) and put together a standard memory interface to MIPI bridge. That way, it's possible to throw it on to any chip with a standard memory bus and it gets a camera interface. There's pros and cons to both approaches though. If you'd like to talk more about open source camera traps, I'd love to hear your ideas.

Akiba

Alasdair Davies

@Alasdair

Arribada Initiative

Director at Arribada, a UK-based conservation technology research & development organisation

1 April 2019 7:51pm

Hi Akiba,

Sure thing. An open source camera trap reference design or SoC that meets commerical specifications is, in my eyes, one of the key missing elements in the world of camera traps due to the complexity of achieving comparable performance as that of a Bushnell / Reconyx. Nobody has cracked it yet, and if you're game, that would offer real value to the camera trapping community. I'd be keen to support a move in this direction.

I supported an experimental programme of work a few years back that multiplexed the SD card, meaning anyone with an existing generic camera trap would use the modified SD and the camera would happily keep the bus, writing data / photos, but the bus would be switched on init so the previous data could be read by a third party radio or device, meaning cheap trail cameras could be modified and used and extended. A flat ribbon cable escaped the enclosure in this instance. I was also going to try and run busybox (think WiFi-SD cards) for wireless transfer but the prob was power as the SD card only received power during writes and the objective was 0 hacks - just a modified SD in a standard camera. Could still go down the firmware route, but it gets heavy supporting various different makes. A reference open design and injection moulded case would be the real answer.

Cheers,

Al