|
equipment recommendations for people tracking
Andrew [8 posts] |
15 year
|
I have an application where I want to run an overhead tracker for people running around below on a soccer pitch.
I am yet to buy hardware.
The camera will need to be at least 640x480, preferably higher, as it will cover half the field.
The main problems I see are speed and resolution.
Can you make recommendations on:
1) cameras
2) computers for the processing (eg. processor configurations, graphics cards etc).
What computer specs are relevant for RR applications?
Thanks,
Andrew.
PS. Will RR work for this app in real time?
|
|
|
|
Anonymous |
15 year
|
Andrew,
1) We typically like the Phillips 950 camera due to its high fps and low light insensitivity. But the field of view will be more narrow than other cameras so the camera would need to be higher than others. Other cameras that we have liked are the Logitech cameras and specifically their Orbit Pan/Tilt model due to its low cost for pan/tilt and image quality. The field of view is a little larger than the Phillips but will reduce fps in lower light situations.
The best approach here is to try a couple cameras out before committing to a particular one since they will really differ depending on field of view, and prevailing color and lighting conditions. Some cameras under certain halogen lights will wash the entire image instead of doing correct color representations (we found that out at a tradeshow a couple years ago) so the best course is to get a couple and test out a static scene to see what the image looks like with different cameras.
2) What processing power is required ... well, you typically can't answer that but we found as much as is possible given the project budget is the best way to go. Multi-cores are desired if you plan to run more than one camera on a computer, but if not then single core will be the best cpu/price performance. Note that will also be dependant on how sophisticated an algorithm you are running. People counting (which we are currently working on) is not very taxing but we're guessing on this since we have not completed the task yet. More on this to come.
Computer specs are mainly cpu speed and camera fps speed in your lighting situations, memory is usually not a bit issue since RR maintains a static memory state when running so 1 Gig should be fine (this assumes a 320x240 image). Graphic cards, bus speeds, etc. do not play a significant role in determining processing speed assuming current standards.
We expect that people counting will operate at around 20fps but this has not yet been fully determined.
Note that form factor and power of the setup might also be an issue. We've found the Netbooks to be ok in terms of lightweight image processing (like people counting) but you will have to test that once it is complete to see if it can process the desired resolution. Note that if speed is an issue reducing resolution will increase fps but at the cost of accuracy. Sometimes this is ok, sometimes not.
You can post more specific cpu requirements once you've decided on what to buy just in case we note something irregular.
Thanks for the donation!
STeven.
|
|
|
|
Andrew [8 posts] |
15 year
|
Thanks Steven.
I cannot find the Philips 950 anywhere. Does the Philips SPC1300NC/00 sound any good? (wide angle, high framerate and megapixel).
Unfortunately I live in Qatar and these things are hard to buy so I am going to have to make a shortlist of cameras (say 3 or 4). I already have a Logitech Fusion. What about the AXIS range? Or MPEG or H264 cameras? Are these compatible with RR or am I limited to moving JPEG (sorry I am a newb to this field). Does decent video compression speed up the RR interface to the camera? Do you support CS mount cameras (so I can get the entire field of view in the picture)?
The environment will be very well lit by halogen (I think). The spotlights will be mounted on same structure as the camera but pointing down onto the playing surface (like the camera).
|
|
|
|
Anonymous |
15 year
|
Andrew,
Sorry, that was the 900nc and not 950.
http://shop.ebay.com/items/_W0QQ_nkwZPhilipsQ20SPCQ20900NCQQ_armrsZ1QQ_fromZQQ_mdoZ
The 1300NC seems to be the next iteration of that camera so it should suffice too.
The Axis camera should work as well as other MJPEG (NOT MPEG) cameras but you will have to watch the frame delay in those. Note that with IP based cameras you can get 30 fps but the frame you have is actually delayed from realtime by a second or so. That's ok for non-realtime processing but for apps that need to react to the camera image very quickly will not work. What I mean by this is when a change in the camera is seen, you only see that change 1~2 seconds later on your computer screen. The video is running at 30fps but just delayed a bit. Not sure if this is an issue in your project but for robot control it can cause the robot to significantly overshoot any targeted approach.
While it is possible to use MPEG using the Media_Reader module I'd stick with MJPEG for internet cameras as most of them do not conform to a standard and we often add support for yet another IP camera that is doing things differently. If you see a module in RR for that camera ensure that the model type is the same, if not then you can try to use the HTTP_READ module for others and then if it still does not work then you'll have to contact us. The IP cameras that are supported can be found under the Cameras heading in the documentation at
http://www.roborealm.com/help/index.php#Control
with Axis type cameras working with the HTTP_READ module.
Video compression will help to speed up the fps since less data will be flowing through the network. BUT with compression most of the color will be lost so if you plan to use color detection that might be an issue after being compressed. Video compression will sacrifice most of the color channel since we humans don't need that much color information. This becomes very evident when running the RGB_Filter as the results will appear very blocky.
Note that we don't really care about CS mount cameras as that will be a camera specific feature and does not affect the image format/speed being sent to RR. Assuming you can get the image from whatever camera into a computer in some way then RR should be able to process it.
What I highly recommend you do at this point is to take your logitech fusion camera and take some same pictures of what the camera setup would most likely be. You don't need to have the camera mounted exactly as it will be but just place the camera in the position and take some image captures (or a short video) and try to do this at different times of the day just to check the lighting situation. Note that you will probably have to do this a couple times so if any permission is required to do so you should ensure that they know you will have to perform this task several more times to get it right.
Once you have a couple example shots that will help you understand the color, field of view and lighting issues. If the field of view is not sufficient with the Fusion you can check its field of view specs and buy another camera with higher field of view. If you can't get that many cameras then buy them one at a time with some idea as to what parameter you are trying to improve (lighting, fps, field of view, color, etc.). This will allow you to maximize the purchasing process at the expense of time (i.e. waiting for the cameras) and testing (i.e. you will have to snap new images of the arena for each camera).
Or if you can, borrow as many cameras as possible and do some test image captures of the scene.
Getting images from the actual arena is the best way to start to understand the issues that you will face given the hardware, esp. with halogen lights! Note I suspect that the spotlights will cause lighting issues too ... but the test images will reveal or discount that.
STeven.
|
|
|
|
Andrew [8 posts] |
15 year
|
|
What fantastic advice. Thanks STeven.
|
|
|
|
Anonymous |
15 year
|
Dag nab it, I was the high bidder on that auction until you posted the link
:-)
In all seriousness, the newer philips 1300 doesn't have nearly the low light performance that the older 900Nc did. (I realize I am completely sinking my chances of getting another one on ebay.)
Since you already have a quickcam fusion, you might start by experimenting with it. I find that it is a pretty good camera. You can set the gain and shutter manually and turn off the autoexposure which wrecks havoc with video analysis. You will want to run at a fairly fast shutter to avoid motion blur issues which will prevent sharp localization of objects.
have fun!
profmason
|
|
|
|
Anonymous |
15 year
|
Thanks I'll try the Fusion first. The notebook Pro 9000 is also available locally (is it much better than the fusion, or just similar?).
I am a bit concerned about the frame rate/high definition speed available with RR and just a few basic filters. Is OpenCV likely to be much faster than RR for this type of problem? Or similar? (not sure of internal workings of RR but I would guess the modules are compiled code so probably fairly fast?)
Also I was thinking of having a dedicated PC up on the walkway, next to the camera overlooking the pitch, doing video blob tracking. This would send a video feed via the virtual camera driver, along with blob COG (sockets?) to a second computer (wifi or wired LAN) which does further DSP (C++) and display everything at pitchside. Does this sound a reasonable configuration?
|
|
|
|
Anonymous |
15 year
|
So there is no multi - threading just with one camera?
Which core would be most suitable for one camera then?
Presumably not the (quad) core I7 ... maybe one that can be overclocked with a lot of L2 cache like the Penryn?
http://www.anandtech.com/weblog/showpost.aspx?i=480
Does RR utilise SSE4 instructions? If not, maybe that could be an advantage of OpenCV (turning SSE4 on)?
|
|
|
|
Anonymous |
15 year
|
Note sure about the difference between the Fusion and the 9000, best to try both.
You can certainly try OpenCV in terms of speed comparison but you'll have to experiment with that on your own. There is an active google newsgroup that might be able to help in this regard. RR does use SSE at the appropriate place but this is only for very taxing modules. But if performance is key then looking at more hardware specific implementations like FPGA might be a possibility. Or perhaps using a GPU like Nvidia might also help ... mind you that's a lot of programming work! Best to try with RR first as that will get the basic system up and running quickly and then performance improvements can be made from there.
As fast a CPU is always preferred. Lots of L2 cache will help with larger images. Not sure about the overclocked system as we've not tested that hardware but that sounds worthwhile. In terms of multi-cores, the more the better, but again I'd check first to see if you really need that. How many cameras are you going to connect to the computer? What's the resolution that you are planning to use?
Your configuration seems about right. Not sure how you would use the virtual camera driver to send the image unless another piece of software is used. You can also try the distributor_server and distributor_client to send and receive an image and variables on a remote computer running RoboRealm. Those modules are used to sync two RR's so that they can share images and variables.
STeven.
|
|
|
|
Andrew [8 posts] |
15 year
|
Thanks again.
Will just connect 1 camera, not sure about resolution yet but will be at least 640x480, probably higher. Will need to test the tradeoff between real-time tracking and image size.
What about the fastest OS?
Presumably WINXP (32 bit)? Does 64 bits help things?
About to order a new system to run all this (E8600 overclocked). That Philips camera SPC1300NC seems to have been withdrawn from sale, incidentally. There are a few reports on the web about it not running at 90 fps at high res. So I guess I stick to Logitech.
|
|
|
|
Andrew [8 posts] |
15 year
|
On a quad core machine, is it possible to get multiple instances of RR running on the same image, passing video via the virtual camera?
Each core just does a small part of the processing then hands it on to next core.
|
|
|
|
Anonymous |
15 year
|
Andrew,
Yes, it is possible to pass the same image to multiple RR's running on multiple CPU's ... or multiple machines for that matter. You can either use the virtual camera or the Distributor_Server/Client to do that.
Again, it will depend on what processing you are doing to allow this to happen. Some modules will require processing of the entire image to produce their correct output.
STeven.
|
|
This Thread