Комментарии 18
Первое, что мы попробовали, – это ESP32, но она нам не зашла. То ли плата была левая, то ли делали мы что-то неправильно, но нам никак не удавалось заставить работать энкодер.
Вероятнее всего - второе. У есп32 есть Pulse Counter (PCNT), который можно сконфигурировать для работы с энкодером:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/pcnt.html
Да, я тоже думаю, что это мы что-то делали не так.
Но проблема была в том, что к тому времени, как мы стали подбирать комплектующие, у нас уже были работающие скетчи в Ардуино. Тратить лишнее время на переход на другую платформу не хотелось, а в Ардуино нам не удалось найти работающую библиотеку для энкодера.
Чую что в поворотных столах все таки главное механика. А в остальном:
... мы что-то делали не так.
С точки зрения электроники, и возможно организации софта, по моему мнению сделано "не так" многое, как раз по причине:
... Ардуино.
Т.к. то к чему в конечном итоге пришли - автономный девайс управляемый через беспроводной интерфейс с телефона вполне себе реализуется на одной esp32 (драйвер движка для бесколлекторника - не нужен) и без дополнительного ПМО на телефоне. А вышло в итоге: связка кортекс и та же esp32 + еще дополнительный софт надо на телефон ставить.
Собственно как бы я реализовал:
Аппаратная часть - один контроллер esp32 + енкодер с согласованием уровней подключенный через pcnt + бесколлекторник с встроенным регулятором.
Программная часть:
Управление положением стола - через ПИД по положению + внутренний пропорциональный (или ПД) контур по скорости.
На esp32 запускается HTML сервер + WiFi точка доступа, при коннекте телефона - редирект на html станицу управления. Все управление столом производится из встроенного в телефон браузера.
Да, с разработкой программной части придется немного повозится, но это хоть как то будет похоже на проф. электронику а не на поделку студента 3-го курса.
Использование WI-FI вместо bluetooth - это другой подход, но я не думаю, что в данном случае он оправдан. Фотограф должен находиться рядом со столом и контролировать процесс, а обмен при этом должен быть двусторонним, если мы хотим отрисовывать прогресс так же красиво, как в мобильном приложении. Так что я думаю, что мобильное приложение в данном случае гораздо удобнее.
Управление положением стола - через ПИД по положению + внутренний пропорциональный (или ПД) контур по скорости.
ПИД-регулятор служит для поддержания заданного параметра, способного к изменениям. Как его использовать для перемещения стола на нужное расстояние? В статье сказано, что нам удалось обойтись более простыми средствами, но мне интересно, как можно было бы использовать ПИД для этой задачи.
Кстати в stm32wb
Есть и квадратурный вход таймера и Bluetooth. Квадратурный вход таймера работает так: вы подключение энкодер (через RC фильтр низких частот) на две ножки stm32: ноджку A и ножку B. Далее с помощью регистров конфигурируете свой таймер на работу с энкодером.
Далее уже автоматически факт изменения шага энкодера отражается в счётом регистре таймера, никаких библиотек не надо. А с инициализацией HAL поможет. Очень удобно.
Боюсь, при таком подходе стол в силу инерции будет часто перескакивать через заданную точку, а это недопустимо. Придётся добавлять в конструкцию тормоз, что усложнит и удорожит её.
кто мешает как у вас здесь, в статье указано, установить пороги, их 4 в таймере у stm32,
1 с минимума на максимум (когда отключать увеличение шим),
2 с с максимума на минимум (когда необходимо притормаживать),
3 остановка минимального шим, точка достигнута.
а работа не с библиотекой, а с прерываниями от таймера по порогам.
кстати 1 порог позволит автоматически поднимать шим, пока не стронется стол, т.е. можно сдвинуть 1->2, 2->3, 3->4,
а 1 каналом или не сдвигая, 4-ым ;) сделать минимальный сдвиг позиции энкодера, с учётом шума, тремора и прочих внешних воздействий, т.е. минимум это 0, а когда отработает минимальный сдвиг по энкодеру = шим в текущем состоянии это работа шим на доводке.
м... и влазя в следующий чат - приложение использует вэб-сервис, и там просто кодируется информация, а штатный компонент системы-браузер отображает.
тогда и приложение проще писать и отлаживать - как обычное html в редакторах html (я ушел с сЫсАдминства до 2007 года и не знаю текущего состояния c web2.0, html5 и прочим...)
Пороги таймера stm32? Четыре? Вы с каналами не путаете?
"Боюсь, при таком подходе стол в силу инерции будет часто перескакивать через заданную точку"
Диво дивное. Я предложил аппаратный способ, который вообще не вносит программных задержек, работает так быстро, как позволяет железо, только и успевай из счетного регистра таймера считывать актуальное значение.
А то, что из-за инерции стол перескочит - так точно перескочит, надо лишь начальные условия подобрать. И любое бесконечно малое время реакции на изменение энкодера принципиально проблему не решит. Поэтому или вводите допустимую ошибку или механически предохраняйтесь, например, поставьте червячный редуктор.
Фотограф должен находиться рядом со столом и контролировать процесс, а обмен при этом должен быть двусторонним, если мы хотим отрисовывать прогресс так же красиво, как в мобильном приложении.
Что значит двухсторонний обмен? Отображение от девайса угла поворота стола и прием от пользователя команд на поворот? Так html с этим вполне справится. Насчет красивостей ввиде секторов круга - не знаю но думаю поковыряв js тоже можно что то приличное изобразить. Вобщем ничего не мешает это красивое приложение сделать на html + js.
ПИД-регулятор служит для поддержания заданного параметра, способного к изменениям. Как его использовать для перемещения стола на нужное расстояние?
Угол поворота стола - это величина? И не просто величина, а регулируемая. Ее собственно и контролируем, дальше от этого и пляшем:
PWMмотора = ПИД(ошибки по углу);
ошибка по углу = заданный угол поворота - угол поворота с энкодера.
PWMмотора - ограничить (допустимой макс. скоростью), углы - после окончания движения приводить к диапазону +/-360град.
html с этим вполне справится
Да я и не спорю. Возможно, придётся сокеты использовать, чтобы динамически сектора рисовать, можно ещё что-то придумать. Как вы справедливо заметили вначале, мороки много. А потом, по моему субъективному мнению, мобильное приложение в любом случае будет удобней, чем браузер.
PWMмотора = ПИД(ошибки по углу)
Ясно, то есть регулятор должен стремиться к нулевому значению ошибки. Но тогда в половине случаев стол будет перескакивать через заданную точку, и придётся возвращать его назад. А задача ставится так, чтобы минимизировать количество таких перескакиваний. Таким образом, мы минимизируем общее время цикла. Мне удалось решить эту задачу без применения ПИД. Столы с разными размерами и моторами с разными передаточными числами работают устойчиво (проверено).
Но тогда в половине случаев стол будет перескакивать через заданную точку, и придётся возвращать его назад.
В ТАУ это называется перегулирование, в данном случае оно успешно лечится подбором коэффициентов ПИД регулятора.
…мобильное приложение в любом случае будет удобней, чем браузер.
Зато браузер всегда есть на любом телефоне и под любой осью :) Вобще некоторые девайсы имеют оба интерфейса и блюпуп и веб.
Но есть один существенный недостаток. Шаговый двигатель сильно шумит. Иногда двигатель попадает в резонанс, и тогда тарахтение стола становится невыносимым.
Если использовать приличный драйвер мотора с большим числом микрошагов, то шум становится значительно меньше.
Очень классно! Советую делать фото либо на камере которая вам не нужна, либо видео сплитить на картинки, иначе камера быстро изнашивается если вам надо будет сделать 100500 снимков.
Медленная и ограниченная ардуина... Мда...
С таким проектом самая простая ардуина на 328 атмеге будет более 99% времени простаивать.
Я делал проект отображения изображений на вращающемся колесе велосипеда, упёрся в скорость обмена с лентой ws2812b, которой стало недостаточно даже для прогулочной скорости. Вторую версию делал на более плотной ленте, и сначала тоже думал, ардуина виновата, но когда посчитал количество передаваемой инфы по одному пину - оказалось, упёрся в 900кбит/сек.
А тут даже скорости велосипедного колёса нет и столько инфы обрабатывать не требуется.
Вообще, про html+js тут уже сказали. Для меня некоторое время назад выбор упал бы не на esp32, а на esp8266, из-за стоимости, но может всё поменялось. Интерфейс с использованием какого-нибудь bootstrap можно сделать красивым без особых знаний css. Ajax запросы для обновления полей без обновления страницы тоже простая гуглящаяся штука. Ну, а сама esp8266 прекрасно программируется с использованием arduino фреймворка.
Esp8266 может и раздавать вафлю и одновременно быть подключенной к какой-то сети. Собственно всякие iot-девайсы зачастую на её основе сделаны, где изначально подключился к розданной девайсом вафле, выставил настройки, и затем уже через домашнюю сеть коннектишься и работаешь с девайсом.
Любой мк и любой софт ненадёжен. Будь то китайская дуина, или супер-пупер микроконтроллер. Для избежания фатальных проблем придумали вачдог таймеры. Не надо думать, что какое-то "революционное" новое устройство лучше протестированного десяток лет.
Поворотный стол. Часть 2