[retegor 0]

О нас: Москва, м. Кожуховская, IQ-park, robotgeeks.ru. Выпускаем электронику начального уровня сложности.
- Задача: Разработать встраиваемое ПО (STM32f407) для решения задач робототехнических соревнований аналогичных AutoNet 14+/18+ (распознавание знаков, разметки, номеров домов).
Разработка не с нуля, есть устройство, успешно решающее задачи распознавания цветных объектов, составных объектов, на устройстве в некоторой упрощенной форме работала FCWS, поиск номерных знаков авто. Есть переписанные и готовые к портированию на МК наработки по интегральным изображениям, методу Виолы-Джонса (на каскадах Хаара).
В выборе реализации вы свободны, хотелось бы получить более-менее универсальный функционал по обучению/распознаванию объектов, желательно с учетом цветовой информации.
Сложности: есть всего около 40 Кб свободной оперативной памяти.
Требование к качеству и быстродействию распознавания: их должно быть достаточно для уверенного участия в указанных соревнованиях, изначально нужно обучить все на объекты из регламента.
- Условия: работа по договору ГПХ, 100..200к руб на руки в зависимости от финального состава ТЗ (разработка либо голого модуля, готового к работе на МК, либо с API, сохранением параметров в памяти, прикладным ПО для обучения, настройки и т. д.).
- Требования: уверенность в результате, знание СТЗ, ориентирование в исходном коде OpenCV и готовность разбирать/переписывать его, опыт работы с МК в части ресурсоемких вычислительных задач.
- Контакты: Егор Девятериков, [email protected]. С радостью рассмотрю разные предложения и идеи.

Изменено 3 октября, 2018 пользователем retegor

[jcxz 184]

28 минут назад, retegor сказал:

- Условия: работа по договору ГПХ, 100..200к руб на руки в зависимости от финального состава ТЗ

В месяц?

[retegor 0]

5 hours ago, jcxz said:

В месяц?

Работа разовая по договору ГПХ с ТЗ. Если у вас есть идеи и вам нужно больше времени/ресурсов, дайте мне, пожалуйста, знать на почту.

[a123-flex 0]

On 10/3/2018 at 9:57 AM, retegor said:

С радостью рассмотрю разные предложения и идеи.

 

Предлагаю приписать два нуля к стоимости работ, и пять к объему свободной памяти устройства на камне с поддержкой opencv - возьмусь.

Жадность это отлично, но ценники у вас на сайте абсолютно конские, экономить на голове выйдет себе дороже.

 

Три китайских принтера по 11 тыр за 830 тыр... Наверно за ними очередь из бюджетников стоит ?

[twix 0]

On 10/3/2018 at 10:57 AM, retegor said:

Сложности: есть всего около 40 Кб свободной оперативной памяти.

Это на самом деле ключевое препятствие. Если писать на ассемблере, памяти просто навалом для всех Ваших вычислений. И скорость и прочее.

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

В остальном вполне себе задача...

[jcxz 184]

3 часа назад, twix сказал:

Если писать на ассемблере, памяти просто навалом для всех Ваших вычислений.

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

[Eusebius 0]

Вы уверены, что предлагаемое Вами железо адекватно поставленной задаче? Даже при разрешении 320х240 пикселей монохромное изображение займёт 320*240= 76 800 Байт. Вы хотите работать с цветным изображением, т.е. умножим ещё на 3 = 230 400 Байт будет занимать одно только изображение в памяти МК. Если стоит задача работать на бюджетном железе - рекомендую смотреть в сторону одноплатных микрокомпьютеров типа Распбери, Оранж и тд. Пи. Так как это задача совсем другого класса и дело здесь не в вычислительной мощности или таланте программиста. Картинка банально просто не поместится в МК.

[Genius1 0]

8 hours ago, Eusebius said:

Вы уверены, что предлагаемое Вами железо адекватно поставленной задаче? Даже при разрешении 320х240 пикселей монохромное изображение займёт 320*240= 76 800 Байт. Вы хотите работать с цветным изображением, т.е. умножим ещё на 3 = 230 400 Байт будет занимать одно только изображение в памяти МК. Если стоит задача работать на бюджетном железе - рекомендую смотреть в сторону одноплатных микрокомпьютеров типа Распбери, Оранж и тд. Пи. Так как это задача совсем другого класса и дело здесь не в вычислительной мощности или таланте программиста. Картинка банально просто не поместится в МК.

Это как раз легко решается внешней ОЗУ. А вот вычислительная мощность железа и квалификация программиста и есть тонкое место. Будем надеяться, автор изначально оценил возможность портируемости реализации на микроконтроллер в принципе.

[jcxz 184]

41 минуту назад, Genius1 сказал:

Это как раз легко решается внешней ОЗУ. А вот вычислительная мощность железа и квалификация программиста и есть тонкое место.

Легко? А ничего, что скорость такого доступа будет скорей всего в разы меньше чем к внутренней? Это при том, что там и с внутренней будут большие проблемы с быстродействием....

Цитата

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

Скорее всего МК был взят "с потолка".

[leocat 0]

37 minutes ago, Genius1 said:

Это как раз легко решается внешней ОЗУ. А вот вычислительная мощность железа и квалификация программиста и есть тонкое место. Будем надеяться, автор изначально оценил возможность портируемости реализации на микроконтроллер в принципе.

Опп-па... Началось в деревне утро...

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

[Genius1 0]

2 hours ago, jcxz said:

Легко? А ничего, что скорость такого доступа будет скорей всего в разы меньше чем к внутренней? Это при том, что там и с внутренней будут большие проблемы с быстродействием....

Речь про объём шла.

 

Но, я думаю, общее мнение о задаче у всех комментаторов совпадает)

[retegor 0]

Добрый день, спасибо всем за обсуждение.

On 10/21/2018 at 11:59 PM, Eusebius said:

Вы уверены, что предлагаемое Вами железо адекватно поставленной задаче? Даже при разрешении 320х240 пикселей монохромное изображение займёт 320*240= 76 800 Байт. Вы хотите работать с цветным изображением, т.е. умножим ещё на 3 = 230 400 Байт будет занимать одно только изображение в памяти МК. Если стоит задача работать на бюджетном железе - рекомендую смотреть в сторону одноплатных микрокомпьютеров типа Распбери, Оранж и тд. Пи. Так как это задача совсем другого класса и дело здесь не в вычислительной мощности или таланте программиста. Картинка банально просто не поместится в МК.

Устройство используется существующее, оно более 3-х лет успешно применяется для задач образовательной робототехники в своей "весовой категории", решало и решает различные задачи по распознаванию и отслеживанию объектов с соответствующими ограничениями. Задача не в выборе элементной базы, а в раскрытии потенциала существующей, расширении функционала и повышении привлекательности продукта. Насчет уверенности - да, мы понимаем, что делаем, здесь важен творческий подход, глубокое понимание алгоритмов СТЗ и на какие уловки и ухищрения можно пойти, чудес от STM мы с вами не ждем. Код СТЗ для STM на выходе получается совсем не такой как для ПК. Конечно, кадр не влезет и OpenCV здесь не запустится, мы все грамотные люди.

On 10/22/2018 at 9:35 AM, jcxz said:

Скорее всего МК был взят "с потолка".

Есть сегмент и устройство с соответствующей элементной базой, она взята не с потолка и может много интересного. Задача в том, чтобы использовать этот потенциал.

On 10/22/2018 at 9:41 AM, leocat said:

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

Мы используем разную элементную базу, малинки и OpenCV наши хорошие друзья, но это другая история.

On 10/22/2018 at 11:41 AM, Genius1 said:

Но, я думаю, общее мнение о задаче у всех комментаторов совпадает)

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

Спасибо за интересные предложения насчет реализации, к сожалению, они оказались нереализуемы на этой железке. С позволения ребят, которые помогали с Виолой-Джонсом, тоже поделюсь результатом, к сожалению образов слишком много для применения этого алгоритма. Задача не горит, поэтому с нетерпением жду новые творческие идеи и конструктивные предложения на [email protected].

[x893 35]

Возьмите пример от CMSIS-NN и проверьте железо. Но на RPi Zero по 5$ с полпинка это решается.

[retegor 0]

On 10/24/2018 at 12:25 PM, x893 said:

Возьмите пример от CMSIS-NN

CMSIS-NN хорошая идея, наши конкуренты уже освоили как только они появились в том году. Для нашей задачи нужна ROI машина хорошая, чтобы робот "смотрел по сторонам". На всю картинку и инвариантность к размеру нас точно не хватит, хотя и образы проще, чем в примере, может и инвариантность будет в каких-то пределах.

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