Choosing a processor for a run-time image-processing based navigation system - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Choosing a processor for a run-time image-processing based navigation system

Quoted text here. Click to load it

Interesting you're specific about the one parameter that's the most
irrelevant --- physical pixel size, but completely fail to see that none
of your other design parameters fit each other.

Quoted text here. Click to load it

To reach your target resolution of 10 mm at such speed you would need
100 fps at the very least.  10 fps means your vehicles move 10 sigmas
from one frame to the next.  That's not position determination ---
that's dead reckoning.

Quoted text here. Click to load it

Processing doesn't deliver accuracy --- your sensors have to.

Quoted text here. Click to load it

And on what basis did you reach the astonishing conclusion that you're
going to get better resolution than all those other systems, using worse
sensors than they do?

Quoted text here. Click to load it

And it'll miss your resolution goal by roughly a factor of 7, and your
factory floor size by a factor of 14, and that's before you add the
absolutely necessary overlap.  So you would need a good deal more than
100 of those cameras to cover your requirements.  Not to mention they
almost certainly wouldn't reach the required frame rate, either.

And another thing: at those distances, the corner pixels are seen at an
angle of 30 degrees off vertical.  So as soon as your warehouse is no
longer empty, but rather full of shelves or stacked objects, you won't
be able to see much of anything any more, which means you'll need
considerably more cameras just to get a look all the way down to the
floor.  After all, they don't build those things 20 meters high just to
use the bottom 2 meters, do they?


Re: Choosing a processor for a run-time image-processing based navigation system
Quoted text here. Click to load it

I did not understand what was meant by "completely fail to.....each other".
Care to explain ? (without OP-bashing for a change)



Quoted text here. Click to load it

You are right. On the previous AGV we have worked with, we have been able
to use the encoders on the wheels and on the steering to give us data
regarding change of position since the last estimation. We plan to use this
technique again. Excuse me for not mentioning it in my post.



Quoted text here. Click to load it

If I am moving at 10% speed in the '<1 m to the target' zone, my accuracy
improves. And as I mentioned above, the encoder data shall be used.



Quoted text here. Click to load it

There is no basis. I don't think we need a basis to experiment.
As for the 'worse sensors than they do' - I don't understand.

Quoted text here. Click to load it

I mentioned about 'considering camera on the AGV and markers overhead'. And
I foresee you repeating that '20 m tall containers....' and stuff - so I
request you to actually go through the full posts that I write and read
about the back-up system in case visibility is lost. It works well actually
- RSSI-based position tracking using Zigbee.

I appreciate the sarcasm. But, clearly this is not the most inviting
prelude to a person who wants to post something and help me. Please take
note @Hans.      

                    
---------------------------------------        
Posted through http://www.EmbeddedRelated.com

Re: Choosing a processor for a run-time image-processing based navigation system
shanky.kulkarni@n_o_s_p_a_m.gmail.com says...
Quoted text here. Click to load it

For a large field of view, the pixel size will have little bearing
on what works or not. In some cases larger pixel size and longer
exposure time may actually help you.

What will have an effect

    Lighting levels
    Lens bandwidth
    Lens distortion
    Using narrow angle lense (not wide angle lenses)
    lens with good MTF
    lens with low chromatic abberation
    lens with low barrel/pin/other distortions
    
    How many pixels in image
    Light sensitivity of sensor
    noise characteristics of sensor
    How fast you can realistically move the data from sensor to RAM

    Many other aspects long before you reach a processor.

--
Paul Carpenter          | snipped-for-privacy@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/ PC Services
We've slightly trimmed the long signature. Click to see the full one.
Re: Choosing a processor for a run-time image-processing based navigation system

Quoted text here. Click to load it

If I might expand a bit:

The field of view of the camera is a function of the optics and the
detector size.  Similarly, the IFOV (the angle subtended by one pixel) is
a function of the pixel spacing and the optics.

So as long as the optics match the detector properly, the pixel size is
nearly immaterial.  Getting optics that match the overall detector size
and pixel pitch is an issue, and a really large or really small pixel
size will make that harder, but that's usually a small issue in the
overall scheme of things.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
We've slightly trimmed the long signature. Click to see the full one.
Re: Choosing a processor for a run-time image-processing based navigation system
Quoted text here. Click to load it

Yes, there seems to be a problem with the OP numbers, if the warehouse is
a realistic size, it is not going to work.

I would think the obvious solution is to put the camera on the robot, and
markers on the ceiling. Add some dead reckoning and the robot should know where
it is quite accurately.

Unfortunately this idea is considered sufficiently considered non-obvious to
warrant granting a patent. Perhaps it is only obvious to an outsider, and not a
"competent practioner in the field"?

Anyway, you can buy a system off the shelf, it might work out cheaper.

Re: Choosing a processor for a run-time image-processing based navigation system

Quoted text here. Click to load it

OTOH, there should be a rich field of prior art -- there was a ton of
university research done in robotics & autonomous vehicles.

Patterned markers on the ceiling would let the robot get position and
orientation, and would certainly solve a whole bunch of issues with fixed-
mount cameras.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
We've slightly trimmed the long signature. Click to see the full one.
Re: Choosing a processor for a run-time image-processing based navigation system

Quoted text here. Click to load it

Yes, but it'll be busy-busy, as well as your comm link.  And everything
depends on a host of other factors.

The smallest amount of memory that you'll get away with will be a frame
buffer that's big enough to hold the image of the thing in the last known
position, plus enough pixels around it to accommodate any unexpected
motion and any obstacles you want to detect.  Doing this "minumum memory"
approach will cost you big time in ease of programming, system
robustness, and speed.

The most memory that you'll really need would be one frame from each of
the four cameras, so that you can do a bone-headed exhaustive search in
each frame.

Processing power varies widely for whatever method you choose, too.

I would do the following:

1: Have one processor per _camera_, that tracks all of the AGVs and
obstacles in its field of view.  These won't have be designed to be
small, vibration-proof, low battery drain, or a host of other things that
you'd need to pay attention to if they're on the vehicles.  Then have
each camera's processor broadcast the AGV position -- this will take much
less bandwidth than having the AGVs do it themselves, it'll make it
easier to have a central supervisory computer (to answer questions like
"Car #4, where are you?" when something breaks down), and it'll make it
easier to expand the system to a larger space, because the heaviest-duty
processing will be expanded along with the number of cameras.

2: Use industrial PC hardware.  It's cheap, it should be more than
capable of this task, there should be off-the-shelf vision software
that'll do most of it for you, and the development will be quick.

3: Then put some small processor on the AGV, like any of the host of ARM
parts, or whatever you please, and have fun.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
We've slightly trimmed the long signature. Click to see the full one.
Re: Choosing a processor for a run-time image-processing based navigation system

Quoted text here. Click to load it

[%X----Requirements for AGV guidance System ---- $X]

Quoted text here. Click to load it

Alternatively, the OP could do a proper analysis of his requirements,
complete with a risk assessment for when there are failures in the lighting,
camera system or links to the AGV's. The amount of information that would
need to be communicated to the AGV's might also be an issue.

I would look at putting the cameras on the AGV's (cheaper ones should be OK)
and adding processing to the cameras to determine where it is. I am looking
at this aspect as a fun project myself (self guided robot). My solution
would be using the GA144 chip but you could do something like Canny Edge
Detection with other processors. This would be much simpler than keeping
good cameras, adequate lighting, and a large amount of data communication
going all the time. With many more cameras and independent processing in
place, links to a central command station would be simplified to just the
information required to give each AGV its designated task.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Choosing a processor for a run-time image-processing based navigation system
shanky.kulkarni@n_o_s_p_a_m.gmail.com says...
Quoted text here. Click to load it

First of all work out all your lighting, distance, lenses, Field of View
calculations, to be sure you get your 10mm resolution,

Work out ALL your algorithms and trial them with MEASUREMENTS.

Look at what lenses you are using as barrel/pin/chrmoatic distortion
will screw up your calculations.

How do you envisage

    Installation set up

    Calibration of system

    Dealing with changes in lighting levels
    - do any roofs have skylights, this will cause sunlight flooding
      at known tmes of day per set days of the year)
    - Is the warehouse only light by internal lighting, how do you
      cope with flickering light or blown light

    Dirty colour marker recoginition.

    I do assume your marker has shape for direction recognition
    what happens when marker is obscured or partly.

Do NOT say "oh the software will sort this out", if you do not know
what you are trying to do for ALL these things you do not even have a
atart point to even work out your software and systems requirements.

You currently do not seem to have the basis of calculting anything yet.

--
Paul Carpenter          | snipped-for-privacy@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/ PC Services
We've slightly trimmed the long signature. Click to see the full one.
Re: Choosing a processor for a run-time image-processing based navigation system
Quoted text here. Click to load it

... on a 50 m by 70 m floor, that would require 5000 x 7000 pixels as a
bare minimum.  Your idea of "4 SVGA cameras" is aiming about 2 orders of
magnitudes below the target.  Oh, and the warehouse would have to be
essentially empty for a mere 4 cameras to cover every square centimeter
like that.  But empty warehouses can't afford automation.


Site Timeline