roboforum.ru

Outcaster писал(а):

=DeaD= писал(а):...Неважно пока как...

Вот это как раз и важно!

Ну вот смотрите:

1. Я уже научился получать информацию из пары откалиброванных изображений о части препятствий на пути робота;

2. Я сейчас занимаюсь задачей распознавания с веб-камеры набор "маяков" которые содержат дополнительную информацию;

(По поводу 1 и 2 - см. тему ориентирование в 3D-пространстве)

Как можно будет работать с этим в вашей парадигме?

=DeaD= писал(а):Как можно будет работать с этим в вашей парадигме?

Как раз десь я сейчас нахожусь.
Только за базовый вариант беру ориентирование с использованием всего одной, но подвижной камеры. Пока всё идет неплохо - через неделю, думаю, кое-что выложу.

Outcaster писал(а):

=DeaD= писал(а):Как можно будет работать с этим в вашей парадигме?

Как раз десь я сейчас нахожусь.
Только за базовый вариант беру ориентирование с использованием всего одной, но подвижной камеры. Пока всё идет неплохо - через неделю, думаю, кое-что выложу.

Ну хотя-бы эскизно, просто хотя-бы идеи? Я просто совсем не представляю как в функциональном подходе можно работать с такими данными...

Эскизно, в первом приближении пока это выглядит как пачка многослойных полиномов, переменными которого служат элементы матрицы изображения. Постепенно малозначимые связи отбрасываються, остаються более значимые. Это ОЧЕНЬ сырой вариант, снова-же, решение "в лоб", с последующей оптимизацией. Пока что добился: ищет контуры, находит "одинаковые" зоны, не обламываеться на бликах и полупрозрачности, находит расстояние до каждой из точек изображения, и по тенденции перемещения "группирует" воедино. Справляеться с отражениями, не смущаеться, если зеркала кривые (правда, ещё не умеет определять где именно сама зеркальная поверхность находиться). Выдаёт матрицу перемещений, матрицу "однотипности", матрицу расстояний. Кстати, всплыло, что камеру предварительно откалибровать нужно (и как это сделать), иначе очень много глупостей получаеться.

Здесь конечно немного офф, но все-таки, из всего что указано:
1. Принцип определения расстояния до точек изображения - optical-flow?
2. И вообще все эти фишки - на реальных изображениях / парах / последовательностях изображений?

1. Чесно скажу - незнаю , я его в "изоляции от внешнего мира" разрабатывал. Суть метода в соответствующей теме выложу.
2. Обработка фотографий, сделаных цифровым фотоаппаратом.

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

Если не жалко и не секрет, выложите результаты - фотка и что на ней найдено, обработано и т.п.

=DeaD= писал(а):Если не жалко и не секрет, выложите результаты - фотка и что на ней найдено, обработано и т.п.

Да конечно не секрет, и безусловно нежалко...пооформляю удобочитатабельно, и сразу выложу (уже оформляю).

Похоже, не у меня одного похожие концепции возникают :
http://webcenter.ru/~korn/mind/algorithm.html

Ну ничего себе "похожие концепции" понятно что в той задаче нужно нормировать сигналы, если они управляют заведомо неизвестными органами... ну вы однако сравнили ИИ с представлением сигналов в управляющих и информационных каналов... аж долго читал и не мог понять в чем сходство-то

=DeaD= писал(а):Ну ничего себе "похожие концепции" понятно что в той задаче нужно нормировать сигналы, если они управляют заведомо неизвестными органами... ну вы однако сравнили ИИ с представлением сигналов в управляющих и информационных каналов... аж долго читал и не мог понять в чем сходство-то

Ну так вот оно и есть!
Любая управляющяя последовательность комад для устройства может быть представлена в виде функциональной зависимости от времени Command = F_Command(t)
У любого устройства есть функциональная зависимость от команды и времени (примем, что ни одно устройство не способно мгновенно реагировать - это в значительной мере относится к механике):
Device_Result = F_Device(t,Command)
Действия устройств тем или иным образом влияют на датчики, которые, как правило, тоже не мгновенно реагируют:
Sensor_Result = F_Sensor(t, Device_Result)
Показания сенсоров используються для формирования командных последовательностей, соответственно, первая формула немного измениться:
Command = F_Command(t, Sensor_Result)
Вот круг и замкнулся. Так к чему я и при чём здесь ИИ? Примем, что заранее неизвесно (хотя и можно прогнозировать/прощитывать после исследований, да и то коряво - всё будет меняться со временем) какое устройство и каким образом на какой сенсор влияет. Зато, если наложить условие, что устройства отображаються в виде именно цифр, количество и направление потоков известно, то вполне реально определить их функциональные зависимости уже на месте, в "боевой" обстановке - на этапе обучения.

Так, первый, корявый компилер заработал - и неплохо заработал.
Первые проги обкатываю, глюки/грабли выискиваю.

Первые впечатления:
1) Так сложно отвыкнуть от пошаговости...
2) Текст довольно компактный, но не читабельнее чем на С++, зато понимаеться (мною по крайней мере) как-то проще...
3) При правильном подходе, прога переделываеться в считанные минуты.
4) Нет явной прямой работы с аппаратурой...но это скорее плюс, чем минус - сама аппаратура описываеться извне, и не пудрит глаза...
5) Язык явно не для машин 5-го поколения...

Наблюдая работу этой штукенции, внезапно подумал: а ведь всё это подозрительно похоже на эмулятор цифро-аналогового компьютера, о котором писал Влад. Есть прямая аналогия:
Цифровая часть - сам компилятор;
Аналоговая часть (решающие узлы АВМ) - операторы;
Входы/выходы - драйвера устройств;
Текст программы - правила коммутации аналоговых частей цифровой частью...

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