Форум: Проблемы искусственного интеллекта

Регистрация | Вход

Все темы | Новая тема  Стр.5 (6) << < Пред. | След. > >>    Поиск:
Автор	Тема: На: Проблематика современного развития темы создания ИИ в рамках поэтапного развития технического прогресса.
Necr0x0Der Сообщений: 34	На: Проблематика современного развития темы создания ИИ в рамках поэтапного развития технического прогресса. Добавлено: 31 окт 12 14:48 Цитата: Автор: Tester64 ...Да и алгорим скорее всего использовали примитивный-математический (while) или комбинаторно выбраный. А я хочу попробовать применить алгоритмы из области ИИ и мягко связать их с математикой. Я не это имел в виду. Наоборот, мы создавали свою систему, потому что решали узкую задачу, и было проще создать что-то простое для моделирования, чем пользоваться громоздкой готовой системой (хотя сначала такие попытки тоже были). В вашем же случае ситуация обратная. [Ответ][Цитата]
Tester64 Сообщений: 1910	На: Проблематика современного развития темы создания ИИ в рамках поэтапного развития технического прогресса. Добавлено: 31 окт 12 14:53 Цитата: Автор: daner а я вам про робототехнику говорю. особенно для домашнего использования. Если вы конечно большая компания которая делает исключительно все сама (знаю я таких...) тогда все равно . А если у себя не хотите 3 года тратить на написания сложних модулей которые уже написанны и отлаженни, то стоит использовать инструменты наиболее распространение в конкретной области. в робототехнике -- это конечо Линукс, C ++ и python Хочу сделать все именно сам... Причем в идеале встроить все алгоритмы в МОЙ логический ИИ-модуль... А то что писать долго или лень переписывать (с явы/питона/с++)готовое - всегда можно подключить отдельным модулем-библиотекой написаной на другом языке. А пока... на моем компе будет жить себе тамагочи-чудо на 4х колесах, которое можно даже обучить "приносить тапочки" Цитата: кстати , вы не правы, на счет симуляторов. не могу скать чо протоколы такие уж простые, но во многих как раз TCP и используется, что бы клиентские модули не ограничивать каким-то определенным языком. Тогда вообще не проблема - ОТЛАЖЕНЫЕ алгоритмы на моем ПРОСТОМ эмуляторе под Win можно будет со временем ТРАНЛИРОВАТЬ через сеть на Linux в другой компьютер или в эмулятор [Ответ][Цитата]
Necr0x0Der Сообщений: 34	На: Проблематика современного развития темы создания ИИ в рамках поэтапного развития технического прогресса. Добавлено: 31 окт 12 15:26 Цитата: Автор: daner меня больше интересует как вы mono - SLAM делали. И тем более если избегали использования разных запотентованых (и кстати весьма тяжeлых ) алгоритмов отслеживания интересных точек. Честно признаюсь, все исходники которые мне пока попадали в руки по этой теме мяго говоря не дееспособны. Так что интересно как вам удалось все-таки заставить это дело работать. Помог опыт создания головок самонаведения, которые должны наводиться на цель, летя со скоростью в десяток километров в секунду А если серьезно, то ваши вопросы весьма в тему. Распознавать несколько кадров в секунду на ARM9 весьма непросто (а когда возникла задача распознавать текущий кадр по базе из нескольких тысяч изображений пришлось вообще пофантазировать). Ладно, попробую что-то конкретное сказать. Во-первых, картинки уменьшались до 320х240. Детектирование ключевых точек может быть умеренно быстрым. Например, есть FAST. Мы использовали свой метод, который немного медленнее FAST'а, но помехоустойчивее. Далее мы отбросили инвариантность к масштабу (поскольку камера робота ориентирована в потолок, а подпрыгивать он не умеет, поэтому z координата для большинства точек не меняется). Это позволило не только увеличить скорость, но и повысить надежность (и, опять же, благодаря отсутствию необходимости достигать инвариантность к масштабу можно было выделять ключевые точки без всяких пирамид разрешения). Дескрипторы были взяты простые. Чем-то похожие на SURF, но еще проще и быстрее. Сделали простую оценку качества точек и до построения дескрипторов еще уменьшали их число, что давало дополнительное ускорение (и даже небольшое улучшение качества). Потом путем максимальной алгоритмической оптимизации и оптимизации на уровне кода (адресная арифметика, собственный менеджер памяти и т.д.) добились очень быстрой имплементации. Упрощение дескрипторов компенсировали утяжелением матчинга, в который добавили ряд эвристик, учитывающих особенности съемки. Кроме того, в норме у робота есть актуальная одометрическая информация, за счет которой робот мог ездить и без зрения, хотя с быстро накапливающейся ошибкой счисления пути. Использование одометрической оценки смещения (при ее наличии) позволило также поднять надежность распознавания. Цитата: Саму локализацию через Кальмана делали или через партикал-фильтры? Там это было не нужно. То есть Калман, возможно, в счислении пути и использовался (точно не могу сказать), а локализация по изображениям проводилась просто путем оценки относительной ориентации по картинке из базы, для которой уже известно положение робота. Плюс при замыкании пути производились уточнения положений. [Ответ][Цитата]
Slava Сообщений: 3070	На: Проблематика современного развития темы создания ИИ в рамках поэтапного развития технического прогресса. Добавлено: 01 ноя 12 0:28 Цитата: Автор: daner определение местоположения при помощи одной камеры Понятно. Спасибо. Тоже когда-то этим занимался [Ответ][Цитата]
Victor G. Tsaregorodtsev Сообщений: 3187	На: Проблематика современного развития темы создания ИИ в рамках поэтапного развития технического прогресса. Добавлено: 01 ноя 12 5:52 Цитата: Автор: Tester64 Переходить на С++ пробовал, но "не зацепило"! Скорость разработки на Делфи раз в 5 быстрее, учитывая мои наработки. Вы просто не поняли основной цимес С++. А именно - параметризованные классы (шаблоны, templates). Раз пишешь алгоритм - а потом его шаблонно клонируешь под любые (в т.ч. и сложные) типы данных. Но у Вас просто задачи могли этого не требовать. И даже если скорость разработки на Дельфи выше - скорость работы проги будет в разы ниже. Поскольку борландовый компилятор никогда не умел оптимизировать - раз, и работать с современным командами процессора (MMX, SSE, AVX) - два. Также к паскалю с трудом подключаются быстрые математические библиотеки типа интеловских (просто разработчик для этих библиотек не прописывает пас-интерфейс - поэтому каждому желающему приходится собственными ручками переводить сишный h-файл в pas-файл) - три. И четыре - это невозможность распараллеливать вычисления (пользоваться стандартными интерфейсами MPI, OpenMP) на кластере. Интерфейс лепить - да, на делфи быстрее. Но как только ценность проги начинает определяться не интерфейсом... [Ответ][Цитата]
Necr0x0Der Сообщений: 34	На: Проблематика современного развития темы создания ИИ в рамках поэтапного развития технического прогресса. Добавлено: 01 ноя 12 6:59 Цитата: Автор: Victor G. Tsaregorodtsev основной цимес С++. А именно - параметризованные классы (шаблоны, templates). Раз пишешь алгоритм - а потом его шаблонно клонируешь под любые (в т.ч. и сложные) типы данных. Слабая потуга по сравнению с функциональными языками. [Ответ][Цитата]
гость 109.171.117.*	На: Проблематика современного развития темы создания ИИ в рамках поэтапного развития технического прогресса. Добавлено: 01 ноя 12 8:30 Сколково. Московский международный форум инновационного развития "Открытые инновации" Деловая программа форума: прямая трансляция из залов A, B1-B11, C1-C5, пресс-центр http://community.sk.ru/press/events/october2012/forinnovations/?sklang=ru [Ответ][Цитата]
Necr0x0Der Сообщений: 34	На: Проблематика современного развития темы создания ИИ в рамках поэтапного развития технического прогресса. Добавлено: 01 ноя 12 12:12 Я вам не скажу за все Сколково, все Сколково очень велико, но ... отдельные его части являют далеко не лучший пример инноваций. [Ответ][Цитата]
Tester64 Сообщений: 1910	На: Проблематика современного развития темы создания ИИ в рамках поэтапного развития технического прогресса. Добавлено: 01 ноя 12 12:15 Цитата: Вы просто не поняли основной цимес С++. А именно - параметризованные классы (шаблоны, templates). Раз пишешь алгоритм - а потом его шаблонно клонируешь под любые (в т.ч. и сложные) типы данных. Но у Вас просто задачи могли этого не требовать. Мои задачи это иногда требовали, но это легко решается и на Делфи. У меня есть базовый (разработанный мной) класс для списков в котором просто указываю тип храния. Или даже класс-предок хранимого типа и название типа - все остальное (даже простые алгоритмы сотрировки и поиска) класс делает сам. Цитата: И даже если скорость разработки на Дельфи выше - скорость работы проги будет в разы ниже. Поскольку борландовый компилятор никогда не умел оптимизировать - раз, и работать с современным командами процессора (MMX, SSE, AVX) - два. Также к паскалю с трудом подключаются быстрые математические библиотеки типа интеловских (просто разработчик для этих библиотек не прописывает пас-интерфейс - поэтому каждому желающему приходится собственными ручками переводить сишный h-файл в pas-файл) - три. И четыре - это невозможность распараллеливать вычисления (пользоваться стандартными интерфейсами MPI, OpenMP) на кластере. Интерфейс лепить - да, на делфи быстрее. Но как только ценность проги начинает определяться не интерфейсом... Возможно Вы и правы по поводу быстрых библиотек, но я сейчас не гонюсь за скоростью. Моего компа (4ядра + 8г озу) хватает для большинства задач. Остальное - проблемы харда у клиента, а не моего софта. Но (возможно уже дело привычки) мне нравится что обнаружив пропущеную ковычку или мелкую опечатку в коде которая не правильно считает я исправляю меньше чем за 10-15 секунд до перезапуска. Помню на VC++ одна лишь компиляция занимала 30-40 секунд. С облаками/кластерами на win тоже не пересекался и даже не знаю задач которые лично для меня нужно решать этими методами. [Ответ][Цитата]
dr2chek Сообщений: 871	На: Проблематика современного развития темы создания ИИ в рамках поэтапного развития технического прогресса. Добавлено: 01 ноя 12 20:40 Цитата: Автор: Tester64 Помню на VC++ одна лишь компиляция занимала 30-40 секунд. В VC++ есть же incremental compiling, или что-то в этом роде. Все последующие компиляции выполняются намного быстрее.., если не проводить сборку "с нуля" [Ответ][Цитата]
daner Сообщений: 4593	На: Проблематика современного развития темы создания ИИ в рамках поэтапного развития технического прогресса. Добавлено: 06 ноя 12 5:59 >>>> Slava так поделились бы опытом. >>>> Necr0x0Der [ ... А если серьезно ... ] Хм... прошу прощение за свое предвзятое мнение относительно ваших ответов. Значит, навигацию по поталку делали... Кстати, становится понятным упоминание о "самоноведении" (ну на сколько я знаком с техникой навигации на летающих девайсах) Я знаком с таким приемом (более того , я с него начал), но он мне не подходит так как навигация должна работать не только в здании. В любом случае спасибо за ответ. с дескрипторами у меня какая-то фигня. пытаюсь OpenCV алгоритмы использовать (вы с ними знакомы?) для Optic Flow он конечно находит, но какие-то они не стабильные. Даже если камера не двигается (ну т.е. все равно фраймы с камеры разные поступают) он их примерно за минуту все теряет. Это нормально? Еще вопрос, из чистого любопытства. А как планировалось создавать базу данных <КартинкаПотолка - МестоПоложение> ? А если роботу надо на кухне под столом, стульями и в комнатах под диваноми ездить? с обычной одометрией он после 2-3 секунд уже потеряется. Кстати, а картинки не проще/лучше сравнивать не по базисным точкам, а по хаш-числу картинки? и еще вопросик а почему на потолок? почему не на пол? слишком большие изменения от фрейма к фрейму? или какая-то другая причина? Хотя..., вам вообще изменения не важны вы же оптик флоу (на сколько я понял) не использовали. Кстати, а что же тогда за 3Д точки (облака) которые вы после рисовали на своем симуляторе. Вы их откуда брали если камера только локализировала сравнивая изображения? или я что-то перепутал? [Ответ][Цитата]
Slava Сообщений: 3070	На: Проблематика современного развития темы создания ИИ в рамках поэтапного развития технического прогресса. Добавлено: 06 ноя 12 6:37 Цитата: Автор: daner >>>> Slava так поделились бы опытом. Задумка была из двух частей Первая - дальномер со скрещенными лучами и одна камера, позволяющая по наклону вектора из точки от опорного луча в дополнительную определять расстояние Вторая - запись получаемой картины в объемную память, где уже и производятся реконструкция, распознавание и т.п. с фиксацией свойств на выделяемых объектах. При этом камера и ее носитель отображаются в соответствующую точку этой памяти. Давно это было. Теперь те же гугломобили, как понимаю, делают многое из планировавшегося, а что не делают - несложно и доделывать. Впрочем, наверно, это и делается, но я уже давно к этому потерял интерес и только изредка в эту сторону поглядываю [Ответ][Цитата]
daner Сообщений: 4593	На: Проблематика современного развития темы создания ИИ в рамках поэтапного развития технического прогресса. Добавлено: 06 ноя 12 12:58 Цитата: Автор: Slava ... запись получаемой картины в объемную память ... проще сказать чем сделать Цитата: Автор: Slava Теперь те же гугломобили, как понимаю, делают многое из планировавшегося,... на сколько я знаю, в гугле мобили не используют моноСЛАМ [Ответ][Цитата]
Slava Сообщений: 3070	На: Проблематика современного развития темы создания ИИ в рамках поэтапного развития технического прогресса. Добавлено: 06 ноя 12 13:36 Цитата: Автор: daner проще сказать чем сделать Не спорю, но так замышлялось, а потом занялись более интересным и важным и требующим много меньше ресурсов, так что это заглохло Цитата: на сколько я знаю, в гугле мобили не используют моноСЛАМ Деталей не знаю, но понимаю, что в качестве основы это могло бы быть использовано. Но опять же - сегодня для меня это совершенно неактуально [Ответ][Цитата]
Necr0x0Der Сообщений: 34	На: Проблематика современного развития темы создания ИИ в рамках поэтапного развития технического прогресса. Добавлено: 07 ноя 12 3:38 Цитата: Автор: daner пытаюсь OpenCV алгоритмы использовать (вы с ними знакомы?) для Optic Flow он конечно находит, но какие-то они не стабильные. Даже если камера не двигается (ну т.е. все равно фраймы с камеры разные поступают) он их примерно за минуту все теряет. Это нормально? В OpenCV реализация оптического потока очень слабая. Цитата: Автор: daner А если роботу надо на кухне под столом, стульями и в комнатах под диваноми ездить? с обычной одометрией он после 2-3 секунд уже потеряется. Там снизу еще сенсор стоял типа оптической мышки, что существенно улучшало точность навигации даже без камеры. Цитата: Автор: daner Кстати, а картинки не проще/лучше сравнивать не по базисным точкам, а по хаш-числу картинки? При поиске в большой базе - проще. При решении задачи навигации это ненадежно. Собственно, при задаче поиска мы и не делали прямой матчинг по ключевым точкам. Вместо этого в пространстве признаков выполнялась кластеризация (она делалась заранее по обучающей выборке), а потом для каждой картинки строилась гистограмма классов ключевых точек, и по этим гистограммам уже сравнивались картинки. Цитата: Автор: daner и еще вопросик а почему на потолок? почему не на пол? слишком большие изменения от фрейма к фрейму? Скорее, слишком маленькие. По оптическому потоку можно сделать только дифференциальное счисление пути. Там будет накапливаться ошибка. У нас же требовалась точная локализация. А отличить один кусок пола от другого нереально. Цитата: Автор: daner Кстати, а что же тогда за 3Д точки (облака) которые вы после рисовали на своем симуляторе. Вы их откуда брали если камера только локализировала сравнивая изображения? или я что-то перепутал? Ну, мы восстанавливали относительную ориентацию, а потом получали z для точек. Эти z заносились в базу. Потом при локализации информация о z использовалась в матчинге как дополнительная подсказка. [Ответ][Цитата]
Стр.5 (6): 1  2  3  4  [5]  6 << < Пред. | След. > >>