Comments 36
У мышиного сенсора есть очень существенный недостаток (ADNS2610).
На первый взгляд, интерфейс вытаскивания изображения по весьма приличной тактовой частоте должен был дать весьма хорошее количество кадров в сек. Но… дьявол крылся в деталях.
Фраза в документации на ADNS2610 по поводу 6-го бита данных
"Data_Valid There is valid data in the frame grabber" была не с проста!
Пытаясь задействовать в своем проекте (то же распознование, но попроще, фиксированных пиксельных кодов), с удивлением и разочарованием наткнулся на то, что фактическая частота кадров ВСЕГДА около 4.67 кадра в сек.
Выше SCK — больше байт идет с 6-м битом "не валидные данные".
А 4.67 кадра — вообще ни о чем. Быстрое сканирование не получится.
У меня даже результаты с разным SCK зафиксированы в исходниках.
// 18x18 image scan:
// 0.214s 1008..1012 lostCnt(ADNS2610_delay = 110us, CLK_halfDelay = 8)
// 0.214s 691..701 lostCnt (ADNS2610_delay = 100us, CLK_halfDelay = 20)
// 0.214s 517..520 lostCnt (ADNS2610_delay = 100us, CLK_halfDelay = 30)
// 0.214s 377..380 lostCnt (ADNS2610_delay = 150us, CLK_halfDelay = 30)
// 0.214s 52..54 lostCnt (ADNS2610_delay = 100us, CLK_halfDelay = 100)
// 0.214s 39..41 lostCnt (ADNS2610_delay = 120us, CLK_halfDelay = 100)
// 0.218s 0..1 lostCnt (ADNS2610_delay = 200us, CLK_halfDelay = 100)
ESP8266 вполне может работать самостоятельно, без дуины, а здесь даже пинов хватает.
Сразу хочу оговориться, что в данной статье не будет приведен исходный код, рассматриваться технология или алгоритм распознавания
То есть рекламная статья?
С радостью ответим на вопросы.
Да вы первым же абзацем урезали по самое небалуй возможность задавать вопросы :)
Теперь вот только один интересующий вопрос остался из всех — а зачем вам этот девайс? Ну, кроме как для того чтобы убедиться, что на ардуине это возможно.
А, и еще один — а распознается цифра, повернутая на 45 градусов? На 90? На 180?
Касательно вопроса про поворот: не проводили таких исследований, так как изначально задача стояла распознавание на микроконтроллере хоть при каком нибудь угле.
А по алгоритмы вы разве не можете сказать распознаются ли повернутые на произвольный угол цифры? Сам алгоритм это предусматривает?
У счетчиков, например, обычно есть импульсный выход.
Может я неверно интерпретировал подтекст, но у меня сложилось впечатление, что вы таки подумываете о серийном применении.Нет?
Но в целом проект концептуально интересный. Вы показали что на дешевом МК можно распознавать символы. Это здорово.
Несмотря на привлекательность распознавания образов на дешевом контроллере, тут видится более рациональным применение камеры и дешевого одноплатника типа RPi и без подвижных частей.
И еще один момент есть — если ваши счетчики работают в сфере госрегулирования (например бытовые счетчики воды), то и ваш прибор (он будет считаться устройством сбора и передачи данных) окажется в сфере госрегулирования, а значит скорее всего подлежит внесению в госреестр как средство измерений, и должен проходить первичную и регулярную поверку. А это всё недешево.
В теории все выходило хорошо, а на деле столкнулись с трудностями — цифры на лимбах различались по написанию, лимбы загрязнялись, из-за убитой механики изображение выходило из фокуса и т. д., пришлось уже на полигоне для каждого теодолита вводить свои поправочные коэффициенты в работу с эталонными масками. Система работала (большей частью удовлетворительно), была утверждена и поставлена на поток. Разработчик предлагал доработать для лучших результатов (хотя бы заменить ПЛИС на более мощную), но для этого нужны были средства и нам сказали что-то типа «и так сойдет».
Через несколько лет стали доступны хорошие абсолютные датчики угловых положений и после долгих «боданий» убедили-таки руководство перейти на них.
Раз уж статья называется «Распознавание цифр на микроконтроллере», то хотя бы название метода распознавания скажите. А то немного не то ожидаешь увидеть открывая такою статью.
В текущем виде статья не предоставляет никакой информации о техническом решении. Вся суть сводится к одному предложению: "мы пытаемся распознавать на ардуинке и иногда это получается".
Особые вопросы вызывает вот эта фраза:
Приложение на планшете отправляет запрос, «ардуинка», получая запрос, «снимает» изображение с сенсора мыши, затем бинаризует его. После бинаризации происходит распознавание, а после его завершения формируется ответ.
Собственно, неясно, где таки проходит само распознавание и, если бинаризация на планшете, то к чему распознавание на микроконтроллере? Возможно будь в статье краткая информация о сути проекта — это было бы очевиднее.
Куча фоток железа, ни слова хотя бы о методах распознавания, скорости распознавания и его качестве.
Подозреваю, что это — написать софт — вообще только в планах, но застолбить статью хочется.
Единственное полезно применение такого устройства — увидеть в дальнем углу цифры счетчика (например воды) и красиво подсветить цифры.
Если работать с картинкой, гораздо проще передавать с Дуины изображение и распознавать на Андройде. Благо, там вычислительных возможностей на два порядка больше
А вообще, статья без алгоритмов и исходников очень похожа на хвастовство. Или рекламу.
http://www.slovary.ru/itemdet.php?item_id=118
???
Должен отметить что распознавание (OCR) на микроконтроллерах вещь хоть и не самая популярная, но совершенно реальная. Я в своих проектах делаю это именно на микроконтроллерах в реальном времени, с жесткими ограничениями по ресурсам. Распознавание символа за 10...100мкс на микроконтроллере за USD10 — реальность.
Жаль что заказчиков на подобные разработки найти сложно… наверное это действительно, мало кому нужно.
Отмечу что в реальных условиях как правило больше ресурсов уходит на подготовку образа к распознаванию чем само распознавание. Например, борьба с линейными и нелинейными искажениями, поворот и пр. Иногда соотношение времязатрат на подготовку к времязатратам на распознавание может быть 10:1.
Hamster во всем!
— Действительно — захомячить суть самой статьи.
Распознавание цифр на микроконтроллере