roboforum.ru

Собственно не стоит ли начать обсуждать такую штуку? Ну или хотя-бы какие-то общие подходы выявить и начать собирать интерфейсы для разных типов датчиков?

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

Поэтому я считаю что надо отделить методы использования информации о расстоянии до предметов от методов её получения и этим значительно упростить дальнейшее движение вперед.

Кроме прочего, это позволит быстро сравнивать несколько методов, например, 3Д-реконструкции по паре изображений.

К обсуждению приглашаются все желающие. Особое приглашение Vorral'у, SkyStorm'у - у них вроде сейчас уже деятельность связана с такими задачами.

Вроде из общих методов определения расстояния до произвольных предметов у нас бывает:
1. Методы предоставляющие 2-мерную карту расстояний:
1.1. 3D-реконструкция;
1.2. Optical-Flow;
1.х. Любой метод из пункта 2 + поворотное устройство;
2. Методы предоставляющие 1-мерную карту расстояний:
2.1. Лазерный сканер;
2.2. Лазерный уровень с камерой;
2.х. Любой метод из пункта 3 + поворотное устройство;
3. Методы предоставляющие 0-мерную карту расстояний (1 или несколько точек или конусов):
3.1. ИК-бамперы;
3.2. ИК-дальномеры SHARP;
3.3. Сонары;
3.4. Лазерная указка + камера;

Основные параметры всех методов измерения расстояния:
1. Максимальная и минимальная дальность обнаружения препятствия;
2. Вектор в локальных координатах робота, в направлении которого ориентирован датчик расстояния;
3. Форма области вокруг вектора в рамках которой препятствие может быть обнаружено этим датчиком;
4. Вероятность необнаружения препятствия датчиком или тип препятствия не обнаруживаемый датчиком;
5. Вероятность ложного обнаружения препятствия датчиком;

Основные параметры результата измерения:
1. Вектор в локальных координатах робота, вдоль которого меряем расстояние;
2. Измеренное расстояние;
3. Качественная оценка достоверности измерения (т.е. если получили мутный ответ, который с достаточной вероятностью может оказаться неверным, пусть даже 5-10%, об этом сообщаем пользователю информации);

что-то непонятно, предлагается обсуждать интерфейс или методы?

Интерфейс

Тогда ничо не понял. В первом посте есть ряд методов. Это ясно. А что тогда подразумевается под интерфейсом в данном случае?

На данный момент, переписываю систему 3Д реконструкции с целью включения в её состав модуля распознавания и улучшения качества карты глубины. Тема интересная, я например планирую использовать информацию о дальности точек для лучшего распознавания(масштабировать искомый образ требуется совсем в небольшом диапазоне) и простого отделения от фона таких объектов как человек. Можно также попытаться построить диаграмму направленности. В принципе, в первую очередь меня интересует навигация по помещению. По моему плану он должен будет достаточно однозначно характеризовать любой незнакомый объект и давать ему ID, а в последствии использовать этот и совокупность остальных ID(между ними будут существовать связи, могут разрушатся , некоторые предметы же перемещаются), как маяки, для определения своего положения. Карта глубины пока(новый алгоритм ещё в разработке) выглядит так.

Добавлено спустя 2 минуты 38 секунд:
Я понимаю тему так: есть информация о расстоянии/ях, как её лучше использовать.

Мне не очень ясна постановка вопроса.
Интерфейс передачи информации это что переменная int содержащая значение в mm.

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

realsystem писал(а):В первом посте есть ряд методов. Это ясно. А что тогда подразумевается под интерфейсом в данном случае?

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

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

Добавлено спустя 2 минуты 14 секунд:

Vorral писал(а):Я понимаю тему так: есть информация о расстоянии/ях, как её лучше использовать.

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

Добавлено спустя 2 минуты 13 секунд:

SkyStorm писал(а):Интерфейс передачи информации это что переменная int содержащая значение в mm.

Если бы у нас был датчик только типа "лазерный дальномер", тогда да;
А у нас есть ИК-дальномеры - тут узкий конус;
Сонары - тут широкий конус;
Камеры с 3д-реконструкцией или оптикал-флоу - тут может быть параметр типа "я не знаю какая тут дальность" или даже "я думаю что тут типа 2м дальность, но уверен в этом на 40%".

Я так и написал, что есть информация о расстоянии(неважно каким способом), и нужен общий стандарт её использования.

Vorral писал(а):Я так и написал, что есть информация о расстоянии(неважно каким способом), и нужен общий стандарт её использования.

1. Не использования, а передачи в использования.
2. Не только информация о расстоянии, но и информация о информации о расстоянии - степень достоверности, угол в котором мог оказаться предмет до которого измерили расстояние.

Ну тогда это некая плоскость, где есть либо одна точка расстояния(имеющая определённую форму и размер) или группа точек, каждая из которых имеет дополнительные параметры(в том числе достоверности). Каждая плоскость может иметь параметры: время, направление(компас) и угол(гироскоп).

время, направление или угол - это уже вспомогательные величины.

Я бы даже сказал корректно считать только время, остальное надо чтобы синхронно писалось в лог, а алгоритм уже сам вытягивает положение компаса на тот момент и т.п.

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

Архивирование - задача транспортного уровня. А вот структуру пакетов - это надо.

Во-первых надо взять мысль у MSRS. В пакете должна быть информация с датчика и время когда он это замерил. Тогда даже при задержках доставки информации с датчиков мы всё равно сможем очень точно сопоставить информацию о расстоянии (которое 3д-реконструкци считала 0.1сек и выдала только что) и направление с компаса (которое компас выдал 0.1сек назад).

Во-вторых надо понять действительно - какие примеры обработчиков информации у нас есть, можно ли вообще как-то обрабатывать эффективно инфу с тех же сонаров. Хотя несколько идей есть

Эффективно обрабатывать информацию с сонаров, можно только зная его местоположение, например, жёстко закреплён на фартуке робота. Тогда, если мы находились в движении, можно предположить, что наткнулись на препятствие или движущийся объект. Не было движения , остаётся только одно предположение, к нам кто то подошёл или что то подсунул . В случаи установления сонара на подвижной башне/голове, для точного понимания положения препятствия, относительно робота, нужно считать положение серв робота и положение его гироскопа и компаса(вдруг мы на горке, или вообще вверх ногами лежим).