Links to all my notes (includes mini-projects and source code etc)
(+) 0001 How do I change the Pi System partition size ?
(+) 0100 Device tree settings
(+) 0201 Power over Ethernet - (PoE)
(+) 0202 Solar Power - (with WiFi)
(+) 0203 Power Bank pass through
(+) 0400 Accessing the SDHC card system image
(+) 0401 Accessing PC shares from the Pi
(+) 0402 Installing samba - (the Pi as a Network Share on your PC)
(+) 0900 Can this approach be scaled up to a PC UPS ?
(+) 1001 Pandora Spotify on the Pi
(+) 1002 Playing movies on the Pi
(+) 1003 Getting VGA from the HDMI socket
(+) 1004 Using the RCA socket
(+) 1005 Using the Pi RS232 serial links
(+) 1006 Using the GPIO pins
(+) 1007 Controlling the Pi Zero ACT LED
(+) 1200 List of standard camera modes
(+) 1300 Auto file names
(+) 6500 How to make the System partition read only ?
(+) 6501 Minimising SDHC corruption on power down
(+) 9000 diode switch
(+) 9001 Auto shut down
(+) 9001 MOSFET switch
(+) C201 High speed photos
(+) Dec 1969 (no desc)
(+) a000 Display setup - (for PhotoFrame)
(+) a001 go photoframe - (how it works)
(+) a002 set photo - (select for display)
(+) a003 go button script - (photoframe pause control)
(+) a005 get photos - (fetch resize)
(+) a00x Other display utilities
(+) c000 CCTV UPS requirements
(-) c001 countering low speed motion detect
How cope with slow motion detection on the Pi The 'problem' is that motion detect is CPU intensive = and, until GPU based motion detect becomes available, you will be lucky if the Pi CPU can manage motion detect faster than once a second. In fact, tests with a Pi A suggested that the common 'motion' utility would take 5s to detect motion !Of course the only real reason to use any sort of 'clever' motion detection algorithms is to cut down on the number of images being saved and thus minimise storage space required = as well as making it faster to check the CCTV 'footage' later. So the simplest approach - just saving any image that has a 'significantly different' JPEG file size compared to the previous (or some 'no detect' template') - might well be 'good enough. Such an approach should work especially well at night when 'no detect' = no PIR floodlights = all black (so minimum sized) images. The 'conventional approach' is to take a photo, then analyse it for motion, before taking the next. Plainly taking photos at 5s intervals is way to slow to get a 'decent look' at any intruder - in fact it's so slow that you would be lucky to get more than a single long distance 'arrival' shot before a fast moving intruder disappears out of the field of view (FOV) ! The trick to getting multiple shots of the intruder with a slow detection system is to generate 'sets' of high speed photos and then perform 'detection' on only one of them. For example, at 10 frames a second 5s worth of jpg's would mean each set has 50 photos (at about 2Mb (jpg) each, this is 100Mb). You then only check the last photo in each set against some 'no motion' template. If you detect motion in the last photo, you save the entire set (so even if the intruder 'arrived' at the start of the set you still 'have him'). Once motion is detected you keep saving until some 'time out' (or until the last photo of a set shows no motion). The result is a series of photos that start up to 4.9s 'early' and continue for up to 4.9s 'afterwards', BUT includes the intruder at 10 frames a second for his entire time in the FOV. Of course whilst you are performing detection on the first set, a second set has to be stored. If no motion is detected in the first set, you then start 'detecting' on the second set - whilst the 3rd set is overwriting the space used by the first set. If each set is 5s at 10 fps = 100Mb, you need enough RAM for 2 complete sets i.e. 200Mb. If motion is detected, you start writing the entire first set onto SDHC - and this has to be 'at least as fast as' the Pi camera is generating new photos, so will 'unload' set 1 faster than set 3 overwrites them. Using a 256Mb Pi (model A) On the Model we only have 256Mb RAM. There is no need to run the HDMI display, so you might expect that the video RAM needed is 'zero', HOWEVER the GPU needs lots of RAM to run the camera ! After deducting system RAM, you will be lucky to have 100Mb free (out of 256Mb) on the A, however this still gives you 50Mb per set, which (for 5s) allows a camera speed of 5 frames a second which should still be 'good enough' to catch most intruders. Notes 1) whilst terms like "pipe-line" (or "memory ring buffer") might be used, any actual implementation would use the *nix RAM disk (tmpfs) = so all the photos are simply saved and manipulated as normal files 2) the 'simple approach' of comparing file sizes should also work with video clips, especially at might.
This note last modified: 17th Nov 2017 17:30.