Если отображние PHP-файлов на плюсовые файлы фиксированное (одинаковое для всех PHP файлов), то можно написать макрос, включающий и правило генерации из PHP, и правила компиляции уже генеренного кода. Как бонус получаем ещё кеширование генерации и распараллеливание её на удаленных хостах.
Если же отображение зависит от исходного кода, то так не получится. Посмотрел немного доки KPHP - похоже, что набор генерируемых файлов зависит от набора функций и классов в исходном коде. Так что в текущем виде bazel и правда не подходит.
Почитайте что ли про time series cross-validation.
Спасибо, почитаю!
Или, опять таки, вы плохо сделали валидацию.
Это вот очень вероятно. Пока более-менее разобрался с тем, как надо делать, конкурс уже подходил к концу :)
я бы не называл это «удалось не ударить в грязь лицом».
По поводу этого пункта — да, спорное утверждение, согласен. В качестве небольшого оправдания: очень-очень не хотелось целиком тащить это конкретное решение. В нем также использовался только lightgbm, но были получше подобраны фичи и гиперпараметры, однако именно с такими фичами и гиперпараметрами мои модельки не заработали нормально.
Да, Танго впечатляет :) Хотя на самом деле ни в программной, ни в аппаратной частях нет ничего сложного. Насколько я понимаю, программная часть основана на appearance-based RGB-D SLAM, очень похожем на RTAB-Map, правда, очень хорошо оптимизированном под конкретное железо. Широкоугольная камера (120 градусов) позволяет достаточно быстро двигаться без потери трекинга. Самое впечатляющее — это построение меша почти в реалтайме на планшете :) Кстати, посмотреть бы, как оно будет работать со слаботекстурированными объектами (думаю, не зря автор презентации принес деревянный стол с хорошей текстурой :) )
Сейчас очень рапространены алгоритмы на основе сверточных сетей, они дают очень неплохие результаты. Вот здесь и здесь можно посмотреть, на что способны современные алгоритмы (не только на основе нейросетей). Многие из них находятся в открытом доступе.
Тут разве что по wifi, который везде есть :) Правда, в помещениях гораздо полезнее знать свое положение относительно местности, а не от точки взлета, ибо препятствий много :) Ну, и как обычно, смешивать показания ИНС с данными SLAM.
Сенсор — в смысле depth-сенсор? :) Если речь о нем, то тут засада не только в производительности, но и в алгоритмах. Нет универсальных SLAM, по крайней мере, сейчас. Алгоритмы типа ElasticFusion работают при некоторых ограничениях: хорошем освещении, достаточно рельефной и текстурированной сцене. Даже использование LiDAR'ов не избавляет от этих проблем в общем случае.
Для нормальной работы всех таких алгоритмов необходимо добиться реалтайма. Для LSD SLAM на Raspberry это вряд ли получится, ORB SLAM и PTAM можно попробовать, особенно ORB — извлечение ORB-фич достаточно быстрое, а на Raspberry Pi 2 уже неплохой CPU. Плюс можно попробовать использовать небольшое разрешение картинки. Мы пока не пробовали запускать все это onboard, однако в первом приближении ответ скорее "Да, хватит" :)
Собственно, SLAM и есть Simultaneous Localization And Mapping — локализация и картография одновременно. То есть, такие алгоритмы всегда выдают и карту (в каком-то виде), и местоположение. Текущее положение камеры на первой гифке отмечено красной пирамидкой.
Не совсем: алгоритм не выдает путь движения камеры как таковой, только граф ключевых кадров. В узлах графа находятся собственно ключевые кадры, а ребрами соединены те кадры, которые трекер смог связать друг с другом при помощи механизма замыкания циклов (loop closure). Цвет линии показывает, насколько велика вероятность такой связи (зеленые — большая вероятность, красные — низкая).
Гифки с изображениями нашего офиса: в виде облака точек (с путем следования камеры) и кусочек видео с камеры (естественно, качество не соответствует настоящему видеопотоку, только для представления о форме комнаты)
Мы немного изменяли код, чтобы извлечь ковариацию позиционирования и подставлять внешнее значение позы при потере трекинга, но в целом алгоритм не трогали, он работает из коробки как надо. Возможно, Вам придётся что-то изменять, если Вы будете использовать разрешение, сильно отличное от 640х480 — некоторые параметры захардкожены.
Проблема в том, что будет накапливаться ошибка интегрирования — значение скорости будет «уплывать» на достаточно длительном отрезке времени. Теоретически можно попробовать считать масштаб из отношения ускорений, но у меня получилось очень большое расхождение даже с использованием сглаживания и идентификации кривых на большом временном окне.
Очень неплохая идея, мы к ней пришли не сразу :) Но тут есть проблема с двойным интегрированием: не получится рассчитывать перемещение за короткий период только по ИНС, а на длинном периоде накапливается большая ошибка интегрирования. При ходьбе есть моменты, когда скорость ноги гарантированно равна нулю, и алгоритмы этим пользуются, чтобы скомпенсировать ошибку интегрирования ускорения.
Вы правы, в разы — это мягко говоря.
Стереопара на основе двух китайских поделок выдает после получасовой отстройки приемлемую карту глубины. А вот для монокулярного мэппинга камера нужна много лучше (дороже), да и результат будет скорее всего хуже (особенно потому, что не даст определить масштаб сцены). Думаю, монокулярную картографию надо применять только в случаях жестких технических ограничений на использование одной камеры (наш случай), или небольших требований к качеству получаемых карт, или в помещениях.
Насколько я знаю, SDK как для AR.Drone, так и для Bebop (весьма интересный относительно новый дрон от Parrot) предоставляют только доступ к контроллеру, навигационным данным с ИНС, видеопотокам и конфигурации дрона. Самое продвинутое, на что способен SDK — распознавать маркеры определенной формы и цвета.
Какие технические детали Вас могли бы заинтересовать? Работа именно SLAM с одной камерой, настройка всех компонент системы, платформа?
Если отображние PHP-файлов на плюсовые файлы фиксированное (одинаковое для всех PHP файлов), то можно написать макрос, включающий и правило генерации из PHP, и правила компиляции уже генеренного кода. Как бонус получаем ещё кеширование генерации и распараллеливание её на удаленных хостах.
Если же отображение зависит от исходного кода, то так не получится. Посмотрел немного доки KPHP - похоже, что набор генерируемых файлов зависит от набора функций и классов в исходном коде. Так что в текущем виде bazel и правда не подходит.
Рассматривали ли bazel и его удаленное исполнение? Если да, то чем он не подошёл?
То есть, это можно использовать как холодильник? :)
Спасибо, почитаю!
Это вот очень вероятно. Пока более-менее разобрался с тем, как надо делать, конкурс уже подходил к концу :)
По поводу этого пункта — да, спорное утверждение, согласен. В качестве небольшого оправдания: очень-очень не хотелось целиком тащить это конкретное решение. В нем также использовался только lightgbm, но были получше подобраны фичи и гиперпараметры, однако именно с такими фичами и гиперпараметрами мои модельки не заработали нормально.
Гифки с изображениями нашего офиса: в виде облака точек (с путем следования камеры) и кусочек видео с камеры (естественно, качество не соответствует настоящему видеопотоку, только для представления о форме комнаты)
Стереопара на основе двух китайских поделок выдает после получасовой отстройки приемлемую карту глубины. А вот для монокулярного мэппинга камера нужна много лучше (дороже), да и результат будет скорее всего хуже (особенно потому, что не даст определить масштаб сцены). Думаю, монокулярную картографию надо применять только в случаях жестких технических ограничений на использование одной камеры (наш случай), или небольших требований к качеству получаемых карт, или в помещениях.
Какие технические детали Вас могли бы заинтересовать? Работа именно SLAM с одной камерой, настройка всех компонент системы, платформа?