UPD: Есть видео демонстрация.
Как видно из названия речь в этой статье пойдет о распознавании цифр на микроконтроллере. Сразу хочу оговориться, что в данной статье не будет приведен исходный код, рассматриваться технология или алгоритм распознавания, скажу лишь, что используются идеи системного подхода. Некоторые из них изложены в наших статьях (здесь, здесь и вот здесь). Это связано с тем, что наш подход тянет на оригинальность, но требует уточнения некоторых вопросов. Кто-то может сказать: «очередная статья про программирование микроконтроллеров». Отнюдь нет, поиск подобных проектов не дал каких-то внятных результатов, за исключением этого видео. Из обсуждений на форумах понятно одно: идея получения подобного устройства (камера + микроконтроллер = результат распознавания на выходе, а не просто снятая картинка) приходила многим, но оставалась без реализации. Да и распознавание, по общему мнению, требует много вычислительных ресурсов и микроконтроллеры для этого не подходят, в частности про Arduino были высказывания, что это вообще невозможно. Если стало интересно прошу под кат.
Что бы не возникало очевидных вопросов, ответим на них:
- Нет, это не сервис по распознаванию изображений
- Нет, это не OpenCV
- Нет, это не нейронные сети
- Используется морфологический анализ объектов из которых состоит цифра
- Да, распознавание производится именно микроконтроллером!
Идея
Если кратко, то все началось с того, что было желание попробовать свои силы и проверить свои идеи в распознавании изображений. В процессе обсуждения пришли к выводу, что можем обойтись небольшими вычислительными мощностями для решения данной задачи. По понятным причинам подробности этих обсуждений описывать не будем.
Установка
Итак, задача поставлена, нужна реализация. Не отступая от уже устоявшихся принципов
берем то, что есть под рукой. А было под рукой парочка Arduino Uno, старая оптическая мышь и CD привод. Кстати, на то что бы использовать сенсор оптической мыши в качестве камеры для получения изображения нас натолкнула статья прочитанная когда то давно, ну и собственно весь остальной около «мышиный» материал. Единственное нам пришлось выпаять сенсор и всю его обвязку для удобства использования, а также приклеить к нему линзу, которую мы бережно «выдрали» из CD привода. Это было нужно для того, что бы увеличить расстояние от объекта съемки до камеры иначе цифры нашего размера не помещались и была видна лишь небольшая часть. Кстати говоря перед линзой из CD привода, мы пробовали прикрепить оптику от веб камеры, но как-то не срослось.
Затем встал вопрос как эту камеру позиционировать над объектом съемки. Тут нам очень помог старый сломанный микроскоп, который лежал без дела. С уважением сняли с него механизм управления предметным столиком. Этот механизм нам позволил перемещать камеру лишь по двум осям, тут же пришла мысль использовать направляющую лазерной головки от CD привода. Все это закрепили на корпусе от многострадального CD привода. В итоге мы получили классный механизм позиционирования камеры.
Итого: так называемая камера у нас есть, механизм позиционирования есть, осталось положить бумажечку с циферкой и получить изображение с камеры. Тут то и начались «проблемы». Так как характеристики «мышинного» оптического сенсора весьма скудны для использования его в качестве камеры, стали импровизировать с подсветкой.
Стало понятно, что просто подсветить не получиться важна интенсивность, направление внешний свет тоже вносит коррективы. Пришлось включать в работу еще одну «ардуинку», что бы управлять интенсивностью подсветки ( естественно можно было и по другому управлять, но в последствии и не только подсветкой, а еще переключением цифр на индикаторе). В итоге оказалось, что съемка на просвет гораздо лучше. А если например использовать в качестве цели светящийся семи сегментный индикатор то сенсор его видит вообще отлично. Так, что теперь у нас в качестве объектов съемки индикатор и полоса с белыми цифрами залитая черным фоном.
слева изображение в градациях серого полученное с индикатора (такое изображение мы получаем с сенсора), справа бинаризованное.
Общий вид установки в сборе
Блок распознавания
Немаловажную роль в нашей установке играет, так называемый блок распознавания (на картинке выше). Как видно, он состоит из Arduino Uno и всем известного wifi передатчика ESP8266. Поясняю, wifi передатчик нам нужен для того, что бы результат распознавания увидеть на планшете. Приложение на планшете отправляет запрос, «ардуинка», получая запрос, «снимает» изображение с сенсора мыши, затем бинаризует его. После бинаризации происходит распознавание, а после его завершения формируется ответ. В ответе мы посылаем результат распознавания и 41 байт для построения бинаризованного изображения на экране планшета, так сказать, для наглядности.
Если оглянуться, то на «на ардуинку» возложен неплохой функционал: и работа с камерой, и распознавание, и работа с esp8266. Что не могло не отразится на работе — пришлось бороться с нехваткой памяти. Вот уж не думал, что когда либо придется отвоевывать каждый байт памяти.
Демонстрация процесса распознавания
Вместо заключения
На этом собственно и все. Впереди еще очень много работы. И первая задача: распознавание чисел (строки цифр) снимаемых «человеческой» камерой (а не «мышиным сенсором») и переносом разработанной технологии на ESP8266 и снижением накала борьбы за каждый байт памяти.
С радостью ответим на вопросы.
Комментарии (36)
SopaXT
29.08.2016 12:37+1ESP8266 вполне может работать самостоятельно, без дуины, а здесь даже пинов хватает.
KonstantinSoloviov
29.08.2016 15:53+1Они оба... могут! )
Andy_Big
29.08.2016 12:37+1Сразу хочу оговориться, что в данной статье не будет приведен исходный код, рассматриваться технология или алгоритм распознавания
То есть рекламная статья?
С радостью ответим на вопросы.
Да вы первым же абзацем урезали по самое небалуй возможность задавать вопросы :)
Теперь вот только один интересующий вопрос остался из всех — а зачем вам этот девайс? Ну, кроме как для того чтобы убедиться, что на ардуине это возможно.
А, и еще один — а распознается цифра, повернутая на 45 градусов? На 90? На 180?
LRpro
29.08.2016 12:59Конкретно этот девайс для тестирования, а так например можно разработать устройство считывания показаний со счетчиков, например.
Касательно вопроса про поворот: не проводили таких исследований, так как изначально задача стояла распознавание на микроконтроллере хоть при каком нибудь угле.
Andy_Big
29.08.2016 13:10Просто предложение "Это было нужно для того, что бы увеличить расстояние от объекта съемки до камеры иначе цифры нашего размера не помещались и была видна лишь небольшая часть." наводит на мысль, что у вас была конкретная цель.
А по алгоритмы вы разве не можете сказать распознаются ли повернутые на произвольный угол цифры? Сам алгоритм это предусматривает?
ncix
30.08.2016 10:00>> а так например можно разработать устройство считывания показаний со счетчиков, например
У счетчиков, например, обычно есть импульсный выход.LRpro
30.08.2016 10:29Скажем так не у всех видов счетчиков есть импульсный выход.
ncix
30.08.2016 10:49Верно. Но не будет ли дешевле заменить счетчик чем ставить распознаватель? Тем более описаное решение из-за механики вглядит сложным и дорогим в серийном производстве.
Может я неверно интерпретировал подтекст, но у меня сложилось впечатление, что вы таки подумываете о серийном применении.Нет?
Но в целом проект концептуально интересный. Вы показали что на дешевом МК можно распознавать символы. Это здорово.LRpro
30.08.2016 11:11Хм, а в чем собственно дороговизна, на Ваш взгляд?
ncix
30.08.2016 11:31Приводы, механика, десятки деталей. Это навскидку будет вам стоит не одну и не две тысячи рублей в производстве при средних партиях. Да и конструкцию придется долго отлаживать, пока она станет достачной надежной. Т.е. это целесообразно если мы говорим не о бытовых счетчиках а о каких-то дорогих высокоточных приборах (которые давным-давно все оснащаются цифровыми выходами).
Несмотря на привлекательность распознавания образов на дешевом контроллере, тут видится более рациональным применение камеры и дешевого одноплатника типа RPi и без подвижных частей.
И еще один момент есть — если ваши счетчики работают в сфере госрегулирования (например бытовые счетчики воды), то и ваш прибор (он будет считаться устройством сбора и передачи данных) окажется в сфере госрегулирования, а значит скорее всего подлежит внесению в госреестр как средство измерений, и должен проходить первичную и регулярную поверку. А это всё недешево.LRpro
30.08.2016 11:42Хм, а с чего вообще Вы взяли, что должна быть какая-то механика? Достаточно микроконтроллера и камеры. Сенсор мыши мы применять не собираемся, ибо это нецелесообразно. И перемещать камеру или сенсор над каждой цифрой нет никакого смыла. В статье это всего лишь установка для удобства.
ncix
30.08.2016 11:57бОльшая часть статьи именно про механику и сенсор мыши, а это оказываетс описание тупикового этапа разработки.
Хотелось бы тогда прочитать про сопряжение реальной камеры с ардуинойLRpro
30.08.2016 12:16Можно и так сказать. Надо же было на чем то отлаживать. Думаю эта статья не последняя на тему распознавания.
Shpakov
29.08.2016 12:49+3Напомнило: в начале двухтысячных делали для военных полигонов модернизацию теодолитов для угломерных измерений (использовались для построения траекторий объектов, исходные теодолиты снимали на пленку). В связи с ограниченным бюджетом и требованием военных о сохранении возможности обратной переделки решение было принято такое — внутрь теодолитов устанавливались камеры, основная для съемки объекта (использовала оптику теодолита) и две вспомогательные, снимающие изображение напрямую с лимбов. Изображение с лимбов обрабатывалось на ПЛИС EP2C5 (второй циклон) и полученные данные скидывались в одном потоке в накопитель. Для распознавания использовалось наложение эталонных масок на изображение цифры и решение принималось по количеству пересечений с маской.
В теории все выходило хорошо, а на деле столкнулись с трудностями — цифры на лимбах различались по написанию, лимбы загрязнялись, из-за убитой механики изображение выходило из фокуса и т. д., пришлось уже на полигоне для каждого теодолита вводить свои поправочные коэффициенты в работу с эталонными масками. Система работала (большей частью удовлетворительно), была утверждена и поставлена на поток. Разработчик предлагал доработать для лучших результатов (хотя бы заменить ПЛИС на более мощную), но для этого нужны были средства и нам сказали что-то типа «и так сойдет».
Через несколько лет стали доступны хорошие абсолютные датчики угловых положений и после долгих «боданий» убедили-таки руководство перейти на них.
masai
29.08.2016 12:50Раз уж статья называется «Распознавание цифр на микроконтроллере», то хотя бы название метода распознавания скажите. А то немного не то ожидаешь увидеть открывая такою статью.
LRpro
29.08.2016 13:06Метод претендующий на оригинальность, можно отнести к омнифонтовому морфологическому методу.
APaMazur
29.08.2016 12:55+2В текущем виде статья не предоставляет никакой информации о техническом решении. Вся суть сводится к одному предложению: "мы пытаемся распознавать на ардуинке и иногда это получается".
Особые вопросы вызывает вот эта фраза:
Приложение на планшете отправляет запрос, «ардуинка», получая запрос, «снимает» изображение с сенсора мыши, затем бинаризует его. После бинаризации происходит распознавание, а после его завершения формируется ответ.
Собственно, неясно, где таки проходит само распознавание и, если бинаризация на планшете, то к чему распознавание на микроконтроллере? Возможно будь в статье краткая информация о сути проекта — это было бы очевиднее.
defecator
29.08.2016 13:28+1Статья, имхо, ни о чём от слова совсем.
Куча фоток железа, ни слова хотя бы о методах распознавания, скорости распознавания и его качестве.
Подозреваю, что это — написать софт — вообще только в планах, но застолбить статью хочется.LRpro
29.08.2016 13:29По видео демонстрации можно составить примерное представление о скорости распознавания.
sav13
29.08.2016 13:57Зачем там городить ESP-шку? И Андроид?
Единственное полезно применение такого устройства — увидеть в дальнем углу цифры счетчика (например воды) и красиво подсветить цифры.
Если работать с картинкой, гораздо проще передавать с Дуины изображение и распознавать на Андройде. Благо, там вычислительных возможностей на два порядка больше
А вообще, статья без алгоритмов и исходников очень похожа на хвастовство. Или рекламу.
BubaVV
29.08.2016 19:14+1В давние времена на Palm OS работало распознавание рукописного ввода с процессором 16 МГц и 128 Кб памяти. Лагов на глаз заметно не было. Алгоритм работы лично для меня не очень понятен, информации по потрохам системы почти нет
tnt23
29.08.2016 20:38Там было не распознавание рукописного ввода, а распознавание определённых закорючек (глифов), по начертанию с некоторой фантазией напоминающих буквы.
Настоящее распознавание рукописного ввода было на Newton.
MinamotoSoft
30.08.2016 09:42пытаетесь создать конкуренцию
http://www.slovary.ru/itemdet.php?item_id=118
???
Sylvan
30.08.2016 11:03+1спасибо за статью
Должен отметить что распознавание (OCR) на микроконтроллерах вещь хоть и не самая популярная, но совершенно реальная. Я в своих проектах делаю это именно на микроконтроллерах в реальном времени, с жесткими ограничениями по ресурсам. Распознавание символа за 10...100мкс на микроконтроллере за USD10 — реальность.
Жаль что заказчиков на подобные разработки найти сложно… наверное это действительно, мало кому нужно.
Отмечу что в реальных условиях как правило больше ресурсов уходит на подготовку образа к распознаванию чем само распознавание. Например, борьба с линейными и нелинейными искажениями, поворот и пр. Иногда соотношение времязатрат на подготовку к времязатратам на распознавание может быть 10:1.
Psychosynthesis
02.09.2016 05:05Ну, вы молодцы, но спасибо не скажу, ибо никакой инфы из статьи вынести невозможно.
mmMike
У мышиного сенсора есть очень существенный недостаток (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)