Ты ждал и вот наконец-то! Теперь в Endeavor ты можешь тренить самостоятельно, а не только под присмотром тренера!
Время для твоих тренировок: с понедельника по пятницу с 11:00 до 17:00
Самое крутое, что в этот промежуток ты можешь тренить час, два, три – столько, сколько тебе нужно для идеального результата. И при этом платишь как за одну тренировку !
— 1 посещение – 400 руб.
— 6 посещений – 2 100 руб.
— 12 посещений – 3 600 руб.
— 24 посещения – 7 200 руб.
— 48 посещений – 14 400 руб.
*Посещения – пребывание в клубе в промежутке с 11:00 до 17:00
Тренируйся в самом современном, большом и новом клубе города. Будь на драйве с Endeavor.
За последние несколько лет мы стали свидетелями внедрения технологий искусственного интеллекта в нашу повседневной жизни — от роботов-пылесосов до беспилотных дронов. Все они, управляемые искусственным интеллектом, уже являются для нас обыденностью. Но несмотря на это, процесс разработки, от проектирования до реализации, занимает годы и обходится не дешево. Кроме того, алгоритмы машинного обучения требуют большие данные и нет никаких гарантий, что в конечном счете все сработает.
Рано или поздно каждый разработчик приходит к выводу, что перед созданием реального робота необходимо протестировать концепт в симуляции, отладить все системы и, в конце концов, понять, тот ли путь разработки был выбран.
Похожие мысли были и у доктора Эндрю Ховарда, когда он со своим учеником Нейтоном Кенигом в 2002 году приступил к разработке 3D симулятора Gazebo в Университете Южной Калифорнии. Концепция симулятора высокой точности возникал из-за необходимости тестировать роботов в различных сложных условиях вне помещений. На первых этапах разработки такой подход позволяет сэкономить время и средства на приобретении необходимого оборудования.
В этой серии статей я бы хотел поделиться своим опытом симуляции и обучения беспилотного автомобиля имея только одну обычную камеру в качестве сенсора.
Всем привет. Я учусь на магистратуре (Computer Science, M.S.) прикладной информатики в Берлинском Университете Прикладных Наук (HTW-Berlin).
В рамках своей курсовой я работаю над методами обучения автономных роботов в симулируемой среде с использованием ROS [1], Gazebo [2] и OpenAI Gym [3]. Эта курсовая работа разделена на две части.
Первая часть посвящена разработке фреймворка, который бы упростил тестирование Reinforcement Learning (обучение с подкреплением) алгоритмов на различных автономных роботах внутри симуляции Gazebo.
Во второй части я сконцентрируюсь на реализации алгоритма для автономного вождения. Над этим я буду работать весь следующий семестр, поэтому в этой и следующих статьях речь пойдет в основном о реализации окружения OpenAI Gym для Gazebo. Непосредственно Reinforcement Learning (RL) будет затронут поверхностно.
Полный код проекта можно найти тут.
Системные требования
- Ubuntu 18.04 или Windows WSL Ubuntu 18.04
- Python 2.7
- pip
- Tenserflow CPU или GPU
Мы будем использовать ROS версии Melodic. Эта версия имеет несколько ограничений и самое значительное из них — это Ubuntu 18 (также есть возможность установить ROS на Windows WSL и на Ubuntu Headless, но об этом в другой раз). Кроме того ROS все еще не поддерживает Python 3.
Часть первая: введение
В этой пилотной части я коротко расскажу о технологиях, которые будут использоваться для создания окружения. Также опишу процесс установки и в конце мы запустим полноценную симуляцию, которой можно будет управлять через Gym API.
ROS: «не изобретать велосипед»
Robot Operating System (ROS) — это фреймворк для программирования роботов. ROS является «программным клеем», который дает возможность разработчикам сосредоточиться на своей конкретной задаче. Хотя ROS не является операционной системой, он предоставляет сервисы, такие как аппаратная абстракция, низкоуровневое управление устройствами, реализация часто используемых функций, передача сообщений между процессами и управление пакетами (плагинами).
ROS спроектирована как слабо связанная система, в которой процесс, называемый узлом (node), должен отвечать за одну задачу. Узлы общаются друг с другом, используя сообщения, проходящие через логические каналы, называемые темами (topics). Каждый узел может отправлять или получать данные от другого узла, используя шаблон проектирования издатель-подписчик (publish–subscribe pattern)
Для ROS, уже реализованы драйвера, позволяющие единым образом работать со многими устройствами, такими как контроллеры, GPS, камеры, лазерные дальномеры и т. п.
И так, установим ROS Melodic (полная инструкция)
По какой-то причине полный пакет установки не включает в себя некоторые необходимые пакеты. Установим их отдельно:
Мы не будем останавливаться на них подробно. Они нужны для управления нашим роботом, речь о котором пойдет дальше.
Gazebo
Gazebo — это динамический 3D симулятор с открытым исходным кодом, который развивается Open Source Robotic Foundation и довольно тесно взаимодействует с ROS. Gazebo позволяет точно и эффективно моделировать роботов как в сложных условиях помещений, так и снаружи.
Симулятор состоит из сервера gzserver, который занимается просчетом физики, столкновений и симуляцией сенсоров. К серверу могут подсоединяться клиенты, например gzclient (для десктопа) и gzweb (для браузера). Именно они занимаются рендерингом моделей.
Все это дает возможность тестировать сложные робототехнические системы в виртуальном пространстве гораздо быстрее и без риска нанести ущерб дорогостоящим настоящим роботам.
Gazebo включен в полный установочный пакет ROS, поэтому дополнительно ничего устанавливать не нужно. Для headless конфигурации требуется gzweb. О нем я расскажу в следующих частях.
OpenAI Gym
OpenAI — некоммерческая исследовательская компания, занимающаяся искусственным интеллектом, одним из основателей которой является Илон Макс.
OpenAI Gym — это библиотека Python, которая предоставляет API для разработки и сравнения RL алгоритмов с огромным количество виртуальных сред и общим API. Gym уже имеет множество готовых окружений, в том числе для игр Atari.
openai_ros
Мой проект основан на пакете openai_ros. Этот пакет реализует архитектуру, которая была предложена командой The Construct. Ребята из The Construct разработали общую структуру, которая реализует необходимый API для управления симуляцией и описывает API для интеграции Gazebo в Gym, требующий минимальной реализации. Предложенная структура состоит из трех логических слоев (фактически можно использовать любое количество), самый низкий из них является еще одним “клеем”, который соединяет Gym API с Gazebo. Подробней об этом в следующей части, когда мы будем разбирать код.
Собираем все вместе
Для начала нам нужно создать рабочую директорию для catkin. catkin — это система автоматизации сборки наподобие CMake, которая включена по умолчанию в пакет установки ROS:
и склонировать необходимые пакеты ROS.
MIT Racecar
Нам потребуется разработанная в MIT модель робота со всеми сенсорами.
openai_ros
neuroracer
Ну и, собственно, сам проект
Далее нужно скомпилировать все эти пакеты
Так же нужно установить все необходимые python библиотеки.
Запуск симуляции
Для запуска любого пакета ROS нам прежде всего нужно загрузить в текущую сессию терминала все ROS пакеты, которые мы скомпилировали:
Теперь мы можем запустить симуляцию Racecar робота:
Эта команда запустит мастер сервер ROS, сервер Gazebo вместе с его UI (на десктопе), загрузит робота и мир для него.
И тоже самое во втором терминале для нашего RL алгоритма:
Эта команда запустит наш neuroracer_gym_rl пакет, который реализует простенький Q-Learning алгоритм в нашем окружении Gym. Его мы разберем в следующей части.
Те, кому не терпится, могут найти исходный код тут. Забегая вперед, скажу, что после нескольких дней обучения на сервере с картой GeForce GTX 1080 Ti 11GB RAM, этот простой алгоритм толком ничему не научился. В следующей части я причислю возможные причины, но вы уже сейчас можете поэкспериментировать со своей реализацией.
Заключение
И так, у нас есть полностью рабочая симуляция автономного автомобиля и готовый шаблон RL алгоритма. В следующий части мы подробней разберем openai_ros и обсудим установленные на роботе сенсоры.После этого я покажу как реализовать свои алгоритмы и какие проблемы могут возникнуть во время обучения.
PS: Это мой первый опыт написания статьей. По этому не стесняйтесь писать, если вы нашли ошибки или у вас есть идеи, или конструктивная критика. Я постараюсь учесть это в следующих частях.
Ссылки
[1] (M. Quigley, K. Conley, B. Gerkey, J. Faust, T. Foote, J. Leibs, R. Wheeler, and A. Y. Ng. Ros: an open-source robot operating system. In ICRA workshop on open source software, volume 3, page 5. Kobe, Japan, 2009.
[2] N. P. Koenig and A. Howard. Design and use paradigms for gazebo, an open-source multi-robot simulator. In IROS, volume 4, pages 2149–2154. Citeseer, 2004.
[3] L. P. J. S. J. S. J. T. W. Z. Greg Brockman, Vicki Cheung. Openai gym, 2016, arXiv:1606.01540
Вы можете помочь и перевести немного средств на развитие сайта
Gym is a toolkit for developing and comparing reinforcement learning algorithms. It makes no assumptions about the structure of your agent, and is compatible with any numerical computation library, such as TensorFlow or Theano.
The gym library is a collection of test problems — environments — that you can use to work out your reinforcement learning algorithms. These environments have a shared interface, allowing you to write general algorithms.
Installation
To get started, you’ll need to have Python 3.5+ installed. Simply install gym using pip :
And you’re good to go!
Building from Source
If you prefer, you can also clone the gym Git repository directly. This is particularly useful when you’re working on modifying Gym itself or adding environments. Download and install using:
You can later run pip install -e .[all] to perform a full installation containing all environments. This requires installing several more involved dependencies, including cmake and a recent pip version.
Environments
Here’s a bare minimum example of getting something running. This will run an instance of the CartPole-v0 environment for 1000 timesteps, rendering the environment at each step. You should see a window pop up rendering the classic cart-pole problem:
It should look something like this:
Normally, we’ll end the simulation before the cart-pole is allowed to go off-screen. More on that later. For now, please ignore the warning about calling step() even though this environment has already returned done = True .
If you’d like to see some other environments in action, try replacing CartPole-v0 above with something like MountainCar-v0 , MsPacman-v0 (requires the Atari dependency), or Hopper-v1 (requires the MuJoCo dependencies). Environments all descend from the Env base class.
Note that if you’re missing any dependencies, you should get a helpful error message telling you what you’re missing. (Let us know if a dependency gives you trouble without a clear instruction to fix it.) Installing a missing dependency is generally pretty simple. You’ll also need a MuJoCo license for Hopper-v1 .
Observations
If we ever want to do better than take random actions at each step, it’d probably be good to actually know what our actions are doing to the environment.
The environment’s step function returns exactly what we need. In fact, step returns four values. These are:
- observation (object): an environment-specific object representing your observation of the environment. For example, pixel data from a camera, joint angles and joint velocities of a robot, or the board state in a board game.
- reward (float): amount of reward achieved by the previous action. The scale varies between environments, but the goal is always to increase your total reward.
- done (boolean): whether it’s time to reset the environment again. Most (but not all) tasks are div >done being True indicates the episode has terminated. (For example, perhaps the pole tipped too far, or you lost your last life.)
- info (dict): diagnostic information useful for debugging. It can sometimes be useful for learning (for example, it might contain the raw probabilities behind the environment’s last state change). However, official evaluations of your agent are not allowed to use this for learning.
This is just an implementation of the >action , and the environment returns an observation and a reward .
The process gets started by calling reset() , which returns an initial observation . So a more proper way of writing the previous code would be to respect the done flag:
This should give a video and output like the following. You should be able to see where the resets happen.
Spaces
In the examples above, we’ve been sampling random actions from the environment’s action space. But what actually are those actions? Every environment comes with an action_space and an observation_space . These attributes are of type Space , and they describe the format of valid actions and observations:
The Discrete space allows a fixed range of non-negative numbers, so in this case val >action s are either 0 or 1. The Box space represents an n -dimensional box, so val >observations will be an array of 4 numbers. We can also check the Box ’s bounds:
This introspection can be helpful to write generic code that works for many different environments. Box and Discrete are the most common Space s. You can sample from a Space or check that something belongs to it:
For CartPole-v0 one of the actions applies force to the left, and one of them applies force to the right. (Can you figure out which is which?)
Fortunately, the better your learning algorithm, the less you’ll have to try to interpret these numbers yourself.
Gym comes with a diverse suite of environments that range from easy to difficult and involve many different kinds of data. View the full list of environments to get the birds-eye view.
- Classic control and toy text: complete small-scale tasks, mostly from the RL literature. They’re here to get you started.
- Algorithmic: perform computations such as adding multi-digit numbers and reversing sequences. One might object that these tasks are easy for a computer. The challenge is to learn these algorithms purely from examples. These tasks have the nice property that it’s easy to vary the difficulty by varying the sequence length.
- Atari: play classic Atari games. We’ve integrated the Arcade Learning Environment (which has had a big impact on reinforcement learning research) in an easy-to-install form.
- 2D and 3D robots: control a robot in simulation. These tasks use the MuJoCo physics engine, which was designed for fast and accurate robot simulation. Included are some environments from a recent benchmark by UC Berkeley researchers (who incidentally will be joining us this summer). MuJoCo is proprietary software, but offers free trial licenses.
The registry
gym ’s main purpose is to prov >gym.envs.registry :
This will give you a list of EnvSpec objects. These define parameters for a particular task, including the number of trials to run and the maximum number of steps. For example, EnvSpec(Hopper-v1) defines an environment where the goal is to get a 2D simulated robot to hop; EnvSpec(Go9x9-v0) defines a Go game on a 9×9 board.
These environment >v0 so that future replacements can naturally be called v1 , v2 , etc.
It’s very easy to add your own enviromments to the registry, and thus make them available for gym.make() : just register() them at load time.
Reinforcement learning (RL) is the subfield of machine learning concerned with decision making and motor control. It studies how an agent can learn how to achieve goals in a complex, uncertain environment. It’s exciting for two reasons:
- RL is very general, encompassing all problems that involve making a sequence of decisions: for example, controlling a robot’s motors so that it’s able to run and jump, making business decisions like pricing and inventory management, or playing video games and board games. RL can even be applied to supervised learning problems with sequentialorstructured outputs.
- RL algorithms have started to achieve good results in many difficult environments. RL has a long history, but until recent advances in deep learning, it required lots of problem-specific engineering. DeepMind’s Atari results, BRETT from Pieter Abbeel’s group, and AlphaGo all used deep RL algorithms which did not make too many assumptions about their environment, and thus can be applied in other settings.
However, RL research is also slowed down by two factors:
- The need for better benchmarks. In supervised learning, progress has been driven by large labeled datasets like ImageNet. In RL, the closest equivalent would be a large and diverse collection of environments. However, the existing open-source collections of RL environments don’t have enough variety, and they are often difficult to even set up and use.
- Lack of standardization of environments used in publications. Subtle differences in the problem definition, such as the reward function or the set of actions, can drastically alter a task’s difficulty. This issue makes it difficult to reproduce published research and compare results from different papers.