roboforum.ru

>то выполнять навигацию будет практически невозможно.
это очень важный пункт. Так если мы хотим автономного робота и подешевле, то будем ставить маленький по габаритам и соответственно маломощный ноут или ПК, а не Core 2 DUO на котором и выходит 40ms. И в конце концов не только же зрением заниматься роботу. Поэтому считаю одной из главных задач умение работать навигации и в "тяжёлых" условиях.

P.S. Например у меня разница в производительности алгоритма 3Д реконструкции на процессоре Core 2 Duo 2.33Гц и Intel Atom 1,6Гц составляет один десяток 43мс против 533мс. Так что желательно сделать алгоритм навигации максимально эффективным даже с 1 кадром в сек

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

=DeaD= писал(а):Чем грозит оптимизация для нас? Тем что первоначальный образ потеряем или что? Отчего разрастается дерево? Можем ли мы в рамках нашей задачи навигации забыть про эту проблему?

Ну, в принципе, было бы хорошо дождаться первых экспериментальных данных от энтузиастов, которые примут участие в проекте «Навигатор» и услышать от них с какими трудностями (в отношении распознавания) они столкнулись. Затем было бы здорово, что бы они записали тестовое исходное видео, там где алгоритм AVM не смог адекватно справится с задачей распознавания. Потом переслать это видео мне, а я попробую выяснить причину и улучшить характеристики AVM.

Vorral писал(а):P.S. Например у меня разница в производительности алгоритма 3Д реконструкции на процессоре Core 2 Duo 2.33Гц и Intel Atom 1,6Гц составляет один десяток 43мс против 533мс. Так что желательно сделать алгоритм навигации максимально эффективным даже с 1 кадром в сек

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

Я убеждён, что ключевым в задаче "зрения" является память. "Зрячая" машина должна быть способна эффективно распознавать миллионы (а то и больше) образов в реальном масштабе времени. Да и вообще, всё наше сенсорное восприятие (зрение, слух, осязание, мышечные чувства) это всё сплошная видео/звуковая/сигнальная ассоциативная память.

Весь наш интеллект-разум - это всего лишь очень много ассоциативной памяти. Наш мозг в обыденной жизни не придумывает ничего нового, он просто пользуется ассоциациями (навыками) полученными ранее. К тому же, над распознаванием сенсорной информации стоит некий абстрактный уровень восприятия (ещё одна ассоциативная память, работающая с распознанными "символами" или абстракциями). Поэтому мы способны переносить некие шаблоны действий (при решении задачи) без привязки к конкретным вещам/объектам, то есть мыслить абстрактно.

Я просто высказал своё мнение по поводу «ассоциативной памяти». А если у кого то есть желание обсудить как устроен интеллект, то для этого нужно создавать отдельную ветку форума...

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

Модератор "=DeaD=":Ай-ай-ай. Устное предупреждение. Что за привычка оффтоп разводить?

Добавлено спустя 7 минут 43 секунды:
EDV как предполагаете решать задачу ориентирования в неподготовленном помещении? Без движения с 1 камерой это будет невыполнимо(если в комнате находятся неизвестные программе образы), нужно активнее смотреть в сторону Optical-Flow. Я думаю это должно стать основой навигации.

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

Добавлено спустя 8 минут 13 секунд:
Особенно, если ещё и объекты перемещаются, относительно друг друга, но тут боюсь уже почти ничто не поможет(конечно же кроме 2-ух вебкамер, люблю самопиар ) ))) Хотя сначала, автор это допускал(определение приблизительных градусов вращения пушки, относительно корпуса)

С 1 камерой я предполагаю осуществить следующие действия . Представим, что у нас есть два кадра. Разделённые 200мс, с обязательным условием, что за это время робот находился в движении. В общем виде задача сводится к нахождению увеличенных областей(случай когда мы едем в сторону этого объекта), перемещённых(едем вдоль) и повёрнутых(например едем кругом, тут останется только часть общего для обоих картинок предмета) или даже параметров сразу. Осуществлением в конкретной программной реализации займусь позже, хотя точно не знаю, по мне проще получить сразу карту глубины и именно таким образом отделить маяки от фона(а там уже распознать, новый -> присвоить ID, уже есть ID -> проследить его перемещение) и заодно знать расстояние до них, для последующих расчётов координат.

Добавлено спустя 35 минут 2 секунды:
А по какому признаку можно запоминать области в AVM? Это должен будет быть квадрат/прямоугольник, на крайняк с наложенной маской исключения фона? Зачем хранить лишние данные? А нельзя уйти от формы квадратов? Т.е. запоминать объект по фрагментам, например с одинаковым спектром световых волн? Т.е. блик это одна зона, чёрная буква эта другая и на основе их компоновки(инвариантности и равномерного смещения световых волн(тени, блики)) и характера эти фигур/фрагментов сопоставлять объекты?