Автономность

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

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

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

1) Управление по скорости.

Робот должен выполнять команды линейного перемещения (вперед-назад) и углового вращения (по часовой стрелке - против) с заданными скоростями. Также он должен высчитывать текущую скорость, и, исходя из нее, пройденное расстояние. В самом простом случае корректность выполнения команд достигается ПИД-регулятором, а подсчет текущей скорости - датчиком холла или энкодером.

2) Локализация на местности.

Робот должен понимать, где конкретно он сейчас находится. Если это улица, то тут все относительно просто. Устанавливаем на робота GPS и получаем абсолютные координаты с погрешностью в +-15 метров. Либо GPS RTK для точности в пару сантиметров, тут уже от задач зависит. Если же мы находимся в помещении, то вариантов несколько больше: маячки, метки, камеры, и.т.д. Лично мне больше всего нравится локализация при помощи Лидара. Он и точность неплохую дает, и позволяет обеспечить...

3) Динамическое построение маршрута.

Робот должен адаптироваться к изменению окружения. Если ему приходит задача перемещения из точки "А" в точку "Б", то сначала строится маршрут, в котором присутствуют только статические препятствия, нанесенные на карту помещения, которая может содержаться в памяти робота (стены, мебель и прочие неподвижные вещи). Если карты нет, то робот считает, что и статических препятствий тоже нет и маршрут строится по прямой линии, а все реальные препятствия считаются динамическими. Собственно, сканирование местности происходит при помощи того же самого лидара, что и отвечает за локализацию.

Выглядит в голове у робота это все, примерно, вот так. Заранее простите за пояснения в пэинте :)

Здесь, например, красными линиями обозначены данные, полученные с лидара. Черная область вокруг - запрещенная (если робот там окажется - он врежется в препятствие), белая область - разрешенная (никто никуда не врежется), серая - неизведанная.

В итоге, пройдя все эти этапы, мы получаем достаточно универсальную систему, которая может допиливаться под конкретные задачи и становиться гораздо более прикладной. Например, катать ikomas'a по офису. Собственно, а почему бы и нет?

Разрабатываю таких роботов. Один из проектов практически один в один такой же, с Лидаром и коллаборативным манипулятором (который не причиняет вреда человеку при столкновении).

И, о боже, я могу быть немного полезным для общества, объяснив политику ценообразования подобных устройств:

Основная сложность создания такого робота заключается, внезапно, в механике манипулятора ибо они (лидеры рынка и KUKA в их числе) позиционируют себя как устройства с ОЧЕНЬ большой точностью (до 0.1 мм на конечном схвате). А для этого нужно покупать ОЧЕНЬ дорогие планетарные редукторы (Shimpo или harmonic drive. Других альтернатив на рынке тупо нет. Стоит в районе 600-1500 евро за штуку). И это на каждый джоинт... На каждую степень свободы в смысле.

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

Дальше. Перейдем к самому роботу. Хрен знает, какой Лидар стоит на этом конкретном товарище, но в общем и целом это чертовски дорогая хрень. Да, в роботах-пылесосах тоже лидар, но для больших контор подобные говноустройства (как они считают, а лично мне нравятся, раздолбать не страшно) неприемлемы и они хотят ДорогоБогато и ставят всякие Velodyne с ценами от 6k+ евро. Пару-тройку штук.

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

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

Аккумулятор - дорогой. Когда-то давно я тоже думал мол почему, ведь power bank'и есть вполне себе бюджетные, но они выдают 5 вольт. А тут нужно 48. Поэтому и весить аккум будет где-то 20-30 кг и стоить под 2k евро.

Еще из основных трат будут 2-4 колеса с энкодерами, чтобы определять одометрию - пройденное расстояние исходя из вращения колес и управляющее железо. Ну и все то, что я не брал в расчет раньше - затраты за программирование и обучение всяческим фишечкам. Это компания вкладывает в изддержки, поднимает ценник и, вуаля, вот он и фул прайс) Как-то так.

Примечание! Я держу в руках микроконтроллер не более месяца, это самый адекватный проект, разработанный мною, тем более мне всего 15 лет.

Всем привет! Сегодня я расскажу и покажу свое первое творение на микроконтроллере Arduino UNO, что оно умеет, как его настраивать и собирать. Прежде всего, оговорюсь что я собирал всего лишь макет, который не предназначен для суровых уровней влажности в теплицах. Для тепличных микроконтроллеров нужен герметичный корпус, который не даст вашей электронике умереть от окисления.  Еще, на макете стоит маленький серво-привод, который тянет 1,6 килограмм. Если вы захотите повторить данный проект для своей теплицы, берите сервопривод мощнее чем у меня.

Внешний вид устройства, собранного на макетной плате.

Для сборки нам понадобится:

1. Arduino Uno/Nano/Mega. Все зависит от ваших потребностей и возможностей.

2. Дисплей LCD 1602, желательно с драйвером I2C, ведь скетч сделан именно под него.

3. DHT11/22. У меня он распаян на маленько плате.

4. Датчик влажности, можно использовать датчик дождя, влажности почвы, да хоть проволоку намотать можно. У меня это копеечный красный датчик воды с Алиэкспресс.

5. Реле одно канальное

6. Серво-привод на 1,6 килограмм. (лучше берите такой)

7. RGB Светодиод, у меня светодиод распаян на маленькой плате, называется HW-479.

8. Пищалка, покупается на любом рынке у дедов.

7. Провода.

8. (Необязательно) Паяльник, припой, флюс или канифоль.

Сборка компонентов выполняется по схеме:

На схеме нету Драйвера дисплея, наколхозил как мог.

Переходим к прошивке микроконтроллера.

Последнюю версию прошивки вы можете найти на здесь. Еще одна ссылка на скетч прикреплена внизу поста.

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

В скетче все описано, за что отвечает тот или иной пункт настройки.

В настройке значений, первые два пункта (TIMEOUT, TIME_FOR_ASKING) отвечают за вторую линию питания для датчиков. Это сделано для того, чтобы продлить жизнь датчикам, подверженных воздействию воды(датчик влажности), так как железные контакты, хоть и не проводят большой ток, но всё равно окисляются из-за воды. НО! Датчик температуры и влажности подключен к "общей" линии питания, так как для того чтобы собрать с него значения требуется от одно до двух секунд. К "щадящей" линии подключаются аналоговые и цифровые датчики с быстрым откликом.

Важно! В скетче используется нестандартная библиотека для работы DHT11, а именно TroykaDHT, oт Амперки. Скачать ее можно с GitHub репозитория.  Также, рекомендую установить корректно работающую библиотеку дисплея по I2C. Скачать корректную библиотеку LiquidCrystal_I2C можно с GitHub.

Первый запуск.

Важно! Устанавливайте датчик влажности почвы возле корней растения и подалее от поливной системы, чтобы микроконтроллер точнее знал уровень влажности почвы.

При запуске появляется текст, сообщающий вам версию прошивки. В это время, вы можете увидеть как серво-привод повернулся на 180 градусов(открыл окно), и через пол секунды закрыл его(стал в нулевое положение). Таким образом осуществляется проверка на корректность работы всех модулей. Если датчик влажности грунта заметит что уровень влаги ниже указанного значения в скетче, то микроконтроллер замкнет цепь питания насоса, с помощью реле, и включит синий светодиод, сигнализирующий о поливе . Когда уровень влажности почвы достигнет заданного значения, полив остановится.

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

Параллельно с этими действиями, на дисплей выводятся все показания со всех датчиков.

T - Temperature: Значение температуры внутри теплицы.

H - Humidity:  Значение Влажности внутри теплицы.

SW - SoilWater: Значение влажности почвы.

Обещанная дублирующая ссылка на скачивание прошивки GreenHouse.

P.S. Скетч очень сырой, да и схема требует доработок. Если у Вас есть идеи по доработке данного скетча или схемы, также если у Вас есть идеи для добавления полезного функционала, страница с GitHub репозиторием всегда открыт для Вашей редактуры! Любая критика воспринимается!

Спасибо за внимание!