Шторки радиатора 4: софтовая часть

Техническую часть написал тут. Теперь пора написать про софтовую реализацию, требования, хотелки и что вышло. Проект оказался долгоиграющим, поэтому в процессе работы над ним были и большие перерывы, и переосмысливания, и каша в коде. Благо есть gitlab и github. Правда, там создал проекты уже после пары провтыков с кодом. :)

Тут будет много букв, в процессе работы фотки не делал.

Когда думал над проектом, то вырисовался определенный план и требования. Для рабочей версии будут нужны скорость движения, температура двигателя и температура наружного воздуха. Проект должен состоять из двух частей: управляющая и клиентская (будь это другая arduino/esp, будь это мобильный телефон). Я не могу выводить на приборку кастомные ошибки, но сигнализировать о проблемах как-то нужно. Уносить "мозги" в салон тоже не хотелось. Так же, проект должен писать достаточно много логов, чтобы было легче наблюдать за его работой с ноута.

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

Версия №1 на базе NodeMCU (ESP8266)

После сборки конструкции и покупки сервоприводов, решил собрать прототип для настройки работы сервопривода. Первым пациентом была выбрана NodeMCU (esp8266) из-за наличия Wi-Fi и простой работы с ним. Так появился первый проект. В репозиторие лежит скетч, схема и файл для Fritzing.

Сначала были сделана точка доступа, потом веб-страница с "ползунком" для сервы. Далее была добавлена серва и методом "тыка" были подобраны оптимальные углы поворота. Для шторки открывались и закрывались в диапазоне от 45 до 105 градусов в контексте сервопривода. Потом было добавление функционала по управлению скоростью поворота сервы, т.к. сама по себе она достаточно резкая.

Пока не были получены нужные данные из CAN шины, решил пилить клиентскую часть для салона. Изначально планировалась тоже NodeMCU (esp8266), т.к. прикручивать к arduino Wi-Fi немного геморно и еще пара NodeMCU у меня есть свободных. Кстати, сейчас появились модули Wi-Fi, которые очень похожие на BT-модули. С ними обучать arduino работе с Wi-Fi намного проще. Но, как уже написал, nodemcu у меня уже были.

Клиентская часть должна уметь подключатся к основной esp-шке по Wi-Fi, получать данные и выводить их на дисплей. Для этого в основной скетч был добавлен API-like ендпоинт, который должен был возвращать статус в формате JSON (вдруг доберусь до приложений на Android?). Клиентская esp-шка раз в несколько секунд опрашивает основную и, если что-то изменилось, обновляет данные на экране.
Сказано — сделано. Заодно поигрался дисплеями 0.96" и 1.8". Подключить дисплей 1.8" оказалось сложнее, почему-то и в библиотеке нашелся какой-то баг со сдвигом картинки на несколько пикселей. Править либы под скетч, как по мне, очень плохая практика. Поэтому, оставил 0.96" и заказал с Али еще пару таких. Проще вывести на несколько дисплеев.

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

Потом я осознал на сколько важна обратная связь от привода… Пересмотрел разные сервоприводы и решил, что для моей цели будет достаточно получать аналоговые значения потенциометра. Об этом писал в прошлой записи о технической части. Это важно на случай какого-то ЧП, чтобы не убить сервоприводы или еще что-то.

Поскольку мне нужно два привода, а у NodeMCU аналоговых пинов аж один, то стало очевидно, что от этой платки откажусь. Проект и код делал под один привод, чтобы доделать уже сам скетч. Далее проект был разобран, а схема и код выложены на github. Вдруг, кому-то будет полезной.

После этого начал переносить код на Arduino Due.

Версия №2 на базе Arduino Due

При переезде на Due уже были планы по дополнительным системам для авто. Установка ардуины планировалась в салоне, а управление шторками хотел сделать с помощью Arduino Nano. Обмен данными с Due сделать не по Wi-Fi, а с помощью того же CAN (отдельная сеть от машины) на скорости до 250 кбит/сек, чтобы nano тянула без особых сложностей.
Прошу прощения, проект не был сохранен. Но повторить его не сложно. Нужна Arduino Nano и модуль mcp2515.

На этому моменту я уже получил данные из CAN шины и принял решение, что на машине шторки стоять уже не будут. Нет, со шторками все ОК и проект можно доделать. Просто к этому времени пообщался с парой человек с такими же машинами и вышло так, что у них проблем с прогревом двигателя, как были у меня, попросту нет. Эта зима была теплой, поэтому сказать, что проблема осталась, тоже не могу. Нашел в доках, что на первом ТО доливали 0.5 л антифриза. Возможно, как-то было связано, хз.
Исходя из этого, выходит, что шторки будут скрывать симптомы проблемы (если она еще есть) и в один момент станут просто бесполезными. Дорогое удовольствие как для бесполезной приблуды… Плюс ушатывание креплений переднего бампера и риски, что что-то заглючит/сдохнет и будет требовать ремонта или замены.

Было решено закончить проект, хоть у него и нет будущего.
Был написан скетч для Due, который получает из CAN данные, решает на какой угол повернуть шторки и выводит данные на экран. В целом, проект не сложный. Тоже выложил на github, возможно, кому-то будет полезным.

Что стоило бы доделать, но не сделано

1. Проект запитывал от блока питания на 9В. Питание от сети автомобиля не делалось, т.к. уже знал о том, что проект не будет в продакшене. Думаю, для питания будет достаточно популярного LM2596 с припаянным штекером 5.5х2.1 мм, чтобы подключить его напрямую в Arduino Due. Питать от постоянного "плюса" через предохранитель 1А.

2. Обязательное открытие шторок после глушения двигателя. Без подключения к постоянному "плюсу" такое сделать не выйдет. Я этот функционал не делал, но считаю, что он нужен.

3. Подбор значений температуры двигателя и скорости автомобиля для открытия и закрытия шторок. Самый верный способ — подбор во время реальной езды.

4. Определенная задержка между открытием и закрытием шторок с приоритетом в сторону открытия шторок. Это нужно, чтобы шторки не начали постоянно открыватся и закрыватся из-за смены температуры двигателя на один градус. Пусть лучше дольше будут открытыми, чем сервопривод будет постоянно их крутить.

Все части:
— Фэйл со шторками радиатора
— Шторки радиатора 2: Попытки собрать с оригинальных запчастей
— Шторки радиатора 3: техническая часть
— Шторки радиатора 4: софтовая часть
— Шторки радиатора 5: финал с видео