Зачем нужны классы классы входов/выходов реле и некоего оптопрерывателя если они не используются в проекте? И зачем вообще они нужны, если всё, что они делают, это задают режим и дублируют штатные digitalRead/digitalWrite?
Зачем вообще для нагревателя использовать фазовое регулирование? Куда проще коммутировать по периодам - тогда можно вообще выкинуть схему детектирования нуля и просто поставить оптрон с коммутацией по нулю.
Класс управления семисегментным индикатором просто за пределами добра и зла.
Для чего вообще нужен регулятор без обратной связи (по температуре, например)?
Надеюсь понятно, что характеристика регулирования фазового регулятора сильно нелинейна? И изменение на 1 вовсе не означает изменение мощности на 1%? Ну, на всякий случай.
Приоритеты логических, арифметических и сравнительных операций лучше явно указывать скобками - это существенно облегчает понимание логики действий. То есть не
Если он висит со 100% тяги(пренебрежём стабилизацией)
Хм. Я вроде бы прямым текстом пишу, что на 100% он висеть не может именно из-за необходимости стабилизации. Так как ему будет просто нечем парировать отклонения (вы же знаете, что квадрокоптеры и вертолёты находятся в принципе в неустойчивом состоянии, да?). С вертолётом автомат перекоса перераспределяет тягу по плоскости винта, поэтому он может летать на 100% тяги. А вот квадрик - не может, так как для парирования отклонения ему нужно уменьшить тягу на одной стороне и увеличить на другой.
Да не, можно, конечно. Но далеко не всякий формат поддерживает ts. А уже тем более это не работает в случае " пытаясь собрать в одно целое видео разных форматов", как в исходном комментарии.
Тут уже либо надо конвертить сперва в промежуточный формат и потом уже собирать всё это в кучу. Либо пытаться как-то извратиться через фрейм-сервера. Но этим лично я не занимался, поэтому не могу ничего конкретного сказать.
Вот что он не любит - это собирать несколько клипов в один. Совершенно не его задача.
А вот чего мне у него действительно не хватает - некоего внутреннего скриптового языка, чтобы можно было внутри него формировать командную строку в зависимости от формата входного файла. Поэтому у меня большинство задач решается либо через bat'ник - запустил ffmpeg, получил параметры входного файла, распарсил выход, сформировал командную строку, запустил ffmpeg на обработку. Либо через самописные программы, делающие примерно то же самое, но когда нужно что-то более наворочанное.
Посмотрел статью, на которую дана ссылка, и стал понимать. Дело в том, что я в основном имею дело с профессиональными программами работы с видео. И у них алгоритм именно такой - если цветовое пространство прописано в файле - работать в нём. Не прописано - смотрим по разрешению файла.
Если же данный алгоритм не гарантирован - то, конечно, лучше прописывать цветовое пространство в явном виде.
Немного напоминает ранние компьютерные видеоплейера, программисты которых в принципе не понимали - что такое чересстрочная развертка и как пиксель может быть неквадратным
Обычно считается по ширине - всё, что до 720 - SD, 721 и более - HD.
Проблема в том, что для этого надо учитывать входное цветовое пространство. То есть можно, конечно, по умолчанию ставить видеофильтр приведения к 709, но это, скорее костыль.
А смысл? В 99% при разрешении видео SD и ниже - bt470, всё что выше - b709. Тут, правда, есть подводный камень - если делаешь апскейл SD-HD или даунскейл HD-SD, то лучше прописать преобразование в явном виде. А в остальных случаях особо и не надо.
Типов ESC может быть два (поправьте, если ошибаюсь):
По большому счету любой ESC состоит из четырех компонентов:
микроконтроллер
драйверы выходных ключей
выходные ключи
стабилизатор питания
А вот прошивок под это всё существует довольно много. Из популярных:
SimonK (стоит в большинстве копеечных китайских регуляторов)
BlHeli - открытый код, огромное количество поддерживаемых ESC, прекрасные возможности по настройке, легко кастомизируется (например, я делал версию BLHeli для регуляторов Cheerson CX20).
BLHeli32 - новая версия от того же автора, код закрыт
Вроде еще несколько новых появилось, но давно не следил, не в теме.
балансировочный разъём для правильной зарядки с балансировкой заряда между элементами аккумулятора
Это вы где-то что-то напутали - это не имеет отношения к ESC
Вообще - проект странноватый. Ну, то есть я понимаю стремление сделать всё самостоятельно с нуля - это должно быть довольно забавно. Но выбор компонентов вызывает оторопь - древний, как г.м. радиомодуль, esp32 в качестве декодера сигналов радиомодуля (основная прелесть - wifi - не используется вообще, выводов фиг да ни фига, многоканальный PWM делается через одно место) и в качестве вишенки - Arduino Nano для передатчика.
Ну, мне казалось, что эта банальная истина давно известна любому коптеростроителю. Увеличиваешь массу батарей за оптимум - вылетаешь на неоптимальный режим работы ВМГ и теряешь время полёта. Уменьшаешь массу батарей - теряешь время полёта за счёт емкости батарей. Обычно пользуются эмпирической схемой - если у тебя ВМГ работает где-то на 50% в режиме висения - ты где-то около оптимума.
Было бы любопытно, если бы был приведён алгоритм поиска этого самого оптимума по заданным параметрам. Хотя, в принципе, это довольно элементарно делается в том же ecalc. Разве что вручную батарею поперебирать, но это буквально несколько минут.
Во-первых, коптер в принципе не может летать на 100% тяге моторов. Так как в таком случае он не сможет стабилизировать своё положение. Обычным значением тяги висения является 50% максимальной тяги.
Во-вторых - если честно - я вообще не понял - зачем эти выкладки и какой их практический смысл. Поиск оптимальной массы батарей по параметру время полёта? Но это бессмысленно, если не учитывать массу конструкции (рама/двигатели/регуляторы и т.д.). А если же считать реальную конфигурацию, то проще посчитать на классическом онлайн калькуляторе ecalc.
Для начала - пойдет :) Основная неправильность - у вас нет диагоналей. А без диагоналей всё "косая" нагрузка прилагается к уголкам с большим плечом. Если быть аккуратным, то какое-то время это всё продержится, но лучше добавить диагональные распорки.
Как я понимаю, описываемая автором программа по сути это GUI к некоей серверной части, которая отдает готовые картинки в заданном формате PCX. Поэтому в эту часть у него просто нету доступа.
Для грубого поиска неголубых пикселей можно было просто использовать прореживание - то есть проверять не все пиксели, а только сетку с шагом 8, например. Это бы уменьшило требуемые ресурсы в 64 раза. Да, есть небольшая вероятность пропустить маленькие объекты, что в данной задаче совершенно несущественно.
Так он и не скажет - всё это здесь пишется только для того, чтобы завлечь в свою школу. Поэтому методы используются вполне "инфоцыганские" - у меня есть тайное знание, которое есть только у меня, которое сделает вас счастливым. Но если вы вступите в мою секту, то вы получите шанс приобщиться к этому тайному знанию. Гоните деньги.
Я когда искал пути поучиться английскому довольно плотно прошерстил интернет и был искренне удивлён - какое количество "английских школ" существует на таких принципах - обязательно должен быть некий гуру с тайным знанием, у него куча поклонников (почему-то в основном поклонниц), которые оставляют счастливые отзывы под их роликами на youtube. Длинные статьи, смысл которых вкратце можно выразить как "вы ни черта ничему не научитесь, пока не припадёте к благодати моего Знания (именно с большой буквы". И такие же ролики на youtube. Но вот чего я никогда не встречал - это объективного сравнения результата работы разных школ. Почему-то.
Что-то мне кажется, что в современных условиях это вообще не задача.
Эххх, разбередили :) Больше двадцати лет назад писал прошивку для управления синхронным приводом киношного 35 мм магнитофона ЛОМО. Трёхфазный сигнал + дополнительный пилот-тон, из которого внутренний привод решал - какое напряжение подавать на двигатель, чтобы он не вышел из синхрона. MCS-51 (ВЕ48), ассемблер, отладка методом прошивки ПЗУ и засовывания в кроватку. Плавный разгон с заданным ускорением, такое же плавное торможение и стабилизация скорости с отклонением не более 0.1% Эхххх, времена... :)
Есть способ сделать конструкцию еще тоньше, но это уже ЛУТом не получится.
Для каждой детали выфрезеровывается соответствующее отверстие в плате и деталь "утапливается" в плату. Результат выглядит странно, но вполне работоспособно.
Как лет на 15 назад вернулся...
Вспоминается троллейбус из буханки почему-то
Монеты скорее всего из какого-нибудь фонтана, поэтому в таком состоянии
Зачем нужны классы классы входов/выходов реле и некоего оптопрерывателя если они не используются в проекте? И зачем вообще они нужны, если всё, что они делают, это задают режим и дублируют штатные digitalRead/digitalWrite?
Зачем вообще для нагревателя использовать фазовое регулирование? Куда проще коммутировать по периодам - тогда можно вообще выкинуть схему детектирования нуля и просто поставить оптрон с коммутацией по нулю.
Класс управления семисегментным индикатором просто за пределами добра и зла.
Для чего вообще нужен регулятор без обратной связи (по температуре, например)?
Надеюсь понятно, что характеристика регулирования фазового регулятора сильно нелинейна? И изменение на 1 вовсе не означает изменение мощности на 1%? Ну, на всякий случай.
Приоритеты логических, арифметических и сравнительных операций лучше явно указывать скобками - это существенно облегчает понимание логики действий. То есть не
!btnState && !_flag && millis() - _tmr >= 100а
!btnState && !_flag && ((millis() - _tmr) >= 100)Хм. Я вроде бы прямым текстом пишу, что на 100% он висеть не может именно из-за необходимости стабилизации. Так как ему будет просто нечем парировать отклонения (вы же знаете, что квадрокоптеры и вертолёты находятся в принципе в неустойчивом состоянии, да?). С вертолётом автомат перекоса перераспределяет тягу по плоскости винта, поэтому он может летать на 100% тяги. А вот квадрик - не может, так как для парирования отклонения ему нужно уменьшить тягу на одной стороне и увеличить на другой.
Да не, можно, конечно. Но далеко не всякий формат поддерживает ts. А уже тем более это не работает в случае " пытаясь собрать в одно целое видео разных форматов", как в исходном комментарии.
Тут уже либо надо конвертить сперва в промежуточный формат и потом уже собирать всё это в кучу. Либо пытаться как-то извратиться через фрейм-сервера. Но этим лично я не занимался, поэтому не могу ничего конкретного сказать.
Вот что он не любит - это собирать несколько клипов в один. Совершенно не его задача.
А вот чего мне у него действительно не хватает - некоего внутреннего скриптового языка, чтобы можно было внутри него формировать командную строку в зависимости от формата входного файла. Поэтому у меня большинство задач решается либо через bat'ник - запустил ffmpeg, получил параметры входного файла, распарсил выход, сформировал командную строку, запустил ffmpeg на обработку. Либо через самописные программы, делающие примерно то же самое, но когда нужно что-то более наворочанное.
Ну и, конечно, его библиотеки просто великолепны.
Посмотрел статью, на которую дана ссылка, и стал понимать. Дело в том, что я в основном имею дело с профессиональными программами работы с видео. И у них алгоритм именно такой - если цветовое пространство прописано в файле - работать в нём. Не прописано - смотрим по разрешению файла.
Если же данный алгоритм не гарантирован - то, конечно, лучше прописывать цветовое пространство в явном виде.
Немного напоминает ранние компьютерные видеоплейера, программисты которых в принципе не понимали - что такое чересстрочная развертка и как пиксель может быть неквадратным
Обычно считается по ширине - всё, что до 720 - SD, 721 и более - HD.
Проблема в том, что для этого надо учитывать входное цветовое пространство. То есть можно, конечно, по умолчанию ставить видеофильтр приведения к 709, но это, скорее костыль.
А смысл? В 99% при разрешении видео SD и ниже - bt470, всё что выше - b709. Тут, правда, есть подводный камень - если делаешь апскейл SD-HD или даунскейл HD-SD, то лучше прописать преобразование в явном виде. А в остальных случаях особо и не надо.
Эээээ. Что???
А вообще - статья мне напомнила классический рисунок "как нарисовать сову".
По большому счету любой ESC состоит из четырех компонентов:
микроконтроллер
драйверы выходных ключей
выходные ключи
стабилизатор питания
А вот прошивок под это всё существует довольно много. Из популярных:
SimonK (стоит в большинстве копеечных китайских регуляторов)
BlHeli - открытый код, огромное количество поддерживаемых ESC, прекрасные возможности по настройке, легко кастомизируется (например, я делал версию BLHeli для регуляторов Cheerson CX20).
BLHeli32 - новая версия от того же автора, код закрыт
Вроде еще несколько новых появилось, но давно не следил, не в теме.
Это вы где-то что-то напутали - это не имеет отношения к ESC
Вообще - проект странноватый. Ну, то есть я понимаю стремление сделать всё самостоятельно с нуля - это должно быть довольно забавно. Но выбор компонентов вызывает оторопь - древний, как г.м. радиомодуль, esp32 в качестве декодера сигналов радиомодуля (основная прелесть - wifi - не используется вообще, выводов фиг да ни фига, многоканальный PWM делается через одно место) и в качестве вишенки - Arduino Nano для передатчика.
Месье знает толк в извращениях...
Ну, мне казалось, что эта банальная истина давно известна любому коптеростроителю. Увеличиваешь массу батарей за оптимум - вылетаешь на неоптимальный режим работы ВМГ и теряешь время полёта. Уменьшаешь массу батарей - теряешь время полёта за счёт емкости батарей. Обычно пользуются эмпирической схемой - если у тебя ВМГ работает где-то на 50% в режиме висения - ты где-то около оптимума.
Было бы любопытно, если бы был приведён алгоритм поиска этого самого оптимума по заданным параметрам. Хотя, в принципе, это довольно элементарно делается в том же ecalc. Разве что вручную батарею поперебирать, но это буквально несколько минут.
Во-первых, коптер в принципе не может летать на 100% тяге моторов. Так как в таком случае он не сможет стабилизировать своё положение. Обычным значением тяги висения является 50% максимальной тяги.
Во-вторых - если честно - я вообще не понял - зачем эти выкладки и какой их практический смысл. Поиск оптимальной массы батарей по параметру время полёта? Но это бессмысленно, если не учитывать массу конструкции (рама/двигатели/регуляторы и т.д.). А если же считать реальную конфигурацию, то проще посчитать на классическом онлайн калькуляторе ecalc.
Для начала - пойдет :) Основная неправильность - у вас нет диагоналей. А без диагоналей всё "косая" нагрузка прилагается к уголкам с большим плечом. Если быть аккуратным, то какое-то время это всё продержится, но лучше добавить диагональные распорки.
Как я понимаю, описываемая автором программа по сути это GUI к некоей серверной части, которая отдает готовые картинки в заданном формате PCX. Поэтому в эту часть у него просто нету доступа.
Для грубого поиска неголубых пикселей можно было просто использовать прореживание - то есть проверять не все пиксели, а только сетку с шагом 8, например. Это бы уменьшило требуемые ресурсы в 64 раза. Да, есть небольшая вероятность пропустить маленькие объекты, что в данной задаче совершенно несущественно.
Так он и не скажет - всё это здесь пишется только для того, чтобы завлечь в свою школу. Поэтому методы используются вполне "инфоцыганские" - у меня есть тайное знание, которое есть только у меня, которое сделает вас счастливым. Но если вы вступите в мою секту, то вы получите шанс приобщиться к этому тайному знанию. Гоните деньги.
Я когда искал пути поучиться английскому довольно плотно прошерстил интернет и был искренне удивлён - какое количество "английских школ" существует на таких принципах - обязательно должен быть некий гуру с тайным знанием, у него куча поклонников (почему-то в основном поклонниц), которые оставляют счастливые отзывы под их роликами на youtube. Длинные статьи, смысл которых вкратце можно выразить как "вы ни черта ничему не научитесь, пока не припадёте к благодати моего Знания (именно с большой буквы". И такие же ролики на youtube. Но вот чего я никогда не встречал - это объективного сравнения результата работы разных школ. Почему-то.
Что-то мне кажется, что в современных условиях это вообще не задача.
Эххх, разбередили :) Больше двадцати лет назад писал прошивку для управления синхронным приводом киношного 35 мм магнитофона ЛОМО. Трёхфазный сигнал + дополнительный пилот-тон, из которого внутренний привод решал - какое напряжение подавать на двигатель, чтобы он не вышел из синхрона. MCS-51 (ВЕ48), ассемблер, отладка методом прошивки ПЗУ и засовывания в кроватку. Плавный разгон с заданным ускорением, такое же плавное торможение и стабилизация скорости с отклонением не более 0.1% Эхххх, времена... :)
На али по 100 рублей
Пройдёшь, конечно. У MPU питание 2.375V-3.46V, у attiny от 2.7В. Если взять с индексом V, то вообще от 1.8В
Есть способ сделать конструкцию еще тоньше, но это уже ЛУТом не получится.
Для каждой детали выфрезеровывается соответствующее отверстие в плате и деталь "утапливается" в плату. Результат выглядит странно, но вполне работоспособно.