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

Немного про «IT Академию Samsung»

Перед тем, как рассказать про мою разработку, хочу поделиться впечатлениями от первых занятий в «IT Академии Samsung» по треку «Интернет вещей», который я прошел в НГТУ (Новосибирского государственного технического университета) в прошлом учебном году. Началось всё с прошивки контроллера STM32 RIOT OS. И всё это через Linux и командную строку. Честно скажу, что опыт незабываемый настолько, что я уже начал переживать, что в 2020 году люди все еще программируют в командной строке и после компиляции заливают образ вручную на контроллер. Но уже на следующем занятии нас познакомили с инструментами, которыми пользуются разработчики, а всё предыдущее было для демонстрации того, что происходит, когда мы нажимаем волшебную кнопку Build в среде разработки. Хочу также отметить, что за весь курс мы ни разу не программировали с помощью фреймворка Arduino, что, как по мне, является огромным плюсом, поскольку в реальных задачах и на производствах данный фреймворк (я надеюсь) не используется. Нас познакомили с Mbed, RTOS, а также ESP-IDF (которая, к слову, базируется на FreeRTOS). Мне нравилось, что каждый кейс начинался с объяснения, для чего будет использоваться данное устройство, и какие технологии уместно применять в нем.

По окончании обучения каждый студент представлял свой проект по Интернету вещей для получения сертификата «IT Академии Samsung». Это мог быть простой светильник с функцией включения по Bluetooth, или что-то посложнее… Мне хотелось сделать устройство, которое будет сложным с точки зрения программирования, при этом решать действительно важную проблему. Поэтому я остановился на умном дозаторе таблеток.

В основе умного дозатора лежит простая идея – выдача заранее распределённых лекарственных препаратов по индивидуальному расписанию. При этом хотелось, чтобы расписание можно было настраивать с помощью любого устройства, которое имеет доступ к домашней сети. Но обо всём по порядку.

Про разработку

Как же я пришёл к тому устройству, что есть сейчас, получившему название AutoPill?

Шаг 1. Определение функционала и выбор микроконтроллера

Поскольку с идеей я разобрался, необходимо было переходить непосредственно к реализации. Я опросил знакомых, что им бы хотелось видеть в этом устройстве. Отсёк те идеи, которые посчитал «не моим путём», и составил описание функционала будущего устройства — получилось около 15 пунктов. А затем снова опросил тех же знакомых со словами «выбери из данного списка самые важные, по твоему мнению, пункты». Это позволило уже на начальном этапе определить тот основной функционал, который нужен именно потребителю, а не тот, который проще всего реализовать или интересен мне.

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

• Устройство должно быть таким, чтобы пользователь (пациент) не мог по ошибке открыть сектора с хранящимися препаратами. Сектора должны открываться по расписанию автоматически и блокироваться при открытии следующего отсека.
• Устройство должно сигнализировать пользователю о необходимости принять новую порцию препаратов.
• Отсеков должно хватать более чем на один день.
• Конструкция устройства должна быть компактной (в качестве примера большинство приводили шкатулки или небольшую коробку).
• Гибкая настройка расписания: возможность задать периодичность с шагом в 30 минут.
• Возможность посмотреть, принял пользователь препараты или нет.

И необходимо проработать следующие особенности:

• Как открывать/закрывать отсеки?
• Как понять, когда пользователь принял препараты, чтобы отключить индикацию?
• Как сообщать пользователю состояние?
• Как настраивать устройство?

Начнём с самого очевидного: для настройки и передачи состояния таблетницы было предварительно решено использовать Bluetooth или Wi-Fi, поскольку у большинства людей в доме есть устройство, поддерживающее тот или иной протокол.

Чтобы понять всё остальное, необходимо было разработать конструкцию таблетницы. На этом этапе я также выбрал микроконтроллер — ESP32, поскольку у него есть множество встроенных возможностей, которые позволят в дальнейшем значительно расширить платформу (например, ESP-NOW, ESP-Touch и ESP-Mesh), а бонусом была поддержка двух необходимых протоколов связи — WiFi и Bluetooth.

Шаг 2. Конструкция устройства

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

Потом я попытался найти какой-нибудь готовый механизм, оказывается, на YouTube даже было 1-2 устройства, похожих на дозаторы, — правда, их надёжность оставляла желать лучшего...

Я принял решение разработать свой корпус устройства, не забывая и о функциональности, обозначенной в шаге 1.

Для того, чтобы разработать конструкцию, было бы неплохо выучить какой-нибудь САПР. К счастью, в лицее я научился работать в Компас-3D, что сильно упростило задачу. Вторая проблема — изучить, из каких материалов можно сделать из 3D модели настоящий прототип. Мой выбор пал на 3D-принтеры, поскольку это, по моему мнению, самая простая возможность создать прототип и напечатать деталь практически любой сложности.

Итак, представляю самую первую версию сборки из, на тот момент, трёх деталей

Если вы все-таки взглянули на это и уже стремитесь закидать меня тапками, спешу оправдаться — это лишь основные внешние конструктивные элементы, которые в дальнейшем были сильно доработаны. Сразу скажу об ошибках, которые были допущены при проектировании корпуса – эта информация может пригодиться тем, кто сам хочет или уже начал разработку собственного корпуса для устройства, и это его самый первый опыт:

1. Не поленитесь посмотреть размеры столов самых популярных принтеров, чтобы у вас был широкий выбор, где заказать печать или попросить по дружбе
2. При проектировании, если вы раньше ни разу не видели принтеры вживую (как я, например), посмотрите, как эта технология реализована, и какие детали ей сложнее всего печатать, постарайтесь оптимизировать модель под более простую печать для уменьшения времени печати и количества брака. Наглядный пример, как делать не надо, можете посмотреть на первую версию крышки устройства. У неё очень пологий угол наклона, что делает печать без поддержек невозможной, и даже с поддержками шанс брака очень велик, так как пластик при такой толщине может просто не сцепиться.
3. Не печатайте на плохо откалиброванных принтерах или принтерах с низкой точностью печати, особенно это касается конструктивно важных деталей (шестерни). Тоже немного негативного опыта я получил при печати основы на дешёвом принтере: вышло нарушение соосности деталей, что создало множество проблем, начиная с неравномерного трения при разных положениях отсеков, и заканчивая длительной подгонкой деталей.

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

На данной иллюстративной сборке не видно таких элементов, как:

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

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

Шаг 3. Электроника

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

1. Микроконтроллер. В моём случае я взял ESP32 Dev Kit с уже распаянным на плате понижающим регулятором напряжения, а также отладчиком.
   
   ESP32 Dev Kit

   
2. DC мотор — мотор коллекторного типа, наверное, один из самых популярных, используется в радиоигрушках.
   
   DC двигатель

   
   Рабочее напряжение: 3 Вольт ~ 8 Вольт
   Ток потребления при напряжении 3,6В: 240 мА
   Тип двигателя: коллекторный
   Вес: 26 гр
3. Щелевой датчик — датчик, необходимый для отслеживания количество оборотов редуктора. В устройстве стоит датчик с уже распаянным компаратором LM393 (на изображении приведён датчик непосредственно с платой развязки).
   
   Щелевой датчик ITR9608

   
   Рабочее напряжение: 3.3 Вольт ~5.0 Вольт
   Ток потребления энкодера: 1.4 мА
   Ширина паза в щелевом датчике: 5 мм
   Вес: 8 гр
   Рабочая температура: от 0 до +70?
4. Датчик наклона — датчик необходим, чтобы определять, взял ли пациент лекарство из устройства. Поскольку отсеки глубокие и достать пальцем сложно, предполагается что пользователь будет вынимать необходимые препараты, наклоняя таблетницу.
   
   Датчик наклона SW-200D

   
   Рабочее напряжение: до 12 В
   Потребляемый ток: до 20 мА
   Время отклика: 2 мс
   Время жизни: 100000 циклов
   Размер: 12 x 3,6 мм
   Вес: менее 1 гр
   Рабочая температура: от -40 до +80?

Помимо датчиков, также использовался MOSFET-транзистор, который служил ключом для запуска и остановки мотора. Собственно, это была вся электроника.

Сейчас для повышения точности позиционирования также планируется использовать еще и датчик чёрной линии, но об этом позже.

Шаг 4. ПО

Хочется отметить, что, конечно, к шагам 2-4 после первой итерации я возвращался не раз, т.к. шла и доработка конструкции, и создание ПО. И хочется уточнить, что шаги ни в коем случае не выполнялись одновременно, а именно доводились до логического завершения, потому что ПО сильно зависело от текущей конструкции.

Самый первый вопрос разработчика ПО для IoT будет следующим (по крайней мере для меня): существует ли IDE для разработки устройств IoT? Почти для каждого микроконтроллера существует своя IDE, но лично я пользовался универсальной средой – PlatofrmIO. В течение всего цикла разработки я ни разу не пожалел об этом решении.

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

Язык, на котором написан код проекта: C. Честно сказать, после нескольких лет написания кода на языках Java, Kotlin и иногда C#, я, хоть и был морально готов к этому испытанию, но не ожидал, что встречу столько неудобств. Но в итоге это оказался очень классный опыт.

Прежде чем приступить к разработке ПО, я изучил на просторах GitHub, как вообще пишут программы под ESP-IDF, и, к моему большому удивлению, результатов (если не считать библиотеки с примерами) оказалось крайне мало. Ладно, подумал я, и решил разработать свою архитектуру для ПО.

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

Если говорить о том, что получилось, то в целом проект остаётся читаемым и легко масштабируется. Единственный недостаток данного подхода в том, что класс main содержит уж слишком много обработок пользовательских действий, и в дальнейшем было бы хорошо добавить также слой, который частично берёт на себя обработку пользовательских действий в пределах определённого набора функционала.

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

1. Работа с периферией. Самый очевидный модуль, причём я принял решение разработать отдельные модули для отображения и для входных данных. Как впоследствии оказалось, достаточно было сделать только тот, что для входа.
2. Подключение устройства к Wi-Fi. Я решил именно подключаться к Wi-Fi и разворачивать свой мини-сервер, поскольку станций Интернета вещей не было ни у кого из опрошенных, а Wi-Fi есть дома всегда. Подключение производилось через WPS, с возможностью изменения в настройках.
3. Создание HTTP-сервера на устройстве. Очевидно, что для такого сегмента использование протокола HTTP – неудачное решение, но на данный момент я его не заменил, поскольку мне важна возможность использования устройства в изолированной сети, что не даёт возможности автоматически продлевать сертификат, а с самоподписанными сертификатами на сервер пропускает разве что Internet Explorer, и то с предупреждениями о том, что это всё мошенничество.
4. Реализация модуля безопасной авторизации. В данном случае мы говорим о Digest-аутентификации. Данная аутентификация позволяет в пределах локальной сети сделать устройство максимально устойчивым к взлому.
5. Модуль планировщика. Наверное, самый важный модуль, который должен поворачивать сектор точно при наступлении необходимого времени. При этом, данный модуль должен также поддерживать синхронизацию времени (т.е. перераспределение задач и автоматическое устранение ошибок)

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

Но, приступая к реализации самого, казалось бы, банального, первого модуля для работы с периферией, я столкнулся с объемной и непонятной документацией. Я думаю, это один из основных факторов, почему каких-либо готовых проектов на ESP-IDF мало. К счастью, у разработчиков есть GitHub, который, благодаря примерам, сильно упрощает понимание. Единственное, не забудьте выбрать нужную ветку с вашей версией ESP-IDF! Пожалуй, это единственная проблема данного фреймворка. А в остальном он очень неплох. Внутри него есть практически всё, что раньше вы добавляли с помощью библиотек: WiFi, WPS, HTTP-сервер, NTP, различные функции хэширования и многое другое.

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

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

Также был разработан планировщик, который запускает поворот таблетницы, согласно тонкой настройке расписания. При этом планировщик разработан таким образом, что он корректно обрабатывает синхронизацию времени, что немаловажно для такого устройства. Синхронизация времени происходит при помощи NTP-сервера, который может находится как локально, так и в глобальной сети.

Что получилось?

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

Давайте подытожим.

Для кого разработан AutoPill? Целевая аудитория — люди с деменцией и плохой памятью, которые принимают медицинские препараты на постоянной основе. Стоит учитывать, что данное устройство не способно полностью заменить близкого человека или медицинского работника, который выдаёт медицинские препараты, но способно значительно упростить процесс выдачи и контроля принятия лекарств пациентом. Необходимо лишь раз в неделю или реже раскладывать препараты по секторам, а далее удалённо отслеживать принятие препаратов.

Как подключить AutoPill? При первом запуске устройства или смены точки доступа это можно сделать с помощью WPS или протокола ESP-Touch (через приложение на смартфоне).

На данный момент устройство работает от сети, но в дальнейшем будет добавлена возможность работы от аккумулятора, при этом внимание будет уделено режиму энергосбережения (в т.ч. автономной работе, либо работе в режиме клиента, когда в качестве сервера будет выступать станция IoT).

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

Видео о проекте:

Что дальше?

Я не ожидал, что устройство окажется таким востребованным. Но буквально каждый второй, которому я рассказывал о своей разработке, спрашивал о том, когда и где можно будет купить AutoPill. Я получил множество советов по возможной дальнейшей доработке устройства.

Сейчас, помимо полировки уже существующих функций устройства, передо мной стоит очень важная задача — уменьшение энергопотребления. Кроме того, я работаю над интеграцией устройства в систему SmartThings. Это позволит продублировать все автономные функции на хабе или в облаке, при этом само устройство сможет более эффективно расходовать энергию. Помимо этого, после интеграции AutoPill сможет не просто подавать сигнал с помощью собственных встроенных возможностей, но использовать и носимые устройства и умные колонки для оповещения пользователя о тех или иных событиях.

Владимир Шперлинг
vladimir-shperling@yandex.ru
Студент 4 курса Новосибирского государственного технического университета
Kotlin, Java, C#-разработчик
Победитель финала конкурса проектов IT Школы Samsung, 2016
Победитель конкурса «Школа VR 360», 2018
Победитель конкурса IT Академии в треке «Интернет вещей», 2020