Привет!
Некоторое время не следил за темой — возможно ребята (из / вместе с) ros уже придумали какой — нибудь комплексный подход. Мне в голову пришло следующее:
1 — вроде у slam rtabmap есть некий localization mode и там говорится о multi-session mapping.
возможно, локализацию в уже построеной карте можно положить на этот узел.
2 — дальше в зависимости от того, что у нас за железо (ходящее, ездиющее, ползающее) и насколько оно маневренное — берем из карты какой — нибудь упрощенный агрегат — octomap, occupancy_map для планирования маршрута / движения
3 — дальше — берем что — нибудь для планирования (от простого move_base до сложного gazebo) и просим железяку напрямую или косвенно проделывать те финты, которые предлагает планировщик чтобы дойти туда, куда планировалось.
Тут же обработка внештатных ситуаций вида "не смог" и т.п.
Здесь могу соврать — с этим почти не работал.
Где это считать? Хороший вопрос.
Мне кажется хорошей идеей считать это на отдельной машинке — думаю, встраиваемое железо, которому хватит сил bubuntu + ros + slam + планировщик — дорогое и в этом мало смысла.
Интересная задачка — стриминг point_cloud по сети — тоже недешево (они вроде большие).
Хотя, наверняка их пережимать можно.
Писать скорее всего придется мало — и в основном конфиги =)
Самое сложное уже давно реализовано.
Сейчас я разрабатываю систему автономной навигации вместе с Alex_ME для AR600E.
Этим обусловлено наличие пары пакетов для антропоморфных роботов в статье =)
На сбор этой информации ушло довольно много времени.
Надеюсь, кому — нибудь этот материал окажется полезным.
Здорово! Интересная реализация поисковых запросов, думал будет сложнее.
Думаю, вашу реализацию можно упростить при помощи regex'ов.
Можно еще поиграться с библиотеками NTLK (Natural Language Toolkit) и ее аналогом для русского языка (как зовут — не помню). Вроде бы при помощи NTLK можно искать синонимы и еще много чего интересного, связанного с обработкой языковых конструкций.
В видео на качестве сказалось то, что я использовал очень слабый микрофон своего ноутбука.
И все же, мне кажется, что то, как говорит синтезатор Google в разы лучше например этого:
Английский на главной странице мягко говоря хромает :)
Спасибо, слона то я и не приметил.
Можно в Redis сделать ключ и выставить expire для него.
У меня были попытки использовать Redis в этой работе. Но что — то пошло не так.
Хочу задать вопрос: Что лучше в плане сбережения ресурсов и быстродействия:
держать Redis или N-ое число потоков типа:
Thread.new do
sleep(GameSessionLength)
GameSession.is_active = false
end
И насколько большой этот разрыв в производительности?
Привет!
Некоторое время не следил за темой — возможно ребята (из / вместе с) ros уже придумали какой — нибудь комплексный подход. Мне в голову пришло следующее:
1 — вроде у slam rtabmap есть некий localization mode и там говорится о multi-session mapping.
возможно, локализацию в уже построеной карте можно положить на этот узел.
2 — дальше в зависимости от того, что у нас за железо (ходящее, ездиющее, ползающее) и насколько оно маневренное — берем из карты какой — нибудь упрощенный агрегат — octomap, occupancy_map для планирования маршрута / движения
3 — дальше — берем что — нибудь для планирования (от простого move_base до сложного gazebo) и просим железяку напрямую или косвенно проделывать те финты, которые предлагает планировщик чтобы дойти туда, куда планировалось.
Тут же обработка внештатных ситуаций вида "не смог" и т.п.
Где это считать? Хороший вопрос.
Мне кажется хорошей идеей считать это на отдельной машинке — думаю, встраиваемое железо, которому хватит сил bubuntu + ros + slam + планировщик — дорогое и в этом мало смысла.
Интересная задачка — стриминг point_cloud по сети — тоже недешево (они вроде большие).
Хотя, наверняка их пережимать можно.
Писать скорее всего придется мало — и в основном конфиги =)
Самое сложное уже давно реализовано.
Сейчас я разрабатываю систему автономной навигации вместе с Alex_ME для AR600E.
Этим обусловлено наличие пары пакетов для антропоморфных роботов в статье =)
На сбор этой информации ушло довольно много времени.
Надеюсь, кому — нибудь этот материал окажется полезным.
Что до Yandex'a, то API вроде бесплатное лишь на месяц.
https://tech.yandex.ru/speechkit/cloud/
А gTTS ведет прямиком в "черную ящик" Google'а.
Здорово! Интересная реализация поисковых запросов, думал будет сложнее.
Думаю, вашу реализацию можно упростить при помощи regex'ов.
Можно еще поиграться с библиотеками NTLK (Natural Language Toolkit) и ее аналогом для русского языка (как зовут — не помню). Вроде бы при помощи NTLK можно искать синонимы и еще много чего интересного, связанного с обработкой языковых конструкций.
И все же, мне кажется, что то, как говорит синтезатор Google в разы лучше например этого:
У меня были попытки использовать Redis в этой работе. Но что — то пошло не так.
Хочу задать вопрос: Что лучше в плане сбережения ресурсов и быстродействия:
держать Redis или N-ое число потоков типа:
И насколько большой этот разрыв в производительности?