|
[DPRG] digital compass in my car went crazy in Canada
Subject: [DPRG] digital compass in my car went crazy in Canada
From: Chris Jang
christopher.jang at yahoo.com
Date: Wed May 28 23:42:22 CDT 2008
> So Chris, we would love to see an outdoor robot do the DPRG
> ORC challenges with vision alone, optical flow, terrain mapping,
> scene recognition or whatever. Lots of builders think that
> ultimately the whole navigation process might be accomplished
> visually. But it's not clear how to get from here to there.
> How are you progressing?
David, I've been thinking about this more. I know I have already
replied. Sorry, everyone. The last few months have been crazy hours
at work. But now they've pulled back to a level where I can think
again (until they go crazy again).
Here is what I am thinking. With my robots, they were nowhere near
as capable as jBot. But they were capable of much more than they
ever demonstrated. That was especially true of Stella, the $15 toy
car with an ARM9 based PC104 board inside and webcam. Vision was
working at the full frame rate, all electronics were stable, and
she could at least drive on a parking lot surface ok.
The real obstacles I ran into were software and quantitative. With
vision, the processing pipeline of data collection, quantitative
analysis and tuning filters, either manually or through machine
learning is the dominant cost. Years ago, I tried writing a network
computer game. The graphics and networking was easy. What derailed
the project was the artwork, sound effects, game universe design,
etc. The engine was much less work.
That was my experience with robots. Getting them to the point where
everything worked was a concrete series of tasks. But then there
were the harder problems of both computing solutions and
representing them in software. I know that a few years ago there
were many discussions about robots that have models versus those
that don't. I'm not claiming anything about what is better.
So before I left Dallas, I might spend 20 minutes to get a good test
run with Stella. Then I would spend many hours analyzing the video
to look for stable image segmentation and feature thresholds (magic
numbers). I had not even tried to approach the problem of terrain
maps. Note that I do not imply SLAM - I am just thinking of a pre-
computed terrain map of a test area (e.g. parking lot with stripes
and fixed obstacles). I didn't even know about bundle adjustment and
these approaches. I didn't have good tools. Those software tools
needed to be written. And without this automation, it was not a
problem that could be solved.
I see this in my current job. A huge amount of infrastructure and
statistical methods are required to approach problems when they
become too large. It's not that automation is better than what a
human being can do manually. It's that some problems are so large
that only computers can do them in a cost effective way.
In my opinion, this is the real cost of pursuing computer vision.
The offline software development and computing costs are high. With
what I had, these costs were higher than the cost of the robot and
any onboard processing. That's the huge advantage of a IMU/GPS and
odometry solution. These software development (and modeling) costs
are avoided.
I read that in the first war in Iraq, cruise missiles were often
programmed with identical solutions. So they would fly nose to tail
one after the other sometimes. This made them easier to shoot down.
In an ideal world, a computer could automatically minimize some
cost function and compute unique solutions for each missile which
would optimize the chances they avoid air defenses and survive to
hit their targets. But the software didn't exist so programming was
still highly manual (and may still be).
That's what I'm thinking of more now when it comes to robots. I'm
thinking about the system that supports the robot and makes it
possible for it to do its job. If a robot relies on vision, then
that supporting infrastructure must be far more extensive.
--Chris
More information about the DPRG mailing list
|
