Технический форум по робототехнике.
Правила форума
В этом форуме новые темы не создаются, однако обсуждение допустимо.
=DeaD= » 05 июн 2009, 10:31
а пауза зачем?
Добавлено спустя 1 минуту 16 секунд:Кстати, а есть уже какие-то мысли по выбору естественных маяков? Если что - могу своих накидать
Добавлено спустя 1 минуту 31 секунду:Кстати, а какая-то есть защита от того, что образ будет встречаться на изображении не то что несколько раз, а вообще размыто?
Например, в качестве образа мы запомнили квадрат состоящий наполовину из черного, наполовину из белого - а на изображении черно-белые полосы по всему экрану. Что выдаст распознавалка?
EDV » 05 июн 2009, 10:41
Пауза нужна, что бы пользователь успел «вставить» в зону обучения (зелёный прямоугольник) объект, на который будет обучаться алгоритм AVM.
А по поводу маяков, на данный момент у меня как минимум две идеи:
- для маяков можно искать контрастные фрагменты изображений с «богатой/уникальной» текстурой;
- искать области изображения, которые сильно выделяются на основном фоне.
Но в начале мне нужно решить, как улучшить поиск образов в ассоциативном дереве AVM.
=DeaD=:
> Кстати, а какая-то есть защита от того, что образ будет встречаться на изображении
> не то что несколько раз, а вообще размыто?
> Например, в качестве образа мы запомнили квадрат состоящий наполовину из черного,
> наполовину из белого - а на изображении черно-белые полосы по всему экрану.
> Что выдаст распознавалка?
Нет, такой защиты нету, поэтому распознает все имеющиеся полосы на входном изображении.
=DeaD= » 05 июн 2009, 10:49
EDV писал(а):Пауза нужна, что бы пользователь успел «вставить» в зону обучения (зелёный прямоугольник) объект, на который будет обучаться алгоритм AVM.
То есть это интерфейсная пауза и потом для работы её будет не надо. Тогда понял.
EDV писал(а):А по поводу маяков, на данный момент у меня как минимум две идеи:
- для маяков можно искать контрастные фрагменты изображений с «богатой/уникальной» текстурой;
- искать области изображения, которые сильно выделяются на основном фоне.
Надо пробовать наверное уже, я так думаю...
EDV писал(а):Но в начале мне нужно решить, как улучшить поиск образов в ассоциативном дереве AVM.
А давай сначала сделаем на том, что есть, а потом будем улучшать?
EDV » 05 июн 2009, 13:39
=DeaD=:
> А давай сначала сделаем на том, что есть, а потом будем улучшать?
Хорошо, можно и так, у меня есть сейчас вариант «поиск контрастных фрагментов», но алгоритм AVM быстро «захлёбывается» потоком новых изображений. Я постараюсь на выходных привести тексты программы в порядок, и выложу для скачивания.
=DeaD= » 05 июн 2009, 14:14
EDV писал(а):алгоритм AVM быстро «захлёбывается» потоком новых изображений
В смысле слишком много маяков в базе данных? так давай я пропишу, как их выбирать адекватно?
Нужно? Или я не так понял проблему?
EDV » 05 июн 2009, 17:38
В принципе, адекватный алгоритм выбора маяков, это тоже актуальная проблема, но с AVM пока и без этого трудностей хватает. Мне бы хотелось, что бы AVM была способна работать хотя бы с 1000 - 2000 образов (матриц) в памяти с разрешением входного изображения 640x480 в реальном масштабе времени (менее 40 ms на один кадр). Пока что не получается.
=DeaD= » 05 июн 2009, 18:20
А сколько образов держит при работе 320х240?
EDV » 08 июн 2009, 10:06
На таком разрешении, как раз под тысячу уверенно работает. Но на таком разрешении навигацию точно не построишь (пикселей для поиска маяков и формирование команд по таким мелким расстояниям маловато).
=DeaD= » 08 июн 2009, 10:26
Разве? А какие параметры процедуры поиска и распознавания образов, что ей 320х240 мало?
EDV » 08 июн 2009, 13:42
Ну, это проще будет скачать
http://edv-detail.narod.ru/Navigator_src.zip запустить StartMe.bat, затем установить разрешение 320x240 (Главное меню/Настройки/Формат захвата изображения) и обучить AVM к примеру на собственное лицо. Затем включить режим навигации (Главное меню/Распознавание/Режим навигации) и поглядеть реакцию «Навигатора» на изменение позиции лица в кадре относительно центра.
Можно лично убедится, что маловато пространства для формирования управляющих воздействий роботу. Так что 640x480 – это наше всё, с меньшим разрешением навряд ли получится.
Vorral » 08 июн 2009, 14:40
>Так что 640x480 – это наше всё
Я тоже думаю, что это разрешение вскоре станет основным. При нём ещё можно сохранить приемлемый результат и скорость работы. Но и сразу откидывать меньший вариант(320x240), было бы не правильно. Из-за текущей действительности процессорного рынка в области экономичных решений.
=DeaD= » 08 июн 2009, 15:24
EDV писал(а):Можно лично убедится, что маловато пространства для формирования управляющих воздействий роботу. Так что 640x480 – это наше всё, с меньшим разрешением навряд ли получится.
А можно для тех кто в танке - что такое формирование управляющих воздействий роботу? Указание образа что ли?
EDV » 08 июн 2009, 15:47
Имеется в виду тот алгоритм навигатора, который сейчас реализован. Там, к примеру, решение поворачивать роботу влево или вправо принимается на основании превышения порогового значения расстояния, которое рассчитывается как разность позиции распознанного объекта от центра по горизонтали.
- Код: Выделить всё • Развернуть
// Вычисляем величину отклонения цента объекта от центра входного изображения
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 плохо сосчитается с задачей навигации (точности маловато).
Виталий » 08 июн 2009, 16:05
Это проблема вашего робота, а не разрешения. У него просто плохое управление.
Поставьте более широкоугольный объектив вот и все дела.
=DeaD= » 08 июн 2009, 16:13
То ли я туплю сегодня, то ли что, а как 320х240 влияет на маневренность и т.п.?
Ну если взять и растянуть изображение до 640х480 с размытием - что поменяется принципиально?
Добавлено спустя 42 секунды:Виталий писал(а):Это проблема вашего робота, а не разрешения. У него просто плохое управление.
Поставьте более широкоугольный объектив вот и все дела.
Да тут даже не ширик нужен, а логика
Как-то же 640х480 нужного угла снимается? Просто не надо 320х240 из середины кадра 640х480 вырезать, а надо сплюснуть 640х480 в 2 раза по обоим измерениям.