[jcxz 244]

Теперь зная минимальную и максимальную протяженность мешка мы можем вычислить количество.

Интересно - каким образом?

Все эти попытки квантовать аналоговую функцию (коей является сумма частично лежащих друг на друге мешков) простыми способами - бесперспективна. имхо.

 

Разве не очевидно, что - простой пример:

Примем: длина мешка == X; имеем N мешков лежащих рядом и частично перекрывающих друг-друга (как на картинках выше) с общей длиной равной = L.

Если коэфф. перекрытия мешков составляет 0% (просто лежат рядом, впритык), то L == N*X.

Если коэфф. перекрытия составляет 10% (каждый мешок залезает на соседний на 10% своей длины), то L == N*X*0.9.

Если коэфф. перекрытия составляет 20% (каждый мешок залезает на соседний на 10% своей длины), то L == N*X*0.8.

...

Итого, при X==1м, N==10, получим значения L:

L==10

L==9

L==8

...

каким образом Вы сможете определить что всё это - одни и те же 10 мешков????

 

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

[OlegH 0]

Имхо, метод учета стоит выбирать только после того, как определены формальные ограничения на параметры мешков (вес, цвет, ...), их индивидуальное (ориентация) и взаимное размещение в зоне контроля, допустимость мешков разного товара и разного номинала веса рядом в одной куче и т.п. Без наличия таких ограничений, т.е. в условиях, когда все может быть как угодно, ни один метод учета не даст сколь-нибудь точного результата. Сначала определить удовлетворительные ограничения (либо создать искусственно, если имеющиеся неудовлетворительны) и формально их записать, потом искать метод, который будет в этих ограничениях работать...

[jcxz 244]

Имхо, метод учета стоит выбирать только после того, как определены формальные ограничения на параметры мешков (вес, цвет, ...), их индивидуальное (ориентация) и взаимное размещение в зоне контроля, допустимость мешков разного товара и разного номинала веса рядом в одной куче и т.п. Без наличия таких ограничений, т.е. в условиях, когда все может быть как угодно, ни один метод учета не даст сколь-нибудь точного результата. Сначала определить удовлетворительные ограничения (либо создать искусственно, если имеющиеся неудовлетворительны) и формально их записать, потом искать метод, который будет в этих ограничениях работать...

Категорически согласен!!!

Это называется - Написать детальное ТЗ.

[Andrey_B 0]

Категорически согласен!!!

Это называется - Написать детальное ТЗ.

 

Спасибо всем. Как раз утрясаем ТЗ с заказчиком, по итогам примем решение по реализации.

 

[OlegH 0]

С одной стороны, врядле заказчик так продвинут, чтобы написать такое ТЗ самостоятельно (иначе б уже написал, а для этого надо иметь в этом опыт и владеть методологией создания работающего технического решения на базе выявленной потребности, хотя бы интуитивно), с другой стороны, никто, кроме ТС, такое ТЗ не составит, потому что для этого надо быть на месте и дышать с автоматизируемым процессом одним воздухом. Поэтому ТС должен выбрать исполнителя, который владеет искусством "доведения до результата" (если, конечно, потребность реально серьезная), и работать плотно с ним. Уверен, ТС и сам это понимает ) и если не выбрал, то просто хочет идей на халяву (т.е. ничего заказывать не будет), или просто не сильно надо.... Черт, дедукция - страшная вещь ;-)

[SVNKz 3]

Нужно разработать ТЗ.

Предлагается для примера во вложенном файле.

Это только некоторая малая часть общего текста докумета. Время на разработку, согласование и утверждение ТЗ около одного месяца. Затраты до 25% от общей стоимости разработки.

"Поэтому ТС должен выбрать исполнителя, который владеет искусством "доведения до результата" (если, конечно, потребность реально серьезная), и работать плотно с ним. Уверен, ТС и сам это понимает ) и если не выбрал, то просто хочет идей на халяву (т.е. ничего заказывать не будет), или просто не сильно надо.... Черт, дедукция - страшная вещь ;-)" - OlegH

____________2.doc

Изменено 20 ноября, 2014 пользователем VNS

[SVNKz 3]

Спасибо всем. Как раз утрясаем ТЗ с заказчиком, по итогам примем решение по реализации.

ТЗ не "утрясают", а разрабатывают. Это серьёзный документ, по разделам которого исполнитель будет разрабатывать алгоритмы и программировать электронные блоки, а заказчик, в случае соответствия разработанного ТЗ, будет принимать и оплачивать работу. Несерьёзный подход участвующих в разработке сторон ВСЕГДА приводит к неопределённости и хаосу самого процесса разработки...

Изменено 20 ноября, 2014 пользователем VNS

[Гость TSerg]

Еще раз вдумчиво смотрим на Сообщение #13 и еще несколько последующих аналогичных и понимаем, что это надежное и относительно дешевое решение.

 

[SVNKz 3]

Еще раз вдумчиво смотрим на Сообщение #13 и еще несколько последующих аналогичных и понимаем, что это надежное и относительно дешевое решение.

Согласен с надёжностью, но алгоритм работы будет достаточно сложен. Аппаратная часть относительно доступна.

 

[WitFed 1]

А почему нет фоток собственно мешков из практики, 10 раз подряд по-разному лежащих на транспортёре во всех возможных позах, Видъ Сверъху ? ТС давно бы уж постоял рядом и нащёлкал ситуации, подминающие нужные 99 % ;)

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

Девайс сейчас копейки стоит, санкциями не грозит, смотрящий вниз объектив не запылится, софтину легко скопировать, если вдруг сопрут, размножить на кучу транспортёров, и любой студент справится за 10 тыров с задачей подсчитать среднее по кадру и слепить до кучи пикселы с цветом выше среднего, сравнить сумму с площадью одного мешка, прикинуть, где было это пятно в прошлом кадре... И передавать свои замеры хозяину по ВайФаю в рилтайме !

+ обязательно нужно механическое упорядочивание -- шторки, ворота, тремор для укладки "на спину", пусть производители транспортёра этим озаботятся. Кстати, именно они и могли бы считать тягаемые грузы в "продвинутых" версиях ! Без механики никакой ИИ и все НИИ+КБ страны не догонят даже мышу в распознавании ситуаций !

Если мешки будут течь выровненными, надписи на них читать будет удобней -- САХАР там, МУКА и пр. Цвет хотя бы. Про штрих-коды на упорядоченно проползающих мешках не говорю -- кто, когда и что выработал для 1С, это оставим 22 веку ;) Правда, как нам доставка 50 кг сахара привозит домой, то надпись только с одной стороны -- так дешевле, а грузчиков заставить держать орднунг в наших условиях демократии -- невозможно аксиоматически, оттого наука и развивается ;)

Студента, конечно, придётся взять потом на полставки грузчиком для поддержки ПО. И если что не так -- пусть подвигает предметы своего учёта с полчаса на транспортёр и с него.. ;)

Но если выйдет ПО нормальное и не особо защищённое от копирования -- все наши склады ему памятник поставят !

[AndreyMK 0]

Хм... Прям дежа-вю какой-то со мной случился...

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

 

Мы решили эту задачу, потратив 2000 долл.

 

1. UHF RFID метка на каждый мешок (самая дешёвая, нужен только TID раздел метки).

2. Стационарный считыватель, антенна которого направлена на транспортер.

Считыватель взяли с WiFi модулем, чтобы провода не тянуть.

3. Простенькая программа на компе (1 человеко/час разработки).

 

Работает уже 5 лет в Краснодарском крае.

 

Метки купили в силиконовой оболочке, предназначенные для прачечных (выдерживают кипячение 20 мин).

Голубенькие такие, размером с пластинку жвачки.

Метки за угол крепил дядя к углу мешка степлером еще на складе. Задача-то была на одну операцию.

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

Стационарный считыватель UHF диапазона читает метку, в зависимости от антенны, с расстояния 3-7 метров.

Главное, чтобы не экранировалась металлом. Поэтому антенну ставили под углом к транспортеру.

 

Возможно и для вас это решение годится.

 

Добавлю - метка стоила в то время 7 руб.

Считыватель меток - 650 долл.

Изменено 20 ноября, 2014 пользователем AndreyMK

[jcxz 244]

Еще из идей: лазерный сканер дистанции с ориентацией вертикально вниз. Снимается профиль и по вершинам считается число мешков. Мешок на мешке тоже, кстати, идентифицируется.

Еще раз вдумчиво смотрим на Сообщение #13 и еще несколько последующих аналогичных и понимаем, что это надежное и относительно дешевое решение.

Блин, опять 25.... :smile3046:

Внимательно смотрим на картинку и считаем. Так сколько вершин? 2? А может 3? А может 4? А может всё-таки 1?

И сколько мешков? Определите.

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

 

смотрящий вниз объектив не запылится,

Что такое "электростатичесий заряд" в школе изучали? ;)

 

Мы решили эту задачу, потратив 2000 долл.

1. UHF RFID метка на каждый мешок (самая дешёвая, нужен только TID раздел метки).

...

Имхо - самое надёжное и очевидное решение задачи. Я ещё в самом начале треда его предлагал.

[Elsystems 0]

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

[SVNKz 3]

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

Лазерный сканер и фотодатчик могут в комплексе выполнять функции видеокамеры. Существуют алгоритмы, которые определяют контуры мешков как области на картинке и уберут всевозможные помехи изображения. Далее идёт логический анализ по количеству областей, их площади и их взаимном расположении. Процедуру отладки алгоритма можно провести, например, в MathCad путём анализа серии фотографий конвеера.

[WitFed 1]

А фотка разве покажет расстояние ?

И лазер может сканировать всё пространство поворотной головкой ?

К нему же надо потом тулить "автомат автосопровождения мешка" на процессоре/ПЛИС, связь с БД,.. что в смартфоне уже встроено за 3 тыра.

Если просвечивать только одно направление "строго вниз" по центру, то 2 слитных мешка, едущих поперёк, распознаются как 1.

 

...Вообще, в нашем "радике" издревле была специальность "Гидроакустика", там эхолоты показывают рельеф дна без проблем на гораздо больших скоростях звука в воде, так что нечто подобное звуковой головкой можно и к мешкам привязать -- вместо "слепого" поставить "глухого" робота ! И выгравировать тип содержимого, если его нельзя будет по плотности отражения вычислить ;)