roboforum.ru

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

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

Ну хорошо, с поворотами согласен, а с маяками как быть? Ведь на разрешении 320x240 маяков может и вовсе не оказаться (изображения слишком мелкие и их окошком 80x80 не распознать), а вот на 640x480 напротив пригодных фрагментов для распознавания, размером от 80 пикселей может оказаться в достаточном количестве.

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

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

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

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

А текстуры от увеличения c 320x240 -> 640x480, не пострадают что ли? Распознавание маяков за уникальные текстуры цепляется. Так что изображение должно быть достаточно детальным.

А откуда окошко именно 80х80 пикселей взялось? Почему нельзя 40х40 пикселей смотреть?

Добавлено спустя 49 секунд:
Принципиально вряд ли что-то поменяется, к тому же по опыту с этой радиокамеры как раз реальное изображение 320х240 идёт, всё остальное - примерно того же качества, что 320х240 развернуть в 2 раза

> А откуда окошко именно 80х80 пикселей взялось? Почему нельзя 40х40 пикселей смотреть?

Это самый оптимальный ключевой размер изображения для алгоритма AVM. Размер 40x40 ещё возможен, но будут ощутимые потери по быстродействию.

Ладно, уговорили, попытаюсь ещё раз поискать маяки на разрешении 320x240.
Посмотрим, что получится.

как это при 40х40 возникнут потери по быстродействию? Вроде качество распознавания может ухудшиться, а быстродействие наоборот может только увеличится?

Ну а если изображение одной и той же площади на фрагменты разбить, где фрагментов больше окажется там, где размер одного фрагмента 80x80 или там где 40x40?

А если сканировать окошком с фиксированным шагом (к примеру 16 пикселей) где окошек больше поместится (естественно там, где размер окошка 40x40)?

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

EDV писал(а):Ну а если изображение одной и той же площади на фрагменты разбить, где фрагментов больше окажется там, где размер одного фрагмента 80x80 или там где 40x40?

Откуда ж оно "одной и той же площади", если у нас вместо картинки 640х480 будет 320х240?

EDV писал(а):А если сканировать окошком с фиксированным шагом (к примеру 16 пикселей) где окошек больше поместится (естественно там, где размер окошка 40x40)?

Если фиксирован шаг 16 пикселей - на изображении 320х240 как раз меньше поместится фрагментов 40х40, чем на 640х480 фрагментов 80х80

EDV писал(а):Поэтому размер наименьшего (ключевого) изображения, которое может быть распознано, значительно влияет на время поиска.

Если не менять кадр и оставить 640х480 - конечно, а если менять?


то будет быстрее! отвечаю!

Ну что же, AVM SDK v0.5 доступны, можно попробовать поменять значения ключевого размера изображения в примере с 80x80 на 40x40 и посмотреть что получится (по быстродействию).

AVM_SDK\samples\src\RcgExample\RcgExample.cpp

Код: Выделить всё • Развернуть

   CvRect InterestArea;
   InterestArea.x = 84;
   InterestArea.y = 38;
   InterestArea.width  = 80;
   InterestArea.height = 80;

Собирать под чем?

Возможна сборка одним из двух компиляторов, проекты:
AVM_SDK\samples\vc6.prj\AVM_prj.dsw для Microsoft Visual C++ 6.0
AVM_SDK\samples\vc9.prj\AVM_prj.sln для Microsoft Visual Studio 2008

Понял, будем ставить

Я тут пока в теорию для этой задачи погрузился, практику пока за кадром чуток оставил.

В общем нам нужны SLAM-алгоритмы и фильтр Калмана. Сейчас читаю что и как. Фильтр Калмана вообще в задачах навигации безумно крутая штука - используется везде где только можно - и в определении своих координат по спутникам (а у нас будет - по визуальным маякам) и в фильтрации показателей гироскопа+акселерометра и еще в куче мест. И главное - ему не надо накапливать информацию при стоящем роботе, ему достаточно на ходу видеть маяки с какой-то там точностью.

Для прослеживания (tracking) распознанных объектов в AVM я использую «Condensation Algorithm» в его документации пишут, что он работает более эффективно, чем фильтр Кальмана.

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

Дык трекинг объекта на кадре - это одно, а задача отслеживания состояния системы в общем виде по наблюдениям в общем виде - совсем другое

На работе немного попустило, так что можно продолжить тему навигации.
И так, вот что у меня получилось с маяками:



Только быстродействие пока что слабоватое.
Демонстрационную версию вместе с исходными текстами программы я разместил здесь:
http://edv-detail.narod.ru/Navigator_Tool_Kit.zip

Алгоритм выделения маяков описан здесь:
Navigator_Tool_Kit\include\PatternRecognition.h

Метод класса iPatternRecognition:

Код: Выделить всё • Развернуть

// Поиск маяков
iPatternFound* GetBeacons(IplImage* apImage);

Для сборки проекта можно воспользоваться одним из компиляторов:
Navigator_Tool_Kit\samples\vc6.prj\Samples.dsw - для Microsoft Visual C++ 6.0;
Navigator_Tool_Kit\samples\vc9.prj\Samples.sln – для Microsoft Visual Studio 2008.

Как-то очень странно маяки выделяются, а они проверяются на смещения? Выложи плиз фотку качественную где номера выделенных маяков нормально читаются, я тогда смогу сказать о чем я.