roboforum.ru

а пауза зачем?

Добавлено спустя 1 минуту 16 секунд:
Кстати, а есть уже какие-то мысли по выбору естественных маяков? Если что - могу своих накидать

Добавлено спустя 1 минуту 31 секунду:
Кстати, а какая-то есть защита от того, что образ будет встречаться на изображении не то что несколько раз, а вообще размыто?

Например, в качестве образа мы запомнили квадрат состоящий наполовину из черного, наполовину из белого - а на изображении черно-белые полосы по всему экрану. Что выдаст распознавалка?

Пауза нужна, что бы пользователь успел «вставить» в зону обучения (зелёный прямоугольник) объект, на который будет обучаться алгоритм AVM.

А по поводу маяков, на данный момент у меня как минимум две идеи:
- для маяков можно искать контрастные фрагменты изображений с «богатой/уникальной» текстурой;
- искать области изображения, которые сильно выделяются на основном фоне.

Но в начале мне нужно решить, как улучшить поиск образов в ассоциативном дереве AVM.

=DeaD=:
> Кстати, а какая-то есть защита от того, что образ будет встречаться на изображении
> не то что несколько раз, а вообще размыто?

> Например, в качестве образа мы запомнили квадрат состоящий наполовину из черного,
> наполовину из белого - а на изображении черно-белые полосы по всему экрану.
> Что выдаст распознавалка?

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

EDV писал(а):Пауза нужна, что бы пользователь успел «вставить» в зону обучения (зелёный прямоугольник) объект, на который будет обучаться алгоритм AVM.

То есть это интерфейсная пауза и потом для работы её будет не надо. Тогда понял.

EDV писал(а):А по поводу маяков, на данный момент у меня как минимум две идеи:
- для маяков можно искать контрастные фрагменты изображений с «богатой/уникальной» текстурой;
- искать области изображения, которые сильно выделяются на основном фоне.

Надо пробовать наверное уже, я так думаю...

EDV писал(а):Но в начале мне нужно решить, как улучшить поиск образов в ассоциативном дереве AVM.

А давай сначала сделаем на том, что есть, а потом будем улучшать?

=DeaD=:
> А давай сначала сделаем на том, что есть, а потом будем улучшать?

Хорошо, можно и так, у меня есть сейчас вариант «поиск контрастных фрагментов», но алгоритм AVM быстро «захлёбывается» потоком новых изображений. Я постараюсь на выходных привести тексты программы в порядок, и выложу для скачивания.

EDV писал(а):алгоритм AVM быстро «захлёбывается» потоком новых изображений

В смысле слишком много маяков в базе данных? так давай я пропишу, как их выбирать адекватно?
Нужно? Или я не так понял проблему?

В принципе, адекватный алгоритм выбора маяков, это тоже актуальная проблема, но с AVM пока и без этого трудностей хватает. Мне бы хотелось, что бы AVM была способна работать хотя бы с 1000 - 2000 образов (матриц) в памяти с разрешением входного изображения 640x480 в реальном масштабе времени (менее 40 ms на один кадр). Пока что не получается.

А сколько образов держит при работе 320х240?

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

Разве? А какие параметры процедуры поиска и распознавания образов, что ей 320х240 мало?

Ну, это проще будет скачать http://edv-detail.narod.ru/Navigator_src.zip запустить StartMe.bat, затем установить разрешение 320x240 (Главное меню/Настройки/Формат захвата изображения) и обучить AVM к примеру на собственное лицо. Затем включить режим навигации (Главное меню/Распознавание/Режим навигации) и поглядеть реакцию «Навигатора» на изменение позиции лица в кадре относительно центра.

Можно лично убедится, что маловато пространства для формирования управляющих воздействий роботу. Так что 640x480 – это наше всё, с меньшим разрешением навряд ли получится.

>Так что 640x480 – это наше всё
Я тоже думаю, что это разрешение вскоре станет основным. При нём ещё можно сохранить приемлемый результат и скорость работы. Но и сразу откидывать меньший вариант(320x240), было бы не правильно. Из-за текущей действительности процессорного рынка в области экономичных решений.

EDV писал(а):Можно лично убедится, что маловато пространства для формирования управляющих воздействий роботу. Так что 640x480 – это наше всё, с меньшим разрешением навряд ли получится.

А можно для тех кто в танке - что такое формирование управляющих воздействий роботу? Указание образа что ли?

Имеется в виду тот алгоритм навигатора, который сейчас реализован. Там, к примеру, решение поворачивать роботу влево или вправо принимается на основании превышения порогового значения расстояния, которое рассчитывается как разность позиции распознанного объекта от центра по горизонтали.

Код: Выделить всё

   // Вычисляем величину отклонения цента объекта от центра входного изображения
   int cXs = apGray->width>>1;
   int cXo = apRcgObj->ObjRect->x + (apRcgObj->ObjRect->width>>1);
   int cXd = cXs - cXo;

   //...

   // Объект находится слева от робота?
   if(cXd >  40) {// Да
      // Один раз (импульсом) повернуть корпус робота влево
      if(!MvLft && gNvg.TurretBalance > 0) { gpCmdArray->Cmd[cmLEFT] = true; }
      // Поворот башней влево
      if(!TrLft) {
         gpCmdArray->Cmd[cmTURRET_LEFT] = true;
         gNvg.TurretBalance++;
      }
   }
   // Объект находится справа от робота?
   if(cXd < -40) {
      // Один раз (импульсом) повернуть корпус робота вправо
      if(!MvRht && gNvg.TurretBalance < 0) { gpCmdArray->Cmd[cmRIGHT] = true; }
      // Поворот башней вправо
      if(!TrRht) {
         gpCmdArray->Cmd[cmTURRET_RIGHT] = true;
         gNvg.TurretBalance--;
      }
   }

Так вот, на таком мелком разрешении (320x240) если даже робот импульсом повернёт на одну позицию, то объект просто может потеряться из поля зрения, да и вообще сложно принять решение о повороте, если в вашем распоряжении всего +- 160 пикселей минус размер распознанного объекта и минус гистерезис. Что бы исключить колебательный процесс (робот начинает самопроизвольно дергается влево - вправо) нужно задать некий гистерезис (в нашем случае +- 40 пикселей).

Вот по этой причине разрешение 320x240 плохо сосчитается с задачей навигации (точности маловато).

Это проблема вашего робота, а не разрешения. У него просто плохое управление.

Поставьте более широкоугольный объектив вот и все дела.

То ли я туплю сегодня, то ли что, а как 320х240 влияет на маневренность и т.п.?
Ну если взять и растянуть изображение до 640х480 с размытием - что поменяется принципиально?

Добавлено спустя 42 секунды:

Виталий писал(а):Это проблема вашего робота, а не разрешения. У него просто плохое управление.
Поставьте более широкоугольный объектив вот и все дела.

Да тут даже не ширик нужен, а логика Как-то же 640х480 нужного угла снимается? Просто не надо 320х240 из середины кадра 640х480 вырезать, а надо сплюснуть 640х480 в 2 раза по обоим измерениям.