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

My favorite economist joke: Two efficient-market theorists were walking down the road. One said "Look, there's a ten-dollar bill in the road." The other said "It can't be. If it were a ten-dollar bill, somebody would have picked it up."

Mel.

Reply to
Mel Wilson
Loading thread data ...

Horses weren't an existing market for pumping water out of coal mines?

Horses, barges, boats and backs weren't an existing market for moving people and goods long distances?

Trains and horses weren't an existing market for moving people locally?

Shouting loudly wasn't an existing market for transmitting information long distances?

Vacuum tubes weren't perfectly good for transmitting information long distances, and performing computations?

Transistors weren't perfectly good for transmitting information long distances, and performing computations?

Plain old paper mail wasn't perfectly good for disseminating text and personal messages long distances?

Yup -- I guess you're right. None of those things that I mentioned had existing market solutions, and they all sprang whole out of the minds of their respective inventors.

Question: Every morning you must wake up and think "if it were worthwhile to be up, I'd be up by now". How do you get to your computer (useless invention that it is), to make your wise pronouncements?

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
 Click to see the full signature
Reply to
Tim Wescott

I consider it more sensible to place any location coding markers on the floor or on intermediate stanchion posts. Using a sort of Bar-Code plate marker with the coded position reference for that marker will help individual AGV's know where they are. [%X]

I picked up a couple of cameras from Maplin Electronics for a mere £10 each not so long ago. They were mounted with Infra Red LEDs for low light illumination too.

The one I am playing with for my binocular vision system is the green Arrays GA144. I am planning on implementing something like Canny Edge Detection and Scene Resolution algorithms across a number of the cores. However, I am sure that if you are not comfortable with Meshed Parallel Forth Engines then you could try with one of the ARM based boards with similar software. Note that when I say I am playing with this, the project is a personal fun one and is only progressed as and when I have some spare time to work on it.

I leave comments on those to others.

--
********************************************************************
Paul E. Bennett...............
 Click to see the full signature
Reply to
Paul E. Bennett

And inbetween the bar code markers, the vehicle could track its movement by looking at scratches and dirt on the floor, like a giant optical mouse. :)

Reply to
Arlet Ottens

I will proceed in chronological order of your replies.

1) @Tim: I completely agree that the specifications were incomplete and as soon as I read your post, we began a hunt for a good-but-economical camera. After going through a number of board cameras and USB-cameras (which can also be considered as an option if we go for an OS-based processor with UVC drivers). After finalizing our minimum requirements and expectations, we have decided to go for 10 fps, 1024 X 768 or 640 X 480 pixel images, pixel size can be as big as 10 micrometer, on-board intensity correction, RGB image.

2) @Mike Kellett: Yes, we are going to try it out on a PC first. Especially the algorithms for image processing. Thank you for the suggestion.

3) @Paul: The maximum speed of the AGV would be 1 m/sec (with load max. speed ~0.5 m/sec). As it would approach the target, the speed would reduce in order to make sure the processing can deliver the desired accuracy. As for using bar-codes/QR-codes - it is an excellent suggestion. Thanks a lot. We have to just see if it is an easier task to identify a bar-code/QR code from a distance of 20 m or a color marker with some letter/number inside it. With some experience, I am guessing the former will be easier. Moreover, it would permit the use of BW images.

Regarding safety, as I previously mentioned we have a safety system in place - tried and tested on a tape-navigation based AGV.

4) @Hans Bernhard: Regarding your doubts about the feasibility of the attempt to come up with a cost-effective alternative technology - we would try doing something new rather than not doing anything. Regarding your 'off the shelf system' observation - an undergraduate student working with me pointed out that off-the-shelf systems cover a variety of techniques all of which have their own advantages and disadvantages and none of which (used alone) guarantee the desired accuracy. Hence, comparing two altogether different systems on the basis of cost is not a fruitful activity. We don't have a cushion of money with us. So, we decided to try for a cost-effective technique. But, your view made us question our motive and brainstorm. So, thanks a lot.

5) @Hans Bernhard: We tested a 0.3 MP webcam from an elevation of 20 meters. It was able to capture an approximate area of 16 m by 12 m. That means, 12 cameras for 50 m by 50 m. As I mentioned above, we will be going for a much better camera. I shall keep you all posted about the number of cameras once we finalize a model. Also, we are now considering a camera on the AGV and markers overhead. Again, thanks for the insight.

6) @Paul: We are not considering markers on the floor because the clients have been very uncomfortable with the fact that our tape-navigation AGV was making their shop-floor look dirty. But, if the overhead markers don't work out, we will go with this as we already have worked on a similar system.

7) @Arlet: I could not understand the giant optical mouse comment. But, I like the idea all the same. :-)

@all: As for the camera details mentioned above, do you think this shall do the job? The vehicle will drop its speed as it nears the target in order to make sure the desired accuracy is achieved. Also, we can use a bit of interpolation in case the fps value is not sufficient. The color/BW choice shall be done after we test out the feasibility of the bar-code markers.

What other metrics shall help us choose the processor?

--------------------------------------- Posted through

formatting link

Reply to
sckulkarni246

An optical mouse uses a very small CCD camera (say 16x16 pixels maybe even 64x64) to look at the surface of the table. By comparing two consecutive images, it determines the relative motion.

To increase the contrast, you can use illumination by laser light.

Reply to
Arlet Ottens

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.

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.

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

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?

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?

Reply to
Hans-Bernhard Bröker

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

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.

If I am moving at 10% speed in the 'going to get better resolution than all those other systems, using worse

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.

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

formatting link

Reply to
sckulkarni246

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          | paul@pcserviceselectronics.co.uk
    PC Services
 Click to see the full signature
Reply to
Paul

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.
 Click to see the full signature
Reply to
Tim Wescott

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.