   Trajectories and intercepts, or "OH GOD, MY BRAINS"
  Alright, so in a vain attempt to rig up a camera tracking system to my robot, I learned that I have no clue how I am going to have the camera track an object. I understand how it sort of works but whenever I try and put it into psuedo-code, I end up getting trapped in circular logic.Basically, I need a way to plot where the camera should be if an object X meters away is travelling at speed Y and the camera takes T seconds to capture an image, if I want the image perfectly centred. Since this is an automated system, you can see my delemma.   quote:Original post by Oluseyi    You know you''re cool when you use MacGuyver as a verb... 
  I''d just make stuff up, personally. But that''s just me.Image analysis is damned hard. Resist everyoneI am your only friend. Click here for more information.;  There are some good articles out there missile guidance systems that talk about this very thing.   Do a search on google and you''ll come up with something.Anywhoo, here is what I think you could do:Since you''re talking about rotation only (ie: turning the camera) distance should not matter at all.    Everything in the scene, regardless of it''s distance from the camera, will appear to be turning at the same rate.Basically what you want to do is figure out how many pixels off center the subject is, and move your motor in way that will adjust the image by that many pixels.So what you need to do is figure out how many pixels each step of your motor will move you.  You could probably figure it out on paper, or, if you''re like me, point the camera at something and figure it out by comparing two images.You could even add a calabration phase to your program where you automatically figure it out everytime the system is started.Cheers,Will;  Most facial recognition systems have extremely advanced tracking algorithms.  I''ll give you some links if you want, but I have the feeling that the cost is going to be extremely prohibitive.  Some of the newer systems can track up to 4 people (or objects) in 32 or 64 video streams.  Actually, I saw a really cool DVR system at ComDex that was relatively inexpensive.  I''ll try to find their info for you. ;ICP America has really sweet DVR equipment.  You can get a card and box for video input for about $400 I think.  It includes an SDK and demo software for interfacing the DVR equipment with your own application (robot vision!).  If you''ve got a spare hunk of cash, it might be really fun to play around with. ;  @ ZulI am not about to shell out that much mony for something I already have half built. I already have a range finder and a simple image tracking system set up, but the problem lies in things like image captures and *cough*weaponry leads*cough*. Basically, any way I can save $400 is a good thing.@ RPGeezusOne of the main issues here is that it assumes the object is always travelling at a constant rate, which, according to the laws of physics, is a pretty safe bet to say that that won''t happen. Odds are that the object is going to be accellerating/decellerating at a rate I can not easily predict.   quote:Original post by Oluseyi   You know you''re cool when you use MacGuyver as a verb... ;  Unfortunately, most good capture cards are fairly expensive (start around $300).  You could probably get a not-so-good one for less that might work well for your robot.Here's a list: clickWe use FlashBus cards here, and they are really good, but also expensive.  You might do a search to see if there's anything in the < $100 range.[English?]   [edited by - Zul on January 29, 2004 1:40:57 PM];quote:Original post by Zul  Unfortunately, most good capture cards are fairly expensive (start around $300).  You could probably get a not-so-good one for less that might work well for your robot.Here''s a list: clickWe use FlashBus cards here, and they are really good, but also expensive.  You might do a search to see if there''s anything in the < $100 range.[English?]   [edited by - Zul on January 29, 2004 1:40:57 PM]Uhh... no, I already have a simple image tracking system, but when it comes to ranged objects, it is painfully akward. I just need a way to predict the course of an object, given it''s speed, and relative distance from the camera.   quote:Original post by Oluseyi   You know you''re cool when you use MacGuyver as a verb... ;  Sounds challenging.  Are you planning to take world physics into consideration?  For instance: if a ball is about to collide with a wall, predicting a bounce?  Or predicting a parabolic turn if a ball moves onto a slope?Also, an animated object might move at a constant speed while an inanimate object would just react to gravity, friction, collisions etc.If you want to consider physics, then I think the robot will need a sense of which way is down.  Maybe assume it is always on a level surface and keep track of it''s camera''s position/orientation? ;quote:Original post by 5010  Sounds challenging.  Are you planning to take world physics into consideration?  For instance: if a ball is about to collide with a wall, predicting a bounce?  Or predicting a parabolic turn if a ball moves onto a slope?Also, an animated object might move at a constant speed while an inanimate object would just react to gravity, friction, collisions etc.If you want to consider physics, then I think the robot will need a sense of which way is down.  Maybe assume it is always on a level surface and keep track of it''s camera''s position/orientation?   Umm... not that advanced, more like...Object "ball" is moving at "F" meters per second, accellerating at "A" m/s/s. Where will the ball be in "X" seconds.Or...Object "ball" is moving at "F" meters per second, and has changed course by "M" degrees, where will the ball be in "X" seconds.   quote:Original post by Oluseyi   You know you''re cool when you use MacGuyver as a verb... 