Vitaly
lvgl (GUI-библиотеку) подкрутили под platformio

github.com/littlevgl/lvgl/issues/667

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

Иногда нужно лепить девайсы с мелкими дисплеями и симпатичными интерфейсами. Для примера - те же reflow-паялки. Так вот, трудоемкость правильного интерфейса может значительно превышать все остальное. И чтобы это не погибло под грузом сложностей, нужно несколько вещей:

  • Нельзя “лочить” проект на одном человеке. Всегда должна быть возможность “подкрутить” интерфейс со стороны, не вникая в проект целиком.
  • Нельзя привязывать прототипирование интерфейса к реальному железу. В эмуляторе это делать на порядок быстрее. И этим могут заниматься вовсе не “железячники”.
  • Не надо пытаться рисовать что-то свое. Серьезные дяди и тети составляют документы под названием “interface design guide”. Просто выбираем design guide по вкусу, и быстро делаем по требованиям, которые в нем описаны.
  • Софт должен ставиться легко и быстро.

После изучения легковесных GUI-библиотек я остановился на lvgl. Технически там все довольно неплохо, но надо было решить вопрос с простотой установки-сборки. Поэтому создал тикет о скрещивании с platformio, и этот тикет сегодня благополучно решили. Ура!

Осталось понять как красиво напилить код, чтобы собирался под разные платформы, и оформить это дело в качестве примера для новичков.

Черновик микро-паялки, плата и конструктив

easyeda.com/reflow/reflow-micro-table

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

  • С питанием от сети.
  • Так чтобы приятно было держать в руках 😃.
  • Более технологичная сборка.
  • Размер нагревателя чуть больше.
  • Общий размер ~ 102*62*25мм.

От оригинала там ничего не осталось, тем не менее все равно спасибо nppc. Во-первых за базовую идею, во-вторых за консультации.

Если посмотрите на плату, то она является частью корпуса. Надо будет допечатать на принтере нижний поддон и верхнюю крышку индикатора с кнопкой. Керамический нагреватель будет притягиваться проволочными хомутами, через бутерброд из силиконовых ковриков и возможно хлопок от 3D-принтера (надо проверять, хватит изоляции без хлопка или нет). Ну и конечно же, по размерам большой стороны я вписался в 10 сантиметров, чтобы платы были по демпинговой цене (2$ + доставка).

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

Микроконтроллер специально поставил потолще - чтобы шился напрямую по USB, памяти побольше и с аппаратной плавучкой. Воткнул сразу два разъема - микро и современный Type-С, кому что больше нравится. Возможно потом поменяем контроллер на STM32F072C8T6 и выпилим кварц. Посмотрим что с памятью будет - хочется всякой продвинутой графики намутить.

Софта пока вообще нет. С ним надо отдельно разбираться, и это не быстро. Если есть желающие поучаствовать - пишите, объясню что как.

Тепловизоры для бедных

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

  1. Есть девайсы на микроболометрах с разрешением 32*32, где героически преодолеваются километры трудностей. Используются дополнительные камеры для подкладывания реальной картинки (а потом долбимся с коррекцией соосности), магические технологии для увеличения разрешения, и т.п.
  2. Есть девайсы на микроболометрах с разрешением 220*160, которые просто работают 😃. Не предел мечтаний, но плату посмотреть точно хватит. Особенно если докупить за 10$ IR-линзу от газового лазера, для близкой съемки.

banggood.com/…/Wholesale-Thermal-Imager-c-7973.htm… - на банггуде довольно неплохо представлен весь актуальный ассортимент. Самое привлекательное - HT-18, “всего за 300$”. Жалко что нет макросъемки и хотя бы ручки фокуса.

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

Также видел много проектов “самопальных” тепловизоров. Но они уходят корнями в прошлое, т.к. используют сенсоры 32*32. Также залез посмотреть, почем сенсоры у известных производителей типа Dali. 384*288 => 300$, 640*480 => 700$. В общем, если нужен простой недорогой девайс для дела, то городить свой уже смысла нет - дешевле не будет, особо лучше тоже.

Заказал HT-18. Пока едет - развожу платы и готовлюсь собирать тестовые нагревалки, проверить различные виды конструктивов.

Обновил схему микропаялки

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

Решил объединить конструктив нагревателя и плату электроники:

  • Надо было вписаться по длине в 100мм - это максимальный размер для дешевых печатных плат.
  • Если все на одной плате, то уходят разъемы нагревателя и датчика.

К сожалению, мелких дисплеев с тачскрином найти не получилось. Поэтому откатился обратно к концепции “микродисплей + пипка”. Дисплей нашел квадратный 1.3" 240*240 IPS. Что касается управления, то квадратурный энкодер мне не понравился - очень сильно выпирает ручка. Поэтому взял микроджойстик (5-way tactile switch), который по высоте очень удачно встает на плату вместе с индикатором.

esp32 на готовой плате по размеру не очень вписывался, поэтому перепилил все на stm32. Ну и выбрал кристалл с поддержкой USB-загрузчика, чтобы люди могли обойтись без ST-tlink. В память о том, как долбались с математикой на регуляторе скорости, решил больше не играться в железки без аппаратной плавучки. Тот же stm32f302cbt6 стоит всего 2 бакса. Не те деньги, чтобы загоняться на тему кроилова.

Пока выходит так: easyeda.com/reflow/reflow-micro-table.

По размерам вместе с корпусом должно получиться ~105*60*30мм. Ну и детальки достаточно дешевые. Думаю, долларов 40, вместе с 3D-печатью и стоимостью доставок из разных мест. Если собирать несколько штук - выйдет еще дешевле.

Но радоваться пока рано 😃. Нас еще ждет долгий путь по ковырянию с софтом.

Черновики схем паялок

Решил параллельно рисовать обе reflow-паялки - проще контролировать разницу. Пока получается так:

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

Электронику еще не разводил. Пока отрисовал только подложки нагревателей, которые планируется заказать как печатные платы. Это должно исключить “неудобные” операции на сборке. Корпуса контроллеров напечатаем на 3d-принтере, так что ни каких столярно-слесарных работ.

Теперь надо собрать нагреватели без электроники, и погонять с обычным диммером. Разобраться, какую периферию оставлять, а какую выкинуть. Если повезет, то должно остаться 2 термопары (верх платы, верх нагревателя), возможно RTD (низ корпуса) и нижний вентилятор.

Ну и лирическое отступление про код. Его можно делать вообще без железки, и “прям щас”. IMHO самое трудоемкое в разработке подобных девайсов - это сделать удобный интерфейс. Но поскольку многие графические библиотеки умеют побираться на PC, интерфейсом можно заниматься совершенно независимо от железа. Если есть желающие поучаствовать - обращайтесь. Сам я не великий писатель на сях, поэтому с радостью поделюсь славой от разработки 😃.

esp32 странный однако

Я тут вдумчиво перебирал, на чем сляпать контроллер reflow. С одной стороны конечно stm32 это круто (по сравнению с ардуиной), а с другой - уж больно жидко там по памяти и беспроводным примочкам, если есть желание лепить разухабистые интерфейсы.

В общем, решил для общего развития слепить мелкую паялку на esp32. По-честному, с FreeRTOS и т.п. Начал рисовать схему, разбираться в распиновке… и ёпс…

  • ADC2 не работает, если включен WiFi. Ну ок, это можно пережить.
  • У АЦП официально (!) кривая характеристика, с капитально заваленным началом и концом. И в sdk есть “выпрямлятор”, который пытается пересчитать результат в правдоподобный.

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

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

Чтобы упростить жизнь, пришлось отказаться от совсем дешевых индикаторов. Дело в том, что там тачскрин болтается без контроллера, и его надо обрабатывать вручную, используя АЦП. И еще выводы делятся с линиями дисплея, а это лишние напряги с арбитрированием шины. В итоге нашел 3 варианта дисплеев, где все на SPI:

  • TFT 2.4" за 9$
  • TFT 3.2" за 13$ (есть еще 2.8", но у него плата почти такого же размера как у 3.2")
  • Понтовый TFT 2.8" за 26$
  • TFT 3.5" от Raspbery за 13$

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

От Raspbery дисплеи очень приличные, но там неудобный (высокий) разъем, который нельзя перепаять. И уже великоваты, честно говоря. Плюс там разрешение 480*320 - это по SPI уже трудно с большим FPS обновлять. Я еще подумаю, что с этим можно сделать, но скорее всего остановимся на чем-то из первых трех вариантов.

В мелкую паялку скорее всего пойдет дисплей 2.4". Потому что надо совсем компактно и желательно дешево. В паялку на кварцевой кассете - посмотрим по результатам.

Нашел интересные детальки для мелкой reflow-паялки

Концепция проекта в очередной раз вильнула 😃. От идеи слепить все на кварцевой кассете я не отказался. Но появилась возможность сделать с намного меньшими затратами времени миниатюрный вариант. Все началось с uReflow. Проект во всех смыслах замечательный, но меня не устроили некоторые нюансы:

  • Нужно отдельное питание.
  • Размер столика совсем микроскопический.
  • Вариант монтажа нагревателя не очень технологичный.

Но недавно я обнаружил вот такие нагреватели.

  • Они на 220 вольт, можно подключать через симистор, а цифру запитать через мелкий TSP-05.
  • Размер 50х50мм в моем случае намного более перспективный чем 40х40мм. Хотя разница может показаться совсем небольшой.

В итоге несколько дней думал, как сделать слойку нагревателя, и как собирать электронику, чтобы людям было удобнее, а мне проще. Вырезал из бумажек прямоугольники, складывал их между собой, вдумчиво махал рулеткой… Раза три полностью переделал уже “почти готовый” результат. Получилось как-то так:

  • У нагревателя заманчиво сделать днище их стеклотекстолита (заказать как печатную плату). И привернуть туда все хомутами из тонкой стальной проволоки. В качестве прокладок - хлопок от принтеров и силиконовые коврики для пайки.
  • Датчик взять RTD, от принтера, чтобы не возиться с калибровкой. Просто присобачить специальным клеем для радиаторов с обратной стороны нагревателя.
  • Индикатор с тачскрином, 2.8", от ардуины. Избавляет от джойстика и торчащих ручек. А места по факту занимает пости столько же.
  • Электронику сваять на esp32, если там не вылезет какого-нибудь ада. Думал сначала на stm32, но там надо ставить жирные кристаллы, чтобы хватало памяти на видеобуфер. По деньгам выйдет то же самое, а esp32 еще и паять не надо, и вайфай про запас.

Ну и предварительно все продумано, чтобы получилось компактно. Больше всего крови попил тумблер питания 😃. Он занимает очень большой объем, и еще не везде можно поставить с точки зрения удобства и эстетики.

С интерфейсом ситуация следующая. Все современные GUI-библиотеки умеют компиляться не только на эмбедах, но и на PC. То есть можно неспешно набивать и отлаживать основную часть кода вообще без железки, а остальное оставить на сладкое. Библиотека пока гянулась вот такая: github.com/littlevgl/lvgl.

Еще о вариантах бездатчиковых стабилизаторов скорости

Оказывается есть довольно современные разработки: (AN863) Improved sensorless control with the ST62 MCU for universal motor. Кому интересно - почитайте, там довольно красивые картинки и понятные пояснения.

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

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

Отсюда кстати понятно, почему регулятор на U2010B хорошо работать не сможет - там просто таблички компенсаций отсутствуют. Точнее, он будет работать относительно хорошо только на средних и высоких оборотах. И под конкретный движок понадобится настраивать вручную.

Если проводить параллели с регулятором, который мы сейчас сочиняем, то у нас измерения идут не на zero-cross, а непрерывно, и считается свертка. В итоге намного меньше проблем с шумами.

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

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

Будем пробовать.

Да, на всякий случай напомню, что текущие алгоритмы на бормашинке и так работают достаточно хорошо. Вся тяга к улучшениям - просто от желания понять нюансы лично для себя. Я не объявлял об “официальном релизе” регулятора просто потому что хочется получше все оформить. Но собирать и юзать можно уже сейчас.

Залили в реп автонастройку ПИД-а бормашинки

github.com/speedcontrols/ac_sc_grinder

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

  • P - сначала отпускаем коэффициенты и меряем дисперсию шума. Автоколебанием считаем если дисперсия больше шума на 10%. Потом двигаемся между минимумом и максимумом, уменьшая шаг, пока не найдем точку где автоколебаний все еще нет.
  • I - тут немного хитрее. Поскольку автоколебаний им не запустить, то дергаем скорость с 0.3 до 0.4 и смотрим чтобы выход не “заносило”. Тоже половинным делением подбираем нужное значение.
  • Уменьшаем оба коэффициента на 0.8, для запаса стабильности.

Крайние значения интервала P взяты [1…5] - типовые номиналы. Крайнее значение I сейчас забито константой (4 сек), но потом подправим, чтобы мерилось время разгона-останова (больше быть точно не может).

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

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

Похоже нашлась замена для Sphinx Search

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

Недавно в очередной раз проверял альтернативы, и обнаружил github.com/manticoresoftware/manticoresearch. Оказывается сфинкс форкнули, и решили все нюансы, от которых у меня пригорало.

В качестве бонуса - в Мантикоре реализовали перколатор (обратный поиск). Это когда люди говорят “хочу отслеживать поисковый запрос” и получают уведомление при появлении новых объявлений (может иметь смысл для барахолки). То есть, вместо поиска тысяч документов по одному запросу проверяется каким запросам из многих тысяч соответствует один документ.

Будем переезжать. По крайней мере уйдет головная боль с поддержкой сфинкса, и все будет по-настоящему опенсорсное, как я люблю.

Подготовка к автокалибровке ПИД-а на бормашинках

Сегодня без графиков, залью по окончании, когда полностью закончим. А пока новые леденящие душу подробности 😃.

Как известно, для вычисления коэффициентов ПИ-регулятора, надо подать на девайс “импульс” и померить время разгона и торможения. Удивительно, но время торможения оказалось меньше времени разгона. Если б не видел графики лично - не поверил бы. Но нам это только на пользу - торможение не будет мешать поджимать коэффициенты регулятора посильнее. А вот с самими измерениями есть нюансы.

Сигнал ОЧЕНЬ шумный. Если посмотреть спектр, то будет до фига гармоник, в том числе на частоте 1 герц (фик знает почему но факт). То есть, чтобы реально все задавить, нужно у фильтра ставить частоту среза 0.5 герц. А это вызывает сильное запаздывание, которое в данном случае может мешать. Мы пока занимались тем, что перебирали в scilab варианты фильтров, частоты срезов и смотрели что будет.

Лучше всего работают low-pass фильтры, которые не искажают АЧХ. То есть, Баттерворта и Чебешева 2 вида. Честно говоря, по картинкам огромной разницы не заметил. График разгона похож на логарифм. После фильтра получается небольшая задержка в начале (которая нас мало волнует), и не особо заметная в конце (если не повышать порядок фильтров).

Теоретически, можно взять КИХ-фильтр с фиксированной задержкой фазы и потом фазу восстановить. Но это очень гиморно, решили пока не связываться.

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

  • Берем частоту среза 4 герца (чтобы отставание фазы было не критичным)
  • Отсечку по времени разгона задаем где-то 15% вместо стандартных 5% от максимума (чтобы не прихватывать пролезающие шумы на хвосте).

Ну и не забываем нюансы с диапазоном скоростей для измерений. Он должен быть где-то [0.3-0.8]. Снизу не ноль, потому что на низких оборотах измерялка работать не умеет (не забываем, что мотор без магнитов и с хреновой характеристикой). Сверху не максимум, потому что поналезет нюансов со сдвигом фазы мотора и всякая фигня с шумами.

Так что теперь остается пересчитать методику под желаемую трубу, и будем надеяться что на этом приключения закончатся.

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

Думаю на этой неделе уже получим окончательный результат.

Опять тюнили измерялку скорости

Залил обновленные графики, поправил инструкции, то-сё. Все-таки график измерения скорости пришлось исправлять более серьезно.

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

Т.к. с нормальными идеями туго, решили временно обойтись “магическими константами” - на глаз разметили диапазоны, где измерения заслуживают доверия, а остальное “достроили”. Улучшать надо, но времени нет. Как-нибудь потом. Получилось так:

  • На низких оборотах выбрали интервал ~ 0.2-0.4 от максимума, и провели прямую, достроив ноль (стандартной полиномиальной регрессией).
  • На высоких оборотах (фаза 0.6-1.0) просто взяли 3 точки, там шаманить особо нечего.
  • Дырку достроили сплайном

github.com/speedcontrols/ac_sc_grinder/…/data - посмотрите графики в файлах “rpms_*”, станет понятно как выбирали магические константы.

Завтра убьем нафик старую историю коммитов и будем считать что есть “рабочая бета”. Ну и займемся ПИД-ом наконец-то.

Вроде добили измерялку скорости

github.com/speedcontrols/ac_sc_grinder

Напоминаю предысторию - перед тем как химичить с калибровкой ПИ-регулятора, понадобилось компенсировать нелинейность мотора (rpms/volts). Над этим и бились. Вроде победили, не считая пары нюансов, которые закроем в понедельник.

Картинки можно посмотреть в файле github.com/speedcontrols/…/rpms_interpolated.ods. Там 3 графика:

  • Красный - что померили тахометром.
  • Синий - что показывает измерялка Back EMF.
  • Желтый - после отбрасывания шумов и вычисления полинома пятой степени.

Шаг измерений нелинейный, чтобы сократить время калибровки - в начале почаще, в конце пореже.

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

Пришлось пободаться с определялкой стабильной скорости. Пока меряем каждые 0.25сек (фильтруя медианным фильтром), и проверяем что результаты 3 измерений отличаются меньше чем на 0.1%. На случай, если из-за помех не впишемся в этот критерий, ограничиваем общее время измерений 3 секундами - за это время скорость точно стабилизируется.

Дальше пришлось придумать как отбросить шумы (по графикам видно, что в начале показывается явный бред). Чтобы сильно не залипать в математике - использовали “магические константы” (поглядели на график и прикинули как резать). Пробегаемся сверху вниз, пока значение не станет < 0.2, прихватываем еще одну точку, а остальное считаем мусором. Это конечно не очень красиво, но уже сил нет буксовать, надо двигаться вперед.

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

В результате получаем то что на желтом графике.

Ну и на всякий случай в конфиге прописываем, что минимальные обороты 5000-7000 RPMs, чтобы “проскочить” явно стремный участок. В реальной жизни меньше все равно не надо. Обновил доку, чтобы “сохранить мудрость для потомков”. Мало ли кому понадобится делать что-то подобное.

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

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

  • У него очень нелинейная передаточная характеристика.
  • Из-за отсутствия магнитов довольно сильные помехи на низких оборотах.

Но вроде почти справились, а с другими типами моторов должно быть попроще.

Продолжаем биться с калибратором

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

  • Те шумы скорости, которые пофик при реальной работе, в калибраторе довольно сильно мешают.
  • Определить что скорость стабилизировалась (перед началом измерений), тоже тот еще квест.

В общем, вместо того чтобы семимильными шагами писать калибровку ПИД-а, буксуем на предыдущем этапе.

  • Пока на тестовых данных сделали апроксимацию графика полиномом. С виду симпатично.
  • Думаем, как детектить что скорость выросла и перестала меняться.

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

Продолжаем изобретать калибровку ПИД-а

Как обычно, повылазили новые нюансы 😃. Рассказываю.

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

К счастью, снять характеристику мотора не сложно - просто плавнo наращиваем фазу триака и меряем скорость в 20 точках. Ну а потом интерполятором накладываем коррекцию.

Теперь по ПИД-у. Стандартные методы (через отклик на прямоугольный импульс) выдавали фигню, видимо из-за отсутствия коррекции. Надо будет проверить после доработки калибратора. Но есть план Б - имитировать ручную настройку, когда коэффициенты ПИД-а крутятся до возникновения автоколебаний.

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

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

На неделе продолжим.

Еще немного математики по калибровке

github.com/speedcontrols/ac_sc_grinder/…/doc

Обновил подробности про калибровке параметров моторов. Сейчас калибруется все, кроме ПИД-а. С ним надеюсь что на неделе тоже закончим. А пока резюме по той практике, которая фигово вписывается в теорию.

Сопротивление и индуктивность мотора

Во-первых, когда мотор остановлен, можно легко насытить железки тестовым импульсом. В итоге мы подаем только 10% от полупериода синусоиды.

Во-вторых, вычисляемые R и L зависят от длины поданного импульса (смотрите по выложенным файлам с выборками). Сопротивление на минимальном импульсе в полтора раза больше чем на максимальном. Придумать правдоподобную модель сходу не получилось (одному аллаху известно, что там со щетками). В итоге просто используем результаты с 10% импульса.

Нормализация скорости

Значение скорости ОЧЕНЬ шумное.

  • Есть шумы в пределах одного периода. Давятся медианным фильтром длины 32. Увеличение до 64 картину особо не меняет.
  • Результат между разными периодами синусоиды тоже сильно скачет. Обычно это давит медленный ПИД и инерция мотора. Но при калибровке надо об этом позаботиться отдельно - собрать данные с разных периодов сети, и тоже взять медиану.

И еще, в прошлый раз я писал про управление триаком, когда ток запаздывает относительно напряжения. К измерялкам это относится в полном объеме - если на полной скорости прихватить данные с хвоста предыдущей полуволны, будет “пичалька”. Мы поступили очень просто - добавили проверку, чтобы измерялка игнорировала первые 25% синусоиды (1/2 полупериода). Обычно сдвиг фазы не больше 10%, так что решение вполне надежное.

Пока всё. Как пойдут дела с ПИД-ом даже загадывать не возьмусь. У верен что сделаем, но не знаю как именно. На практике обычно лезут такие нюансы, что любая фантази пассует 😃. Сначала выставим коэффициенты вручную, а потом будем смотреть, какие формулы дадут что-то похожее.

Еще раз про управление мотором через симистор

Как обычно, новые кровавые подробности 😃 . Сегодня отладили новый медианный фильтр, эмулятор EEPROM и стали ковырять калибраторы.

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

В итоге триак закрывается не когда напряжение падает до нуля, а позже. Поэтому на макимуме следующий импульс идет когда триак все еще не до конца закрылся, и на следующем полупериоде он тупо не открывается. Короче, внешне фигня выглядит так: на максимуме начинается фигня, и на минимуме мотор тоже не полностью стоит. Жопа.

Видимо надо убрать химию с испульсами на оптроне, и держать его открытым полностью до конца периода. В надежде что триак сам откоммутируется как ему потребно. Из потенциальных косяков - в диапазоне 95%-100% ручка будет выдавать максимум. Ну и минимум тоже сместится с 10% на 20%. Считать реальное отставание тока можно (чтобы убрать смещение), но IMHO ненужный гимор. Будем чинить по-быстрому. Уж очень хочется поскорее зарелизиться.

Сейчас в репе уже залит код калибраторов R/C и скорости. Так что еще небольшой рывок, и они оживут. Останется только написать калибратор ПИД-а, но напарник клялся что там все относительно прозрачно.

Регулятор, промежуточные итоги.

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

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

На завтрашнюю отладку уже заготовлены новые куски кода:

  • Скользящий медианный фильтр (для считалки скорости). Помимо того что “это красиво”, позволит гарантировать отсутствие переполнений на не калиброванном девайсе.
  • Считалка сопротивления и индуктивности двигателя.

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

Немного математики по AC-коллекторникам

github.com/speedcontrols/ac_sc_grinder

В папку с документацией добавились аналитические формулы и модели для scilab. К понедельнику дочистим код и можно будет переходить к автокалибровке. Обратите внимание, подобной инфы в понятном виде в интернетах нет. Люди лепят алгоритмы “по наитию” и с “магическими коэффициентами”, а такое прокатывает только до первой производной. Хотелось бы внести окончательную ясность по данному вопросу. И для себя лично, и чтобы следующие падаваны не собирали слухи из мутных источников, а юзали готовую и годную математику. С гарантированным результатом. В серьезном подходе ведь главное - не просто код слепить, а гарантии, что он будет работать должным образом.

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

Второй важный момент - мы предполагаем, что на подобных “мелких” моторах статор не входит в насыщение (для мощных коллекторников переменного тока все ровно наоборот, но там уже есть датчики оборотов и подобные регуляторы и не актуальны).

Итак, в папке с документацией у нас есть:

  • Формулы вычисления скорости.
  • Модели для scilab, где можно эти формулы покрутить и посмотреть ошибки.
  • Данные с реального девайса, и скорость, посчитанная по этим данным.

Нас конечно интересуют реальные данные. Тот кусок, когда ток начинает расти (симистор открылся) и пока напряжение не станет равно нулю (потому что отрицательное мы мерить не умеем).

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

Регуль, прогресс...

Прогресс пока в основном на макетке, но хорош. Комрад переписал формулу вычисления скорости, заменив стрёмную свертку на более полноценное выражение с производной. Сообщил, что теперь обороты держатся намного стабильнее во всем диапазоне (для одних и тех же коэффициентов ПИД-а). Был скользкий момент с насыщением магнитного потока (если поток не линейный, то формулы просто так не сократить), но, хвала всем богам, его либо нет, либо им можно пренебречь без последствий.

То есть теперь, чтобы определить скорость, достаточно двух соседних отсчетов (два - чтобы производную тока определить). Единственный нюанс - во время включения симистора производная слишком большая, и стоит игнорировать данные. Теперь осталось внимательно перепроверить на реальном моторе, вписываемся ли в нужную точность, и будем “отливать в граните”. Проверять надо на минимальной скорости, 3000rpm (~10% от макимума):

  • Сколько нужно выпилить отсчетов в начале (примерный критерий - пока производная тока не станет <= 0).
  • Сколько нужно выпилить отсчетов в конце (чтобы не делить на слишком маленький ток, который может вызвать погрешность).

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

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

На потом (после релиза) останется тема с ограничением мощности/тока, и попытка привернуть более дохлый процессор (Cortex-M0 без аппаратного деления). С практической точки зрения это нафик надо, просто хочется чисто для себя разобраться, если будет время.

"Клавиатура" для регулятора бормашинки

Ну что ж, регулятор с новой платой и прошивкой ожил, но надо уточнять математику. Если выставить ПИД на большой скорости, то там стоит как влитой, но на малых не хватает (просадка, потом восстановление за 2 сек). Если выставлять ПИД на малой скорости - то на малой держит железно, а на большой уже начинает дергаться.

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

  • Грубовато сократили формулу вычисления скорости.
  • Есть накладки с точностью на математике с фиксированной точкой, и погрешность не поддается нормальной оценке.
  • Остались “магические константы” (зависят от параметров двигателя).

Что можно на эту тему предпринять?

  • Напарник пообещал за выходные еще раз расписать формулы в Scilab, чтобы быстро подставлять реальные значения тока/напряжения и оценивать погрешность.
  • Все-таки неплохо бы иметь автокалибровку - мерить сопротивление, индуктивность, коэффициент нормализации скорости, и подбирать коэффициенты ПИД-а.

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

Исправления в регуляторе

easyeda.com/speed/AC-speed-control-for-grinder

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

АЦП

Не учел импеданс цепочки, через которую меряется входная синусоида. В итоге измерялку слегка перекосило. Выпилил резистор между делителем и входом АЦП, не нужен он. Заодно, на всякий случай, поставил защитную сборку из диодов шодки. В основном от отрицательного напряжения, чтобы не юзать внутренние защитные диоды микросхемы (меньше шансов, что отрицательной напругой перекосит мультиплексор АЦП). Не уверен, что в такой защите есть смысл, но сборка копеечная, места почти не занимает.

Если делаете высокоомные делители и АЦП работает на максимальной частоте - загляните в datasheet, чтобы избежать сюрпризов. АЦП в микроконтроллерах очень хорошие, но все-таки не “идеальные шарообразные” с бесконечным импедансом.

Triac

Не знаю, что там временами прошибает, сам ключ или симистор оптрона, но мелкий снаббер решает проблему с периодическим открыванием на полный период. Обычно для расчета используют app note от Fairchild, но мне больше понравился Panasonic Application Note 030, Driving Triacs with Phototriacs. Очень просто и доходчиво. Хватило всего 1нФ, чтобы убрать косяки. Так что можно спокойно делать снаббер из smd компонентов.

Сам оптрон заменил с MOC3023 на MOC3052 - у него рабочее напряжение до 600 вольт. Ну и не забываем, что резисторы 0805 имеют рабочее напряжение 150 вольт (кратковременно до 300), поэтому их надо ставить по 2 штуки последовательно.

В принципе все эти правки можно сделать и на старой плате.

Zero cross detector

В софте считалась длина положительного и отрицательного полупериода независимо, поэтому поэтому из-за перекоса АЦП получался не симметричный результат, и симистор рулился криво. Надо считать положительную волну + полный период, а дальше вычислять коррекцию (полуразность положительной и отрицательной части). Хотя после исправления цепочки АЦП это не особо актуально. Сейчас разбег в пределах 1 тика (при частоте 17 килогерц).

Софт

Стыдно признаться, но софт по структуре стал больше похож на ардуину. То есть, когда в main делается бесконечный цикл с кучей логики. Вообще, так обычно пишут либо полные бакланы, либо профессионалы, которые очень хорошо понимают зачем они так поступают 😃. Надеюсь что тут второй случай 😃.

Я никогда не скрывал, что не люблю С и что текущий код делается “на скорую руку”, пока Rust не станет готов для эмбедов. Поэтому не стали втаскивать сюда RTOS ради одного единственного места с отправкой сообщений. Сделали по рабоче-крестьянски.

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

По ресурсам нагрузка получилась около 50%, так что кроить с экономией питания особого смысла нет.

Что еще

Судя по чудесам с симистором, всё-таки стоит поставить фильтрующий конденсатор на сетевое питание. Только на плате для него с местом не очень. В оригинале конденсатор висит на мягких выводах над потенциометром. Наверное пока сделаю так же. Не буду рисовать на схеме, просто напишу в инструкции чтобы выпаяли со старой платы и припаяли к точкам, куда приходят провода питания.

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

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

Еще на отладочный разъем добавил пины nRST и SWO. Это очень специфичная вещь, только для отладки. Но контакты ничего не стоят, и пусть лучше болтаются без дела, чем если для какого-то особо хитрого случая понадобится еще раз переделывать плату.

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

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

Новости отладки регулятора скорости

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

  • Симистор иногда сам открывается на весь полупериод. Хотя он понтовый 3Q snubberless (bta16-cwrg).
  • Прерывания ADC (после каждой выборки из 4 каналов), несмотря на передачу данных через DMA, съедают подозрительно много ресурсов. На остальное уже не хватает.

Это немного неожиданно, но не фатально. Будем лечить.

  • К симистору временно привернули снаббер (и он сразу заработал как надо). Дальше будем заменять управляющую опторазвязку MOC3023 на MOC3052. Натыкался в интернетах на такой странный рецепт.
  • Логику выборки из АЦП переделаем. Будем выгребать по DMA в цикле сразу 16х4 отсчетов, с прерыванием на середине и конце. А вместо таймера - поллинг внутри main (кривовато конечно, но в данных обстоятельствах приемлимо).

Победа всё ближе 😃

Регуль для бор-машинки: о фильтрации сигналов и т.п.

github.com/speedcontrols/ac_sc_grinder (точную ссылку на файл и строчки не даю, т.к. по окончании отладки будем чистить историю).

Практика показала, что сигнал на выходе АЦП имеет свойство прыгать, и поэтому есть смысл чистить резкие скачки. Делается это обычно медианным фильтром. К сожалению, мне не удалось найти готовых быстрых библиотек с учетом особенностей эмбедов, поэтому желающим советую смотреть тут (вариант от Ekstrom). Мне не очень понравилось, что над быстрой имплементацией надо “думать”, чтобы понять как она работает. Поэтому решил пойти другим путем - разобраться с truncated mean (или как его там). Кто забыл школьные лабораторки по физике, напомню:

  • Считаем дисперсию измерений (среднеквадратичное отклонение от среднего арифметического).
  • Отбрасываем все, что вылезло за пределы допустимого и усредняем еще раз.

У меня на глаз получилось что при 8 отсчетах и отклонении 1.1*sigma выходит вполне приличный результат. По затратам - 2 полных прохода по массиву данных (в данном случае - по кольцевому буферу). На первом проходе считается среднее арифметическое и дисперсия, на втором - отбрасывается лишнее и усредняется остаток. Итого:

  • Оптимизированное truncated mean чуть медленнее оптимизированной медианы (меньше чем в полтора раза), но код намного понятнее.
  • Есть “встроенный усреднятор”, который теоретически должен скакать меньше медианы. На самом деле не факт и вопрос филосовский.
  • Затраты на вычисления стабильные.
  • Если процессор с навороченными кешами - тут только чтение, запись вообще отсутствует.

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

  • Симистор открывается слегка не симметрично на положительной и отрицательной полуволне. Надо мерять не только длину полуволны, но и длину полного периода, а потом смотреть расхождение и компенсировать разницу.
  • В новой схеме (в отличие от макетки) применили усилитель для токового шунта, а у него выход никогда не становится 0 (есть малюсенькое смещение, хоть операционник и специализированный). В коде напряжение можно сравнивать с 0, а ток - нет. Ну тоже примерно понятно как лечить.

Пока все. Победа близка 😃

Продолжение квеста с регулем бормашинки и PlatformIO

Переписали математику в регуле на фиксированную точку. В принципе неплохо вышло. “Сложных” делений осталось 3 штуки на итерацию. Это когда F16 (sign + 15 bits + 16 bits) делим на F16. Если надо делить на целое число - это обычное целочисленное деление. Умножение F16 на F16 и так быстрое. При условии, что процессор поддерживает аппаратное умножение и деление, операции с фиксированной точкой сводятся к ним довольно эффективно. Кому интересно - смотрите исходники github.com/PetteriAimonen/libfixmath. Еще надо было считать арккосинус, чтобы “линейно” откусывать “напряжение” от синусоиды, это просто забил в таблицу, сразу с нужным смещением и масштабом.

Проца на глаз жрется около 25-40%. Это при частоте квантования 40 килогерц. Есть подозрение, что частоты хряпнули с изрядным запасом, но кроить пока не хочется. Если будет настроение - попробую привернуть еще медианные фильтры к АЦП. Была еще мысль запустить всё это на совсем дохлом кристалле типа stm32f030c6t6 (он аж на пол бакса дешевле, гы), но видимо не судьба. Там нема аппаратного деления, а ковыряться с оптимизациями некогда - другие проекты ждут. Кому охота поупарываться из спортивного интереса - исходники открыты.

Дальше частично разобрались с выхлопом отладчика. Иногда при отладке хочется выводить сообщения. Лепить их в UART/USB конечно можно, но давно уже не модно. Сейчас все современные кристаллы имеют разухабистые отладочные интерфейсы, и выхлоп printf модные пацаны гонят по тому же шлангу, что шьют фирмварь. Всего вариантов есть 3:

  • через semihosting - медленный, но работает через самый дешевый stlink, по 4-проводному SWD.
  • через SWO - быстрый, но надо более аккуратно выбирать программатор (тоже дешевый), плюс требует дополнительный пин, который я продолбал из-за нехватки места
  • Через RTT (segger) - надо либо китайский J-Link с проприетарным софтом, либо ручками собирать openocd, т.к. патч с поддержкой еще не не приняли.

Пояснять все эти умные слова не буду, подробности есть в гугле.

В общем, на скорую руку прилепили semihosting. Он хоть с подвывертами, но пашет. А больше такой мелкой плате и не надо. Потом может еще проверим SWO и если получится - добавлю где-нибудь сбоку недостающие пины для любителей отладки. Флаги сборки в PlatformIO пришлось добавлять через питоновский скрипт, правда в нем всего 2 строчки.

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

Что отложили до лучших времен (некогда совсем):

  • Автокалибровку мотора.
  • Web Wizard для быстрой кастомизации параметров.

Тут все просто - модель бормашинки одна, можно константы забить. А с остальным как-нибудь потом разберемся, если реально будет надо.

This site will not work without javascript!
This site will not work if cookies are completely disabled.
Site is offline