Hardware for Homebrew Motion Capture? 82
goruka asks: "We are a small garage game development and 3D animation group, and as such, we try to develop by reducing costs as much as we can. Recently, it came to our mind that we could setup and develop a home-brew motion capture system by using three consumer USB web-cams to motion track bright objects attached to the body. However, we don't know which web-cam models can: capture at a decent frame rate (25fps) and resolution; are supported and easily programmed under GNU/Linux, since we'd like to later release our software as open source; and lastly, won't cost us a fortune. What are your experiences with such devices?"
Interesting... (Score:2)
Watch out for the pixel count (Score:1)
Preferably, try not to have the pixel count too high.
Typically, webcams are fairly lousy in terms of noise and focus. Getting a
cam which is pushing the MPs is really just going to be asking for trouble.
As far as linux go, I believe that mtp cameras are pretty much all going to
work.
http://ptp.sourceforge.net/ [sourceforge.net]
Different solution (Score:5, Interesting)
The benefit of this setup is that you can get away with very cheap hardware (you can probably borrow needed camcorders from friends and family if it's just a temporary deal), and the image quality - resolution, dynamic range, low-light performance, noise - will be a lot better than with a heavily compressed usb-cam stream.
As for synking the streams, you have that problem with three usb cams as well (can't caprture three usb-streams on the same computer), and with camcorders at least one step up from the bargain bin, you should be able to use sync cabling if you're really concerned about capturing frames at the same instant. I doubt that would be necessary, though, for the kind of precicion you're looking at getting (just do a linear interpolation between captured points to do an approximate soft sync should be fine for any movement you can hope to capture at 25/50 frames/s anyway).
Re: (Score:2)
Re: (Score:1)
The solutions are: ignore it, and don't rely on the motion capture alone for fast movement; figure out afterwards approximately what phase the cameras are in and interp
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
(of course, this doesn't sync refresh, but your animation package will be interpolating anyway, so it doesn't matter much.)
Re: (Score:3, Insightful)
Re: (Score:2)
The only reason that board needed to clap was so that the audio and video streams could be synched.
You can use that visual/audible cue to sync the video & audio from three different cameras with zero trouble if it's all going to be digitized anyways.
hackaday had a link to a motion tracking... (Score:1, Informative)
Axis (Score:3, Informative)
Re: (Score:2)
Get yourself a Philips SPC 900NC (Score:4, Interesting)
Features:
* 640x480@30fps w/high compression enabled (15 or 10 without)
* 35mm camera screw mount
* Manual adjustments on camera (sensor angle and focus ring)
* Lots of software settings to play with (AGC, white balance, shutter speed, aperature)
* Compatible with the PWC 10.0.12 drivers from http://saillard.org/linux/pwc/ [saillard.org]
* Above all: stable.
Sorry, here's the URL: (Score:3, Informative)
The reviews are not exaggerating, it's a nice camera.
I forgot, it has a usb-audio device endpoint two that's a built in mic, but that's not important.
The 1280x960 modes mentioned are software scaling, so they're useless. It's a fairly standard CCD board in the unit that is 640x480. Since it uses a Bayer pattern to filter
Re: (Score:3, Informative)
I've got a 4000 and it does 640x480 at about 30fps.
Thing about the Philips 900: (Score:1)
If the intended use is motion capture, they're going to want to have tripods and booms and stuff to hold these cameras in precise positions. Most other webcams just have some kinda suction cup or LCD clamp that isn't very useful for arbitrary positioning.
Webcam to 35mm (i.e. m42) (Score:2)
The trick is to get the adaptor from the astrophotography community which uses telephotolenses for astrophoto purposes. The adapters from Steven Mogg work well and incorporate a 1/4-20 tripod screw for mounting.
http://webcaddy.com.au/astro/adapter.htm [webcaddy.com.au]
Also note that the FireWire Fire-I has an optional C mount lens adapter:
http://www.unibrain.com/Produc [unibrain.com]
The nature of your dots counts (Score:2)
You will then have very bright spots on an almost black background. That will make recognising the spots easy, even for the most brain-dead of algorythms.
Professional 'body mechanics' use reflective spheres.
Re: (Score:2)
AKA reflective tape on ping-pong balls
Re: (Score:2)
Unibrain Fire-i (Score:1)
Re: (Score:1)
?
http://www.apple.com/isight/ [apple.com]
Re: (Score:2)
In short: Fuck them.
Dave
Re: (Score:1)
Re: (Score:2, Informative)
http://en.wikipedia.org/wiki/ISight#Discontinued_
Raw idea (Score:2)
Here is what I can tell you. My guess is that FireWire would be easier because all FW video uses the same driver. Find yourself (or just borrow or rent) two video cameras with firewire and use that. You only need two because one can capture one pair of axis (X and Z) and the other the other pair (Y and Z). If you put the cameras at right angles to each-other (pointing down the axis) you should have all you need. The programming half shouldn't be too bad, in relative terms. All you have to do is extract the
Re: (Score:1)
Did this 6 years ago with camcorders for a dem (Score:4, Interesting)
This is a lot of work but also a lot of fun! I did it for a real-time demo project with a few friend. We used Christmas fairy lights and 5 mini-VHS camcorders. You can see the result at the very end of our Childbone [pouet.net] demo.
Nowadays, using webcams will save you a lot of troubles, and you can find lots of very useful codes on the Internet (such as Intel's OpenCV [intel.com], however majors issues that you still have to solve would be calibrating camera positions and reliably tracking crossing markers in images. In my system I had to do an editor to manually reassign markers when incorrectly detected or labeled, which can be a very tedious task...
I would recommend Logitech Quickcam Pro 5000 webcams, as they are USB 2.0, can do 640x480 at 30 fps, and most importantly use the somewhat recent generic USB Video Class spec, for which a driver for linux [berlios.de] is available. I have a few of those and the image quality is quite good :)
Good luck!
Re: (Score:3, Interesting)
I wonder how the big studios deal with marker crossings? (Then again, perhaps they just pay humans to do tedious work.)
Seems like there must be a cheap hardware solution, given enough time and energy.
For example, one could put colored filters on the reflectors. By replacing each dot with a cluster of colored dots and then selectively blackening them you could code each point uniquely. It would take some experimentation to figure out how to get the results you need with consumer gear. Presuma
Re: (Score:3, Informative)
I can second the OpenCV nomination.
However, I think I may be able to add something to the puzzle: I was informed (but have not yet tested) that IEEE1394 (Firewire) cams will synch across the bus. This means that you no longer have to worry about adjusting for framedrops or timing or whatnot. Rather, the two cameras "see" their fields in lock-step with respect to time. I know that some folks here locally have had great success with Uni-Brain Fire-i cameras, but earlier in the thread someone reported
Bump (Score:2)
I should have posted on slashdot.
Why reinvent the wheel? (Score:1)
Re: (Score:1)
Re: (Score:2)
I, for one, will be pretty interested in how this turns out. I'd love to be able to do motion capture for a little one or two-man game.
Re: (Score:1)
Re: (Score:2)
It also means you'll never innovate a thing.
Or, try Doug's Law (correct me if this is from anywhere but my friend Doug): Make an estimate. Double it, then change the units. That's the estimate you give to the business end, and to the clients.
So, for instance, if it'll take you 10 seconds, say
Re: (Score:1)
Re: (Score:2)
Oh, I'm going to add my own amendment to Doug's Law: Doug's Law only covers unknowns. Anything you know -- time cost by mi
Re: (Score:1)
You just need to know what to outsource and what to do in-house. If you're an up-and-coming motion capture and 3D animation studio, then it might be worthwhile to try to innovate in the motion capture space. If instead you're an indie game developer that just happens to need motion capture for your next game, you're better off outsourcing the motion capturing and focusing on innovation in your game design and gameplay.
Just because you can outsource somethin
doug's law (Score:1)
Re: (Score:2)
Cheap Mocap Solution (Score:2, Interesting)
Here's their link:
http://www.naturalpoint.com/optitrack/ [naturalpoint.com]
If you have Poser(and free time), you can also try the Rotoscoper plugin by PhilC as well.
Huge link follows:
http://istore.mikrotec.com/philc/index1.html?page= catalog&trackerid=1661406456&category=a&vid=208024 5373&pid=924839477&oldvid=2143420604 [mikrotec.com]
Would an easier idea be... (Score:2)
Something like Gypsy [animazoo.com], only lots cheaper.
Re: (Score:1)
Simon.
Hitlab (Score:2, Interesting)
Hitlab (NZ [hitlabnz.org] but also an American office [somewhere]) also have come out with some pretty funky motion tracking. Beit for other purposes, but the source is available (via SourceForge: ARToolkit).
It may not be exactly what you are wanting, but with a little modification it should, and, importantly, is CHEAP.
Good luck. Hope to see some break-through gaming experiences. Hooroo
This may be a much bigger job then you think... (Score:2, Informative)
First, they have many, many cameras, because you have to have 3 unobscured camera views to triangulate a point. I assume you want to mocap people doing game moves, so multiple camera are required. Also, they capture with infra-red, not visible light. They put infra-red reflective spheres on the people at key locations, so what the camera picks up are
cheap homebrew infra-red mocap rig (Score:5, Informative)
- For your camera, look for cheap used DV cameras on ebay. Not super high res, but lots of them 3 ain't going to cut it, consider at least 9 (high/low from each of the cardinal directions, and on top [might want a few for different sectors]) - occlusion is an absolute bitch of a problem.
- This will provide reliable time-synced data, and NOT max out your USB bus.
- USB cannot provide you with images from 3 cameras with the same timesync, it's just not capable of such behavior.
- Firewire has a longer length limit on the cables, which is a big help for your work.
- Cheap PCI firewire cards - two should be enough, this will give you 6 seperate firewire busses, and put you at the limit of your PCI bus.
- Find filters that fit said cameras, and are opaque to visible light, but transparent to infrared.
- Rig up really bright infra-red lighting, ideally with a low quantity of visible light output.
- Go to an burgler alarm supply place, and buy infra-red reflective tape - I leart this tip from the EA guys a couple of years back, the 'official' reflective tape from 3M costs too much, and is a pain to order, but alarm places stock stuff that works even better, and is cheaper to boot.
- Buy really small polystrene balls, and cover with infra-red tape. On one small part of the ball, put the hook side of a velcro dot. These are reusable now, avoiding problem with tape waste. You can also clean them easily to keep them very reflective.
- For your subjects, get them to wear any clothing that velcro will hook reliably onto (pretty easy choice)
- Place the reflective balls on either side of every joint, spaced not more than 90 degrees apart - eg your elbow should have 8 balls.
Using infra-red helps reduce the data-set size way down, and also lets you use the cameras in monochrome for capturing, greatly reducing the data-set size.
From working with several commercial mocap rigs, I'll say that the calibration routines are extremely important. You need to accurately map the entire volume that you wish to capture in. Depending on space available to you, consider building a simple frame or using a lighting rig to attach the cameras to.
I will repeat again, occlusion is an absolute killer problem. From visting the EA facilities in Burnaby BC to specifically research their systems (I was working with a university research lab at the time), they estimated that they lost 2 hours of production a day to occlusion problems during mocap shoots.
Your system must be capable of tracking all the balls, all of the time. If it loses one, it's almost impossible to pick it up again properly during a runtime - you'd need to recode the relative location of that ball before it gave you useful data again.
Re: (Score:2)
They're making a sequal to Leisure Suit Larry. Their subjects Won't wear clothes.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
I just have to look the other way for a while and look you are upto
Re: (Score:2)
1) there is the research on animation from doing a series of figure drawing poses - the algorithm provides a set of poses that the user picks as being correct (a single figure drawing is ambiguos since there are multi
Re: (Score:2)
The figure pose stuff I have dealt with as well - using early and recent versions of Credo Interactive's "LifeForms" and the mocap input form they take. It's good for helping to solve occlusion by predicting which location
Re: (Score:1)
Re: (Score:3, Interesting)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
I'm trying o build one... (Score:2)
Luckily, it seems RealViz will soon be releasing a new software package [realviz.com], called Movimento, that claims to be able to obtain motion capture data from video of events taken from multiple camera angles. While this new software should definitely make things easier for
I looked into this once (Score:2)
When I was looking into it for a local doctor's office that wanted to do gait analysis research (something near and dear to my heart since i have a game leg and still no real
Would RFID chips? (Score:3, Interesting)
Re: (Score:2)
Unless things have come a long wa
NOT webcams! (Score:2)
Inexpensive "real" camera for IR tracking: (Score:1)
These run between $150 and $400 depending on where you get them and options.
It's a standard B/W NTSC camera with a clock sync so you can chain them together. CS lens mount, with electronic iris/zoom lens control.
Then you get yourself a few Osprey 1xxs in a mid-end server, and you can support 4 cameras pretty reliably. If you want to do more than 4, you might look at a Matrox Morphis; those are PCIe x4 or PCI-X, so they're a bit pickier. You could probably get 12 full frame streams from 3 of
Clean solution (Score:3, Interesting)
The default bt878 driver in FreeBSD works but I had to write a small driver to init the video switcher on the board.
Using very simple code you can capture and process 4 full motion video channels in FreeBSD.
I there is also the BTTV Linux driver for this board.
CCTV Cameras can be had for $35 each and the board is $200. for a total cost of $300 for 3 cameras to do motion capture.
I have used Blinking dual color LEDS on the target very successfully.
Also retroreflective balls and LED lighting also works well. The $35 black and white versions of these camera come with IR leds for so called "Night Vision" and works great with the 3M reflective tape.
See http://www.videotechnology.com/old1104.html [videotechnology.com] Retroreflective Materials for more info on that also.
Old video camera + IR leds (Score:1)
Camera suggestion + some other stuff (Score:1)
First of all, the library of choice for all things computer vision is Intel's OpenCV library. They have a linux version. I know nothing about the linux library, but the windows version only supports a few webcams. The cheapest and best for the money is the usb 2.0 Logitech
Your idea is good, but the implementation... (Score:3, Informative)
With that said, your ideas on using webcams is spot on, but you are going to need more than three, mainly for occlusion handling. For the rig I was contemplating (using webcams much the same as you), I was thinking of at least four cameras. The main problem I ran into (just in thinking about it, no actual implementation), and as others have described, was timing issues. For best results, you need all the frames captured from the cameras to happen at the exact same time. Since with USB webcams this isn't possible, you either need to come up with another solution (people here have mentioned some "high end" cameras that have syncing systems), or deal with it in software (very difficult to do, in addition to dealing with everything else, and still getting a high frame rate).
Another problem you are going to run into (and has been mentioned by others, but not much on the reason) is webcamera resolution. Most webcams that capture at decent framerates do so at QVGA (320x240). Even those that capture at a real 640x480 typically do so at only around 15fps, instead of 24 or 30. Rare (and more expensive) is the webcam that will capture at 24-30fps with VGA resolution. Even at VGA resolution, though, you are going to have to deal with the angular vs pixel resolution of the camera. What I mean by this is that as an object moves throught the FOV of the camera, it is going to only be imaged by certain pixels of the CCD imaging device. Depending on the distance away from the camera, the object may move say a foot, and only move (on camera) a pixel or so. The further away the moving object, the fewer pixels covered due to parallax. This translates into a lower resolution of pixels (on camera) to inches/cm (in real motion). In fact, this is almost the inverse problem of HMDs, where you can have high resolution, and low FOV, or vice-versa. In order to have both (in either cameras or HMDs), you have to pay a lot of money. In optical camera-based mocap, this means HDTV or better resolution cameras. I hope you understand what I mean here, because it is important for motion capture where you may be capturing large amounts of motion over a lot of area. For close-ups (like facial capture) it is less important - but remember, the higher the resolution of the camera, the finer the motion you can capture at all distances from the person/object to the camera. Higher resolution cameras translate into higher prices for the system, because you have to deal with more data, all in realtime. Not easy, not cheap.
You might best be able to deal with this by going the custom camera route. What you would want to do is build a custom frame capturing system, using 640x480 (or better) b&w CCD cameras (you don't need color, you just need IR sensitivity - even with B/W cameras, you are going to filter the final image down so far that it is mostly only a true b&w 2bpp image - so the closer you can do that in hardware, the less you have to do in software). This won't be easy, but many people have done similar systems for homebrew robotic vision systems, so look there. Realize that this kind of a project will likely dwarf your game development project in both hardware and software needs, and you might end up with a system
PointGrey (Score:2)
open source does not imply GNU/Linux (Score:1)
are supported and easily programmed under GNU/Linux, since we'd like to later release our software as open source
I'm wondering, if you're intending to release later as open source, then why does that necessarily mean that it must be supported under GNU/Linux? Seriously, open source can be for any operating system. Just pick the OS or vision API that makes camera interfacing the easiest, and write your code for that, while keeping the main parts as portable as possible. Open source shouldn't automatically
Wiii (Score:1)
g
DIY motion capture (Score:1)