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 или быстрый процессор, а алгоритм. Неудачно построенный алгоритм затормозит любую систему. Так что я буду стараться организовать алгоритм поиска образов как можно эффективнее.

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

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

Уу, вот это "Весь наш интеллект-разум" ты зря написал, сейчас понесётся, 20 страниц точно не миновать...

P.S. ИМХО:
>Я убеждён, что ключевым в задаче "зрения" является память.
верно(только, одно из ключевых)
>Весь наш интеллект-разум - это всего лишь очень много ассоциативной памяти.
не верно.

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

Стоять! (предупредительный выстрел в воздух) Все обсуждение ИИ\ЕИ и прочего - в другие темы. К вечеру всё это покрошу, если не будет высказано серьезных оснований почему это имеет отношение к этой теме!

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

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

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

2Vorral: Вроде EDV'ом и так заявлен Optical-Flow?

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

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

В принципе, можно попробовать запоминать памятью области в центре экрана, при условии, что эти области не распознаны (если область изображения в центре не распознана, то запомнить её в память). И тогда если робот будет перемещаться, то будут фиксироваться всё новые и новые маяки (которые можно привязывать к карте локации).

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

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

2EDV: Я себе вижу интерфейс таким образом:

1. Создание распознавалки как класса с созданием внутри всех необходимых структур данных;
2. Сохранение всей внутренней структуры в файл, загрузка из файла.
3. Добавление образа для распознавания.
4. Распознавание всех образов, которые знаем, на заданном изображении.
5. Распознавание 1 вида образов, который знаем, на заданном изображении.
6. Удаление образа из распознаваемых.

Всякие фишки типа самообучения в процессе распознавания и т.п. сделать над общим интерфейсом.

Так нормально?