Posted: 3/15/2010 12:50:33 PM EDT
|
So I've just about gotten ready to take the next step in my hobby robot project. In order to facilitate self-navigation it will be necessary to determine the distance to nearby objects and surfaces. My first thought was to utilize 3D laser scanning technology (as used in some surveying) but those things cost about 100K.  As such, it will be necessary to build something from the ground up. Here's the plan for those interested: Two analog security cameras will be mounted a set distance apart from each other on a rotating stalk above the robot. An infrared laser will be mounted between the cameras along with an optic that causes the laser to produce a horizontal line. A servo will cause this line to slowly scan up and down while the cameras rotate. The laser will therefore shine over all possible points that the cameras can see and in 360o around the robot. Output from the cameras will go through a composite video analog to digital converter. An FPGA will then be used to determine the location of the line in each vertical pixel column from each camera. This information will be sent to a computer over Ethernet. Differences in the "location" of the laser line as shown by the two cameras will be used to determine distances. These distances will be stored by my program (written in JAVA) as spherical coordinates. |
|
Look up "Sum of Absolute Differences" and Stereopsis. That's how depth perception is usually done. the computation overhead lends itself well to hardware as the software won't keep up). An efficient architecture for the windowed sweep and partial line computations is a must. Mechanical scanning will be very slow if you're just looking for point measurements. from the two cameras. And doing that with stereo cameras seems a bit pointless when you could just use a laser rangefinder and take readings directly. but that would be many points unless you just scanned ahead and up/down a bit. |
|
Quoted: Look up "Sum of Absolute Differences" and Stereopsis. That's how depth perception is usually done. the computation overhead lends itself well to hardware as the software won't keep up). An efficient architecture for the windowed sweep and partial line computations is a must. Mechanical scanning will be very slow if you're just looking for point measurements. from the two cameras. And doing that with stereo cameras seems a bit pointless when you could just use a laser rangefinder and take readings directly. but that would be many points unless you just scanned ahead and up/down a bit. Some of the computations will be done using hardware. How much is to be done using hardware is yet to be determined. I did do a mock up of the algorithm using just software to do the calculations and it preformed remarkably well. Using a hacked together laser rangefinder "might" work but it would be slower than what I am proposing I believe. However since stereo cameras will only be accurate out to a relatively small distance a laser rangefinder of some sort might be included in the final design somehow, if only to check distances to large and faraway objects like buildings. |
|
Quoted: Good luck. They have been doing that our here for years in that DARPA challenge, and have yet to really get it. I know!  I have studied the results of that contest a couple of times for ideas. My hope is to be able to duplicate better their results with a smaller budget. |
|
Quoted: I'm fascinated as to how the horizontal line from the laser will be picked up from other image features and how you will differentiate the timing of each sample point, as computing the difference between left and right images usually needs some kind of correlation.Quoted: Look up "Sum of Absolute Differences" and Stereopsis. That's how depth perception is usually done. the computation overhead lends itself well to hardware as the software won't keep up). An efficient architecture for the windowed sweep and partial line computations is a must. Mechanical scanning will be very slow if you're just looking for point measurements. from the two cameras. And doing that with stereo cameras seems a bit pointless when you could just use a laser rangefinder and take readings directly. but that would be many points unless you just scanned ahead and up/down a bit. Some of the computations will be done using hardware. How much is to be done using hardware is yet to be determined. I did do a mock up of the algorithm using just software to do the calculations and it preformed remarkably well. Using a hacked together laser rangefinder "might" work but it would be slower than what I am proposing I believe. However since stereo cameras will only be accurate out to a relatively small distance a laser rangefinder of some sort might be included in the final design somehow, if only to check distances to large and faraway objects like buildings. |
|
Quoted: The cameras will have an infrared filter so that they only see the line.I'm fascinated as to how the horizontal line from the laser will be picked up from other image features and how you will differentiate the timing of each sample point, as At the outset I am planning to simply assume that the two frames coming from the cameras were taken at the same time. If this assumption proves to be too far off from the truth then there will have to be some kind of synchronization circuit retrofitted to the cameras. That might be a lot of work all by itself so I'm hoping that it isn't necessary. computing the difference between left and right images usually needs some kind of correlation. |
|
Then you'll be wanting a vertical line: | rather than horizontal _ That way the number of pixels offset from one image to the other will give you a stereo difference. Bigger distance = closer object. However, your frame rate from the cameras and scan rate of the moving line may give you some unexpected challenges. Stereopsis with SAD woudl give you the ability to take single left and right images and determine a heat map of the best matches and hence best matching offsets between the two images. I've seen 15x15 windows with 30 or 40 positional measurements - and that's very compute intensive. No multipliers though :-) |
|
Quoted: Just a thought, you might look at digital cameras that are controllable by USB. You could take the picture from both cameras at the same time and process them. To have that all computer controlled would most likely require writing new drivers for complicated hardware that I know nothing about. It would certainly be possible but would present its own share of challenges. |
|
Quoted: Then you'll be wanting a vertical line: | rather than horizontal _ The line will be vertical with respect to the orientation of the cameras for the reason that you mentioned (scanning rate of the cameras). However, the cameras will be on their "side" when mounted so the line will be horizontal with respect to the rest of the world. Mounting the cameras on their side also gives a greater number of pixels in the "up-down" direction. This is key since the cameras will not be movable in that direction. More information available is always a good thing. |
|
Quoted: Quoted: Just a thought, you might look at digital cameras that are controllable by USB. You could take the picture from both cameras at the same time and process them. To have that all computer controlled would most likely require writing new drivers for complicated hardware that I know nothing about. It would certainly be possible but would present its own share of challenges. Canon cameras at least have an SDK that works VERY well. http://www.usa.canon.com/consumer/controller?act=SDKHomePageAct&keycode=Sdk_Lic&fcategoryid=314&modelid=9808&id=3464 |
|
Quoted: Quoted: Canon cameras at least have an SDK that works VERY well.Quoted: To have that all computer controlled would most likely require writing new drivers for complicated hardware that I know nothing about. It would certainly be possible but would present its own share of challenges.Just a thought, you might look at digital cameras that are controllable by USB. You could take the picture from both cameras at the same time and process them. http://www.usa.canon.com/consumer/controller?act=SDKHomePageAct&keycode=Sdk_Lic&fcategoryid=314&modelid=9808&id=3464 Interesting... |