roboforum.ru

citizen Скажите пожалуйста, на вашей картинке есть зеркало на уровне дальномера и где оно располагается?

Про зеркало уже на Гиктаймс обсуждалось: https://geektimes.ru/post/275442/#comment_9291026
Китайцев (RPlidar) никакие патенты не смущают, уже два года их делают.

Рабочая уверенная дальность работы дальномера порядка 3 м, можно наклонить вертикальную ось дальномера по ходу движения, и считать что с 2 х или 3х метров будет горизонт для данного направления, поворачивая робота вокруг своей оси можно будет получить сканирующий срез и в итоге получить частично объёмную хоть и медленно разворачиваемую картину. Конечно считая что робот перемещается по плоской поверхности, иначе надо добавлять гироскоп, можно одну из осей сделать с эксцентриситетом и поднимать опускать всего робота или только сам лидар.

Хоть кто бы сказал, зачем вообще это трехмерное сканирование нужно?
Тем более, что вне зависимости от типа дальномера, от 3d скана из одной точки толку мало, для получения адекватной модели помещения нужно делать несколько полных сканирований из разных точек, а потом как-то склеивать получившиеся облака точек (3d slam).

citizen Хотя бы для оценки возможности прохода робота по высоте или будет ехать пока выступающей частью не упрётся? что то вроде каждые 5 секунд угол изменяется для контроля нависающей мебели.

citizen писал(а):Хоть кто бы сказал, зачем вообще это трехмерное сканирование нужно?

Если у вас робот не выше чем робот пылесос, то 3D сканирование действительно ни к чему, но если робот (как наш LUM) достигает в высоту 1,2 метра, то выступающие углы столов, крестовины офисных кресел, коробки и другие предметы лежащие на полу, все это находится на разных уровнях высоты, а лидар, при сканировании, видит точки предметов лежащие только в плоскости сканирования на высоте установки самого лидара. Если, например на пути робота стоит гладильная доска, а лидар находится на высоте 0,5 метра, то в лучшем случае (если разрешение лидара позволит) он увидит трубки из которых сделаны ножки доски, саму гладильную поверхность, расположенную на высоте около метра, разумеется лидар не выхватит, ну а если высота робота больше метра, то он обязательно, проезжая мимо, снесет гладильную доску.

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

sned писал(а):Всё остальное о чём вы тут говорите это функции парктроника которые проще реализовать другими датчиками(бамперами и т.п.).

Представляю сколько "бамперов и других" датчиков придется поставить на нашего LUM-а чтобы контролировать препятствия по всей его высоте.

sned писал(а):Основное предназначение лидара это навигация и построение карты.

А разве обнаружение препятствий это не навигация? Или гладильная доска это не препятствие?

Обнаружение препятствий это не навигация.А вот дальнейшая их систематизация и классификация позволит использовать эти данные для навигационных целей. 3д сканирование это не для данных лидаров вот и весь посыл того что я хотел сказать.Кстати на вашей LUM платформе используются "многоуровневые" данные c кинекта или только средний срез ? Ведь у вас бампер тоже из датчиков наделан.

sned писал(а):Кстати на вашей LUM платформе используются "многоуровневые" данные c кинекта или только средний срез ? Ведь у вас бампер тоже из датчиков наделан.

LUM получает с кинекта картинку глубины и выделяет препятствия по всей картинке, вычитается уровень пола и препятствия выше роста самого робота так как под ними он может пройти. В LUM-e весь код самописный под С++, так что в нем мы сами делали обработку карты глубины. Сейчас пытаемся решить эту задачу на БЕЗbot-е который работает под ROS. Пакеты обрабатывающие облако точек или картинку глубины не позволяют убрать уровень пола, во всяком случае у нас не получилось, если просто расширять ширину сканирования в итоге все равно начинает захватываться пол. Так что сейчас пишем свой узел для "схлопывания" картинки глубины по всей высоте и передаче ее в laser_scan с вычитанием уровня пола.

sned писал(а):Ведь у вас бампер тоже из датчиков наделан.

Да бампер имеется, а раньше еще и ИК датчики стояли, но ИК сняли за ненадобностью, два кинекта полностью перекрывают все пространство спереди робота, без слепых зон, а бампера остались как "дань традициям" , просто демонтировать их не было смысла, хотя они и не отключены, но я не припомню ситуации когда LUM наталкивался ими на препятствия.

два кинекта полностью перекрывают все пространство спереди робота,

теперь понятно зачем вам такой ёмкий АКБ
а поворачивать кинект немного влево вправо не дешевле? (с точки зрения энергозатрат)

linvinus писал(а):а поворачивать кинект немного влево вправо не дешевле? (с точки зрения энергозатрат)

Вы не поняли, один кинект (на рисунке номер 3 - красный) смотрит вперед на нем реализовано построение карты, второй кинект (на рисунке номр 2 - желтый) смотрит вниз, он предназначен для детектирования препятствий на полу и перекрывает слепую зону третьего кинекта.

судя по картинке 3й кинект видит те же препятствия на полу что и 2й, только в дальней зоне.
если эти препятствия будут на карте рос то никакой проблемы с тем когда они попадут в мёртвую зону быть не должно, рос уже "помнит" о них. (я вас не критикую, просто мысли в слух)

linvinus писал(а):судя по картинке 3й кинект видит те же препятствия на полу что и 2й, только в дальней зоне.
если эти препятствия будут на карте рос то никакой проблемы с тем когда они попадут в мёртвую зону быть не должно, рос уже "помнит" о них. (я вас не критикую, просто мысли в слух)

Я ведь писал, вроде, что LUM работает не под ROS, на нем "крутится" наш собственный софт написанный на C++.