General overview of the code
bohemian
navigation robot and I've found the Sentience so interesting. The aim
of the project which I'm working on is to build a low budget robot
that will use economic components instead of any special kind of
hardware or software. As a result, I believe that the Sentience can
provide an appropriate framework for the vision of our robot.
At this stage, I'm about to get through the code but before that, I
would like to know the following issues. Please consider that I'm a
novice in computer vision and some of my questions might be out of the
subject or even irrelevant.
1) A list of stereo algorithms which are implemented in Sentience
including any clue to read more about them.
- Feature based correspondence algorithms.
- Correlation based correspondence algorithms.
- 3d reconstruction algorithms.
- Other available algorithms
2) The software architecture of the Sentience including some details
about the core and interrelation of available VS projects and
solutions (e.g. RTstereo, mapping, gridviewer).
3) Is there any way to evaluate the computational requirement of the
Sentience?
I also think that it can be useful if there was a section for stereo
data sets (e.g. indoor, outdoor). In this case, people would be able
to work with the code without having a stereo camera.
Cheers
motters
On Feb 28, 4:07 pm, "bohemian" <mzarafs...@gmail.com> wrote:
> 1) A list of stereo algorithms which are implemented in Sentience
> including any clue to read more about them.
> - Feature based correspondence algorithms.
> - Correlation based correspondence algorithms.
> - 3d reconstruction algorithms.
> - Other available algorithms
Stereo correspondence is a very involved topic and there have been
numerous attempts to find good algorithms over the years. The methods
which I'm using at the moment are:
1. A very simple method which looks for vertically oriented edge
features. This is similar to the method from Moravec's classic stereo
vision paper ( http://www.frc.ri.cmu.edu/~hpm/project.archive/robot.papers/1996/9609.stereo.paper/dbfinal.html
), although it doesn't use his interest operator. On a 1.8GHz laptop
it takes about 20-30mS to compute. This is fine for getting very
sparse but quite accurate stereo ranges, which might be suitable for
EKF SLAM.
2. Contour based correlation. This is my own algorithm, which uses
centre/surround fields to turn the images into a continuous contour
space. This is suitable for dense stereo.
3. FAST stereo. This is another of my own experimental
correspondence algorithms, based upon FAST corners (
http://mi.eng.cam.ac.uk/~er258/work/fast.html ) and line detection.
The results so far look at least as good as (1), possibly better.
FAST corners are easy to track from one frame to the next and so this
might be a good way of recovering the robot's pose with some accuracy.
Most of these algorithms have not yet been formally described in
academic papers. Typically those which have been described to date
are inaccurate under realistic conditions (eg. the Birchfield method)
and too slow for real time performance.
> 2) The software architecture of the Sentience including some details
> about the core and interrelation of available VS projects and
> solutions (e.g. RTstereo, mapping, gridviewer).
The software architecture consists of "core" algorithms and front end
applications. I'm deliberately keeping the Sentience core routines
separate from any user interface stuff so that it may be easily used
on Linux under Mono. It's my ultimate aim to eventually use Mono for
the entire project, and it looks like this will be possible in the
near future. Using Linux on low cost robots makes obvious sense, due
the lack of any licencing costs.
> 3) Is there any way to evaluate the computational requirement of the
> Sentience?
I'm aiming to keep the algorithms as efficient as possible, so that
any reasonably modern computer hardware could be used. The target
platform would be an embedded mini-ITX or nano-ITX motherboard, around
2GHz clock speed per CPU or faster.
> I also think that it can be useful if there was a section for stereo
> data sets (e.g. indoor, outdoor). In this case, people would be able
> to work with the code without having a stereo camera.
Yes. I'm planning to add some data sets of that kind soon. I would
have added them earlier, but they would have made the code base too
large. One possible limitation is the 20MB maximum size set by
Google.