People Tracking

[richard777]

I've been looking into people tracking with RPi 2 B and OpenCv.

I found that using HOG works, but it's very very slow, even at very reduced resolutions and large WinStride settings.

Basically you can have good detection at 1 frame every 10 seconds or poor detection at 0.5 frames per second.

I also tried going for face detection instead using a HAAR Cascade and this works faster but obviously requires a face to work on and therefore needs a closer target.

Does anyone know if these OpenCV functions run on the CPU or is the GPU getting used?

Are there any tricks to getting better performance out of the RPi or do I need to look for a faster board?

Are there other methods I should look at for tracking a person in a scene, that has other moving 'clutter' in. i.e. it has to have some intelligence and not just work on basic movement detection...

Thanks for any help!

[richard777]

OK so not much response so far!

I have tried both tracking algorithms on my desktop machine (an old Intel Core 2 1.86Ghz) and it runs about 5-10 times quicker.

The HOG tracker is still slow with the best detection settings. Just over 1 second per frame.

[RpiName]

OK so not much response so far!

I do not know if this helps, but UV4L can do live object detection (face detection by default) at full fps and medium resolution in any video format. Classifiers can be passed as an option. The detection does not do anything useful at the moment apart from drawing rectangles around the detected object areas.

http://www.linux-projects.org/modules/s ... #example10

You can turn detection/tracking on/off on-the-fly by command line or by Web Interface from the UV4L Streaming Server.

[stderr]

I have tried both tracking algorithms on my desktop machine (an old Intel Core 2 1.86Ghz) and it runs about 5-10 times quicker.

That might be a clue as to how much faster it is than the pi, especially if you are feeding things in single threaded.

The HOG tracker is still slow with the best detection settings. Just over 1 second per frame.

While I can envision needing something faster than one second rate, I can't see needing 30 fps in real time. I can certainly see *keeping* the 30 fps for delayed analysis, but what difference does it make if you detect people now or a 30th of a second from now? Surely you aren't building a self driving car! Are you?

If you really need faster, I would definitely look at gaining control of each image off the camera so I could interleave them to multiple cores or even multiple pi boards. In your tests, find out how quickly you can process a single image with its overhead and then you'll know where your limit is if you start parallelising things. Obviously if you are given the choice of a stream of MPEG all connected together stuff or single images, your choice will be at least affected by how you want to decode things.

[windy54]

Hi,

I have been using opencv and the camera for various activities .

Have you come across this blog
Pyimagesearch.com

There are some really good examples of using opencv on the raspberry PI, there might be something of interest.

Steve

[richard777]

Hi,

I have been using opencv and the camera for various activities .

Have you come across this blog
Pyimagesearch.com

There are some really good examples of using opencv on the raspberry PI, there might be something of interest.

Steve

Indeed, that was my first port of call!

[richard777]

I have tried both tracking algorithms on my desktop machine (an old Intel Core 2 1.86Ghz) and it runs about 5-10 times quicker.

That might be a clue as to how much faster it is than the pi, especially if you are feeding things in single threaded.

The HOG tracker is still slow with the best detection settings. Just over 1 second per frame.

While I can envision needing something faster than one second rate, I can't see needing 30 fps in real time. I can certainly see *keeping* the 30 fps for delayed analysis, but what difference does it make if you detect people now or a 30th of a second from now? Surely you aren't building a self driving car! Are you?

If you really need faster, I would definitely look at gaining control of each image off the camera so I could interleave them to multiple cores or even multiple pi boards. In your tests, find out how quickly you can process a single image with its overhead and then you'll know where your limit is if you start parallelising things. Obviously if you are given the choice of a stream of MPEG all connected together stuff or single images, your choice will be at least affected by how you want to decode things.

Actually I'm driving a PTZ CCTV camera and it needs a minimum of around 5fps to keep on target.

It tracks reasonably well on the PC.

I am using a USB video grabber on the PC and unfortunately USB video grabbers appear to be another can of worms on RPi so the project is dead in the water at the moment...

I will see how a BBB goes or maybe try one of those Panda Latte boards when they are released.

[richard777]

OK so not much response so far!

I do not know if this helps, but UV4L can do live object detection (face detection by default) at full fps and medium resolution in any video format. Classifiers can be passed as an option. The detection does not do anything useful at the moment apart from drawing rectangles around the detected object areas.

http://www.linux-projects.org/modules/s ... #example10

You can turn detection/tracking on/off on-the-fly by command line or by Web Interface from the UV4L Streaming Server.

I'll look into that, cheers!