15
A 3D laser range finder or LIDAR such as the one on the Google Car is far more expensive than a camera. The other reason is that while in case of a LIDAR the distance of every pixel is available, the generated data to be processed is enormous. You have to transfer and process data faster which comes out again as rising cost. Finally cameras usually have a ...
12
Features like the sun and clouds and other things that are very far off would have a distance estimate of inf. This can cause a lot of problems. To get around it, the inverse of the distance is estimated. All of the infs become zeros which tend to cause fewer problems.
11
Off the top of my head I would go by the following selection criteria
color/b&w - usually b&w is better, since the stereo algorithms only use one channel anyway
baseline - this really depends on the scene. With the baseline you control how much accuracy you get with distance. Wider baseline results in higher disparity values and thus less noise on ...
9
It is not possible to achieve arbitrary precision in camera calibration, precisely because of camera resolution and camera imperfections (e.g. lens distortion, which is only approximated in the calibration of intrinsic parameters).
That, however, isn't usually the worst part of the deal. You can go a long way if you are able to fabricate your calibration ...
8
Optical avoidance of people in an every-day (like) environment would be difficult, your best bet would be with sensing the range of things from the robot, rather than if it is a person or not. An Xbox Kinect could do the job if mounted in the right place. Alternatively you could use range finders, either the light or acoustic variety. I have used Ultrasonic ...
8
The inverse depth parameterisation represents a landmark's distance, d, from the camera exactly as it says, as proportional to 1/d within the estimation algorithm. The rational behind the approach is that, filtering approaches such as the extended Kalman filter (EKF) make an assumption that the error associated with features is Gaussian.
In a visual ...
7
Actually we don't. This is the source of myriad visual illusions. Through a life time of experience we learn context which tells us when one thing can be on another vs. in it. But even then a sculpture can be built to trick us. For example it can look like a plate, cup, and spoon organized in a certain way but in fact be non of the above. A good example of ...
7
Animals and robots both need to understand something about the 3D structure of the world in order to thrive. Because it's so important, animals have evolved a huge number of strategies to estimate depth based on camera-like projective sensors (eyes). Many make use of binocular disparity -- the fact that the distance between the same scene point in two ...
6
A few things you should be on the lookout for:
Global shutter basically means all pixels get captured at the same time, as opposed to Rolling shutter where they are captured sequentially in a line scan fashion. Since your UGV will be moving around and performing stereo algorithms over the images you capture, it could be important that you avoid aberrations ...
6
You should start by calculating how many frames per second you need, and how much camera resolution you can process at that framerate. If nothing else, that will prevent you from overspending or from buying a camera that won't suit your needs.
Beyond that, there are a variety of features that make the choice more difficult/interesting. Different cameras ...
6
As a neuroscientist/engineer who teaches vision in a physiology course for engineers, but who hasn't read any of the FREAK docs, I'd point people to the works of David Marr, or maybe Kuffler. I found a nice review at Introduction to visual computation and
the primate visual system - 11MB PDF.
Retinal receptive fields (or more properly, ganglion cell ...
5
You probably are asking too much of inexpensive components.
The raspberry Pi does not have 2 camera connections, but its brother, the Pi Compute board does.
http://makezine.com/2014/11/03/stereo-depth-perception-with-raspberry-pi/
Even then, you will have to write optimized GPU Code in assembler to get anything near acceptable performance if you try to do ...
5
Given that you are doing a more "constrained" goal, with a "mostly" static background, I would recommend simply doing a "background image subtraction" method. The "hard part" which has come a long way over the last decade is how you deal with shadows, light changes, and foliage moving.
There are tons of resources on this topic, but here is a good one I ...
5
Ball detection using vision is not extremely difficult, especially if the ball is easy to recognize. There are a lot of tutorials and blogs which give a detailed explanation on how to implement an algorithm to solve this problem:
Raspberry Pi Ball tracking
Using OpenCV on the Beagleboard to track an Aibo pink ball
OpenCV Tutorial C++ - Color Detection & ...
5
The most important point is the scale. If you do monocular SLAM, your map will only be accurate up to scale so that you e.g. cannot compute the length of the travelled path in meters. The scale between your map and the world is not even constant over time so that if you come back to your starting point, it's going to be difficult to match the beginning and ...
5
I would argue that the similarities are largely superficial. More "classical" machine vision approaches focused on finding features a human can identify such as lines, texture and blobs of color.
Neural networks were originally designed based on what was known of neurons at the time, for example the activation functions are loosely based on how signals in ...
5
ROS's tf.transformations.py has self-contained code for doing these functions and can be used without installing ros. In fact, the python code only depends on numpy!
transformations.py
4
You can try to skip the salient point detection, and just densely sample over the image (as grid or so) and compute a feature descriptor at every sample point. You can probably even go as far as computing a descriptor for every pixel.
You might lose scale-invariance, but I think this won't hurt too much for stereo vision as objects will be at approximately ...
4
In general, visual odometry is a method that performs odometric measurements using visual means. This rules out the SLAM component, since visual odometry is only a relative means of navigation (see my answer on navigation). There are a number of methods to extract the relative motion of the camera. Since the transform from camera to robot is known this will ...
4
Building on WildCrustcean's response another possiblity would be stereo vision. While we often think of stereo vision as using two cameras the techniques really only need images displaced in space and a model of the displacement. In other words I can take an image, move, then take another image. So long as I know the transformation between these two images I ...
4
It's hard to say exactly what they were doing, but the terms you may want here are "optical flow" and "egomotion". Sounds like there may have been some feature detection and matching (something like SURF or SIFT) or foreground/background segmentation thrown in as well.
OpenCV is probably the most widely used codebase for computer vision, they have a lot of ...
4
That is an interesting topic, and not very easy to get right on the first try. From experience with this, here are the most important things.
Synchronization. The camera must be 100% synced. For example, say the UGV is driving at a modest 36Km/hr (10m/s) and recording frames at 30 frames per second. That is, at every frame the UGV would cover 3m. Now, say ...
4
These are two different things which share a lot in common.
Simply spoken the CV's task is to perform automatic image processing and then display it to humans.
The MV has to do similar things but you do not get an image as result, you get data.
For example: "There are 6 apples in this image" or "The image shows that the product has a malfunction"
Sources:
...
4
Interesting question! Thanks for introducing me to FREAK!
The paper just says that overlapping fields "increases redundancy", my interpretation is that like most detectors, FREAK is essentially scrolling a detection window over the image. If you arbitrarily break the image into non-overlapping windows then there's a good chance you'll break a useful image ...
4
My favorite is the Learning OpenCV book. It has a fantastic stereo / 3D section that introduces concepts from the ground up. If you're at a university, you might be able to find the digital version available from the library website.
Depends, especially on how you are going to combine scans into a full 3D pointclound (if you need 360 degree views.) ...
4
This AR.Drone provides SDK, therefore, you can access the images on real-time. It is fully compatible with Linux. They have examples also for smartphones. I believe android and iPhone. It has two cameras. I've bought it and its price is reasonable. At that time, the price was roughly 272 CAD. Of course, the price is now more expensive than before but I ...
4
I don't know what you mean by "precision" and how do you measure it. The sensing
accuracy will probably go back to the camera calibration precision and the stereo matching algorithm used. If they ship the device "calibrated" then no one knows what happened after the camera was calibrated in factory and before you got it (mechanical shock, temperature swings)...
4
My question: are there cases where you'd still need a LIDAR or can
this expensive sensor be replaced with a standard camera? ...
A each one of them has its advantages/disadvantages. Thus in some cases it would be more suitable to choose a lidar instead of a camera and vice-versa.
A LIDAR doesn't require light to perceive the environment whereas a camera ...
4
In addition to those points in Bence's answer, cameras can:
Calculate many complex features that result in very robust matching between frames, and object recognition
High angular resolution (typical low->high range goes from $0.5^\circ$ -> $0.025^\circ$)
Lower power usage
Passive sensor (doesn't require 'clean' signal of a laser)
4
AprilTag is the state-of-the-art solution for pose estimation. The library itself already has pre-built functions to compute the marker position, given its size. The pose is estimated by homography decomposition and it's quite good if you don't go too far (2 or 3 meters for a 20cm marker). There is the C implementation made by the authors at University of ...
Only top voted, non community-wiki answers of a minimum length are eligible
