roboforum.ru

Приветствую!

Хотелось бы в этой теме обсудить возможность реализации платы видеообработки для МиниБота.

Плата видеообработки должна обеспечивать оцифровку черно-белого изображения с аналоговой видеокамеры с разрешением 320x240 пикселей с частотой 25-15 кадров в секунду. Объем оперативной памяти контроллера должен быть минимум 16Mb.

Один из вариантов исполнения - два процессора: один оцифровывает видео в память, другой (с большей памятью и более производительный) занят в видеообработке.

Если плата видеообработки таки появится в металле, тогда планирую портировать под неё алгоритм распознавания образов «Associative Video Memory» (AVM).

-= 23.11.09 =-
В фразе «один из вариантов исполнения - два процессора» имелось в виду, что процессор оцифровки видео будет использован с целью уменьшения количества микросхем логики на плате. Но если существует какой то специализированный чип, позволяющий оцифровывать черно-белое видео, тогда можно обойтись одним процессором видеообработки, а данные в память видеобуфера записывать, к примеру, по DMA.

Одно из требований к процессору видеообработки – наличие под этот процессор компилятора C++.

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

Я считаю, что причина по которой не нужно ориентироваться на «SRV-1 Blackfin Camera» - повторяемость изделия. Нам нужна плата, которую реально можно будет изготавливать в необходимых количествах, схему которой мы понимаем и можем улучшать. А в случае с «SRV-1 Blackfin Camera» эту плату могут просто прекратить выпускать, да и заказывать плату из за океана, как по мне, тоже чересчур.

Схем цифрователя видео, ну просто для затравки:

12 кадров в секунду это можно сказать идеально

Я ошибся, кадр длится не 64 а 40 мс. Так вот вопрос, можно ли за 40 мс обработать кадр объемом 75 килобайт?
Или придётся пропускать два кадра, но это уже 8 кадров в сек.

2yak-40, если как предлагал EDV реализовать AVM, то для меги это точно нереально

Такие вещи надо учесть. Зачем видео вообще надо?
а) передать дальше, это сейчас можно сделать через видеосендер, очевидно не наш случай
б) обработать на месте. Смотрим дальше:

a) "обработать видео" - это сначала надо иметь алгоритм,
который первоначально делается на ПК, потом переносится в робота.
Двойная работа получается в общем-то.
б) робот едет с остановками (стоп-взял-видео-проанализировал-проехал чуток).
Движение будет дерганное типа рывок-стоп-рывок. Если FPS мало, то только так и можно будет.
Иначе пока получается и анализируется очередной кадр,
робот уедет черти куда и решение на основе последнего кадра будет неверным.
Как вариант - ехать медленно и печально.
в) робот едет без остановок (взял-видео-проанализировал-скорректировал моторы).
Чтобы робот ехал разумно быстро, надо как можно больше FPS.

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

Поэтому, если будет мало FPS - в топку такую плату

если как предлагал EDV реализовать AVM, то для меги это точно нереально

Ну да, ну да.
Но хотя-бы шарик белый определить можно?

Имхо не определит он и шарик белый...

AndreiSk, насколько я понял из http://roboforum.ru/viewtopic.php?f=37&t=6657 комповый вариант уже существует и развивается. насчёт х86... не сказал бы, что слишком великовато будет, есть picoitx, есть nanoitx. а вот дорого и потребление относительно немалое (+размеры акума+бп) это точно, так что думаю в данной теме идея с х86 не приживётся

Но хотя-бы шарик белый определить можно?

Можно, только таких шариков в реальном мире - куча. Любой блик.

только таких шариков в реальном мире - куча. Любой блик

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

Например лампочку на базовой станции или белая линия на тёмном полу...

Если мозги не парить излишними сложностями, то конечно найдет

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

Значиться так! Поставить в "мою" схему не одну, а две микросхемы памяти, ну или одну в два раза больше.
Дальше, Мега16 переносит кадр в перую половину памяти, второй, более мощный контроллер начинает обрабатывать эти данные. А в это время Мега16 пишет второй кадр во вторую половину памяти. Потом наоборот.
По-моему всё это очень даже реально.

Вопрос: в исходном варианте по УАРТ у у тебя какое максимальное быстродействие получилось?

Я же писал, при скорости 115200 один кадр передаётся за 0,5 сек. в лучшем случае. Поэтому, УАРТ - бутылочное горлышко. Его использовать не стоит. Лучше брать информацию другим контроллером прямо из памяти. А с вводом видео в память мега справится.

Все понял идею