[Secter 0]

Но это плохой вариант, в отличие от предыдущего...

)))) ...неее, так у Вас дело не пойдёт...))) ...реверсивный, есть апгрейд первого варианта со сбросом... :laughing: ...призванный компенсировать нерасторопность механики манипулятора в целях уменьшения пустых пробегов конвейера...а сброс в бункер никто не отменял!

[VCucumber 0]

Почти боевые условия, видимая область всего в полтора раза больше. Нужно бы еще ближе, но и так объектив уже вываливается и на сопли приделан:

 

 

Векторизация по градиенту:

 

 

 

реверсивный, есть апгрейд первого варианта со сбросом

Не надо реверсивный, надо инверсивный. Т.е. эсэмдешки должны не по внешней поверхности конвейера ползать, а по внутренней.

 

[jeka 0]

При виде такой кучи появляется интересная мысль про создание карты высот. Не надо забывать, что мы можем управлять камерой (и источниками света, если понадобится) как захотим. То есть простым перемещением камеры, и при этом отслеживая скорость перемещения градиентов, нетрудно рассчитать высоту.

 

[VCucumber 0]

Интересно, что примерно правильным образом лежит не более 1% резисторов.

 

Логично было бы использовать стереоосвещение и далее распознавать трехмерные объекты по _стереоизображению_. Однако в инете на эту тему абсолютная тишина.

Второй вариант - использование трехмерной модели компонентов и дальнейшее сравнение ее вариантов проекций с изображением с камеры. Но ресурсов это утянет.

 

[jeka 0]

В реальности предполагается что компоненты больше рассредоточены по поверхности и не лежат кучей. В рассредоточенной области процентов 30 компонентов должно лежать правильно.

Если же встречается свалка компонентов, то можно рассредоточить либо руками, либо вибрацией, либо инструментом - уцепить что получится из центра кучи и сбросить неподалеку.

[IGK 0]

Напомнило институт... Я участвовал тогда в работе по созданию сортировочной машины. Надо попытаться вспомнить, как их правильно перевернуть. Если вспомню - напишу.

Всплыло из памяти, С.Лем "Эдем" - там описывалось, что лоток с деталями трясся и они непонятным образом укладывались рядами. Вот так и было, микровибрация и сброс в накопитель лежащего кверх ногами. Правда, детали тогда у нас покрупнее были. Вибрирующий лоток, чтобы детали легли в один слой. С наклоном. На выходе просто выталкивали не так лежащие на второй круг. Помню, целый курс возились, пока не заработало. Систему зрения тогда писали на ЕС-1035 :-), сейчас тот парень профессор.

Заглянул в коробку с 0805. Что-то у меня больше правильно лежит. Стукнул по донышку, стало меньше :-)

Интересная тема. Себе такой же хочется.

 

[VCucumber 0]

В принципе, с кинематикой сегодня я определился, что радует. Хочется какой-то рабочий софт.

 

По распознаванию. Не известно, насколько будет работоспособно, но с прицелом на аппаратную реализацию можно бы попробовать такой вариант. В основном все элементы черно-белые, поэтому цветовая составляющая нам не нужна. Поэтому входной видеопоток переводим в серый. 480*480 230К. Наверное можно даже 4бита - 115К. Преобразуем в градиенты (монохром). Дальше ксорим с паттерном (который тоже в градиенте) и считаем сумму установленных бит. Этакая пародия на сумму наименьших квадратов. Результат записываем на место анализируемого пикселя. Хотя нам не нужно знать, где располагается каждый компонент, достаточно знать, где располагается несколько наиболее определившихся, поэтому достаточно иметь короткий массивчик с тремя координатами - X, Y, A.

 

Изменено 2 февраля, 2012 пользователем Огурцов

[VCucumber 0]

Первый третий блин:

 

 

25 секунд. Предыдущий вариант считался минут десять. А первый - вообще бы неизвестно сколько. Есть вероятность, что при переходе от 8bpp к монохрому будет раз в 8 быстрее. 3 секунды - это уже более менее терпимо.

Но это все без градиентного фильтра - даже не знаю, как его реализовать, если градиент будет вычисляться по двум измерениям.

 

зы: не, монохром сделать будет слишком сложно, придется сдвигать все изображение по биту, так что в результате будет работать наверное даже медленнее, чем сейчас.

Как вариант - сделать предварительный поиск подходящих областей по картинке с меньшим разрешением, после чего - уточняющий, детальный поиск внутри их.

ззы: есть такая либа Open Source Computer Vision Library http://ru.wikipedia.org/wiki/OpenCV которая используется в проекте, который был приведен выше.

 

Изменено 5 февраля, 2012 пользователем Огурцов

[Demeny 0]

А смысл сейчас - париться с распознаванием ?

Если для конденсаторов всё равно прикручивать измерительный пинцет, то не проще ли им же и сопротивление мерять ?

[_pv 74]

А смысл сейчас - париться с распознаванием?

да и элементы сваленные в кучу друг на дружку, а не лежащие один слоем тоже сомнительно выглядят.

один механизм захвата как попало лежащего резистора чего стоит.

 

зы

выводы резисторов слегка магнитятся, то есть если рассыпать их на тонкую пластинку, под которой будет периодически намагниченный магнит (смена полярности через несколько мм) то большинство еще и по углам распределяться правильно с точностью до 180 град.

 

ззы этой ссылки тут вроде еще не было:

http://www.marsohod.org/index.php/projects/138-cloning

[VCucumber 0]

А смысл сейчас - париться с распознаванием ?

 

Это потому, что :

 

элементы сваленные в кучу друг на дружку

 

 

Кстати, в предыдущем варианте время нужно умножить на 360 (зависит от круговой точности, 256 тоже должно хватить). Ну так минуток 180 на поиск одного компонента потребуется )))

 

[Demeny 0]

Но в кучке-то элементы одинаковые ... поэтому, если распознавать номинал - то один раз для кучки.

Думаю, рассыпать элементы по кучкам несложно - поэтому это несущественное ограничение.

 

Другое дело - распознать ориентацию элемента в пространстве (поворот, наклон), тут все проще и быстрее должно быть.

[VCucumber 0]

Совершенно наоборот. Основное время займет поиск координат элемента в поле 640x480 (хотелось бы больше, но нормальные камеры дорогие, и время обработки тоже поджимает, оно в 4й степени от линейного разрешения). После того, как координаты будут найдены, потребуется обработка поля 96x80 (сейчас), что в полсотни раз быстрее и при абсолютно любых алгоритмах OCR будет не хуже.

 

зы: кстати, OCR - O. Chip R. тоже ;

 

[VCucumber 0]

 

Инвертировал алгоритм (маску с источником) плюс сделал обработку на базе полутоновго изображения, что избавило от векторного преобразования (все равно не понятно, что с векторами делать). Время увеличилось раза в полтора, в зависимости от внутреннего масштабирования (и качества) от 45 (оптимально) до 90 секунд. При уменьшении размеров изображений в два раза время уменьшается примерно до 2х..3х секунд, как раз 1/N^4 - было бы терпимо, если бы не нужно было определять угол поворота. В общем какбэ в этом варианте тупик. Ускориться можно если уйти от виндовых типов и методов, либо уйти от брутфорса к какому-нибудь последовательному древовидному поиску в разных масштабах.

 

[SM 0]

Народ, не то мучаем! Сначала сделать надо девайс, который из заранее известных мест расставлял бы заранее известные компоненты, а уж потом...