Не, все, что это библиотека может делать, это вместо одной команды серве "иди в позицию 180 градусов", посылать регулярно команды "иди в позицию 1", "иди в позицию 2" и т.д. до 180, добавляя к этому разгон и торможение. При некоторых условиях это выглядит, как контроль скорости движения, но не решает ни одной проблемы, которые я указал, поэтому в других условиях снова будет обычное дерганное движение. Например, без нагрузки все идеально, но если прикрепить к серве голову от лампы с массой и моментом инерции, то все равно она будет болтаться.
Если вкратце, то не может. В них используется релейный регулятор, который может только включать мотор на полную вперед/назад, пока не достигнет нужного положения, очень шумящие потенциометры, с помощью которых невозможно точное измерение скорости, также интерфейс взаимодействия с RC-сервами не имеет возможностей управления скоростью.
Если чуть более подробно, то для математики, которую вы упоминаете, нужно еще поставить нормальные датчики скорости/положения, и компенсировать все вышеупомянутые недостатки сервы. Мне не кажется, что эти костыли для низкокачественных серв были бы дешевле, чем готовые продвинутые сервы.
Ну если честно, проблема "белый больше не белый" мне кажется более серьезной, чем "серый стал чуть менее серым".
Более того, если мы считаем 255 чистым белым, то идеально серым надо считать 127.5. И поскольку 128 чуток больше, то то, что 32896 на 0.5*256 больше, чем 32767.5, вообще не выглядит ошибкой.
Нет, круглое число в двоичной системе счисления это степень двойки.
Не, я понимаю, что такое круглое число в двоичной системе. Мой посыл в том, что в рамках рассматриваемой задачи это неважно. Минимальная/максимальная интенсивность (0/255) должны отображаться в минимальное/максимальное вещественное значение 0.0/1.0. То, что 255 на 1 меньше круглого 256 - это низкоуровневая особенность реализации и для задач перевода цвета неважна. Если бы входной диапазон бы 0..123, делили бы на 123, а не на 124, т.е. вообще неважно, какое там число следует за максимально возможным, круглое или нет.
Также ваш алгоритм неустойчив к увеличению точности входных данных
Дак я не предлагаю новый алгоритм, я за первый, описанный в статье, который делит на 255, и, как следует из статьи, применяется в большинстве реализаций.
Я вообще не понял ваши контрпримеры. Два варианта разбиения отрезка на доли описаны в статье.
Вот вам тоже пример, не про цвет, но по-моему лучше демонстрирующий суть задачи. Контроллер скорости принимает команду установки скорости в трёх разных видах: как 28 шагов скорости (0..27), 14 (0..13) и 127 (0..126), в каждом из случаев максимальное значение означает "максимальную скорость". Внутри контроллера все три варианта преобразуются в 0..1, но по вашим формулам "максимальное значение" будет не 1.0, а тремя разными числами! Чтобы проверить, а максимальная ли скорость, предлагается сравнивать с тремя значениями, вместо одной единицы? Чтобы отмасштабировать вещественную скорость в ещё какой-нибудь выходной диапазон команд мотора (скажем, 0..255), придется тоже учитывать, из какого входного диапазона скорость была получена? Абсолютно непонятно, какая польза от такого подхода. (Это, если что, реальный стандарт управления модельными железными дорогами)
Зачем вам в результате круглая единица, если в исходных значениях круглого числа нет?
Ну это верно с точки зрения систем счисления, а на практике чисто белый цвет (255) - это и есть "круглое" число, максимальное значение диапазона, и он должен быть отображаться в максимальное значение вещественного диапазона (1.0).
Эта же проблема указана и в самой статье, только с чисто черным цветом, который по альтернативной формуле из статьи перестает быть таковым, так что алгоритму, оперирующему вещественными числами, для определения "черный ли цвет?", надо знать, из какой глубины цвета он конвертирован.
А почему вы выбрали незакрытые с одной стороны диапазоны? В целых числах диапазон [0, 256) не имеет большого смысла, т.к. совпадает с [0, 255]. А диапазон [0, 255] в диапазон [0,1] надо переводить делением на 255.
Интересно, но все уже изобретено до нас. Вот, например, очень крутая библиотека для работы со звуком для RP2040/RP2350, а также esp32 и даже древнего esp8266. Она понимает кучу форматов, включая MIDI, и тоже использует модифицированный TinySoundFont.
меняет очень многое в структуре файла и предсказать эти изменения невозможно. Там даже версия компилятора повлиять может
Ну вот это и означает "так и не научились делать обратно-совместимые файлы". Видимо, вы просто пишете внутренние структуры из памяти в файл, а надо было сделать сериализатор/десериализатор, который пишет в файл независимо от компилятора и упаковки структур в оперативной памяти.
превратить их в плотный поток байт‑кода с точками траектории для отправки на микроконтроллер.
Для решения такой задачи непонятно, зачем вы вообще хотите сделать реалтайм на ПК. Для этого обычно отгружают реалтайм на микроконтроллер, а на ПК оставляют тяжёлые вычисления, интерфейс, и т.п.
Например, похожую задачу решает проект Klipper, где g-код для 3Д-принтеров обрабатывается на одноплатнике, а импульсы для шаговиков генерируются микроконтроллером. Этот стек используется одними из самых производительных принтеров на сегодняшний день. Дак вот, ПК-часть проекта написана на питоне! То есть при правильном разделении работ, задача успешно решается даже на языке, далеком от реалтайма настолько, насколько это вообще возможно.
Ещё вы делаете много разных оптимизаций, и хотелось бы измерений, как каждая из них влияет на результат, и не являются ли какие-то экономией на спичках (да и сравнение до/после тоже бы не помешало). И как эти выигрыши выглядят на фоне вклада ОС, которая может переключить контекст с вашего процесса на антивирус или учудить что-то подобное.
обработка 400 000 строк в секунду полностью покрывает потребности для учебных и гаражных ЧПУ и 3D принтеров
Звучит впечатляюще, но зачем вам вообще обрабатывать 400000 строк в секунду в реалтайме? Ни один станок или 3Д-принтер столько команд в секунду не выполнит.
Надо сказать, что это тот же модуль, что и в Casio ABL-100, только в пластиковом корпусе от модели F91W. ABL-100, в стальном корпусе, уже давно доступны, еще с 2024 г.
Тоже плюсую за Amazfit Bip. Всегда включенный экран, заряжать надо раз в месяц (изначально было раз в пару месяцев). Единственный минус - экран и близко не такой яркий и цветастый, как OLED, IPS, и др.
но в целом все было совершенно приторно-идиллическим
Если мне не изменяет память, буквально единицы этих стиляг-ослов (или вообще один?) смогли за считанные дни устроить полный коллапс общества, сопротивление которому психологически неподготовленные жители не смогли оказать. Решить все смог только волшебник-из-машины. То есть Носов намекал на хрупкость такой системы и неспособность к защите себя.
Люди берут спеки консолей, прикидывают примерный аналог из мира ПК и выдают их за реальные требования. Да, иногда угадывают, но опираться на это как на факт нельзя.
Вы что-то путаете, микропитон работает как обычный - компилирует исходник в байт-код, а потом его интерпретирует. Это как раз cython, nuitka и т.п. делают C-код из питона и компилируют его в нативный.
Кстати, попробуй uart подключить к трансиверам can. Can в чистом виде не получишь, а вот передачу сделаешь. У меня работало прекрасно. Просто uart гонялся на уровнях can шины. И расстояния приличные.
А если два устройства одновременно начнут передачу, все же сломается? Потому что они оба будут в одну дифпару писать
Комментатор выше пишет, что вы можете заказать разработку и платы, и прошивки, и сайта, специализированным конторам, тогда у вас будет все вышеупомянутое, но разработчиком вы не будете. Ничего устаревшего в схеме нет.
Мне кажется, что вы где-то в начале пути Данинга-Крюгера, когда все кажется легко, потому что не осознаешь объема и сложности темы. Вы, как кажется, получили MVP, сделав 5% работы, а теперь до продуктового качества осталось запрограммировать остальные 95%.
Не, все, что это библиотека может делать, это вместо одной команды серве "иди в позицию 180 градусов", посылать регулярно команды "иди в позицию 1", "иди в позицию 2" и т.д. до 180, добавляя к этому разгон и торможение. При некоторых условиях это выглядит, как контроль скорости движения, но не решает ни одной проблемы, которые я указал, поэтому в других условиях снова будет обычное дерганное движение. Например, без нагрузки все идеально, но если прикрепить к серве голову от лампы с массой и моментом инерции, то все равно она будет болтаться.
Если вкратце, то не может. В них используется релейный регулятор, который может только включать мотор на полную вперед/назад, пока не достигнет нужного положения, очень шумящие потенциометры, с помощью которых невозможно точное измерение скорости, также интерфейс взаимодействия с RC-сервами не имеет возможностей управления скоростью.
Если чуть более подробно, то для математики, которую вы упоминаете, нужно еще поставить нормальные датчики скорости/положения, и компенсировать все вышеупомянутые недостатки сервы. Мне не кажется, что эти костыли для низкокачественных серв были бы дешевле, чем готовые продвинутые сервы.
За $99 - да. Уверен, что за эти деньги там стоят копеечные радиомодельные серводвигатели, которые примерно так и двигаются
Насчёт ПД - предположу, что в договоре с банком клиент соглашается, что его ПД могут посылаться на адрес, который он указывает.
Ну если честно, проблема "белый больше не белый" мне кажется более серьезной, чем "серый стал чуть менее серым".
Более того, если мы считаем 255 чистым белым, то идеально серым надо считать 127.5. И поскольку 128 чуток больше, то то, что 32896 на 0.5*256 больше, чем 32767.5, вообще не выглядит ошибкой.
Не, я понимаю, что такое круглое число в двоичной системе. Мой посыл в том, что в рамках рассматриваемой задачи это неважно. Минимальная/максимальная интенсивность (0/255) должны отображаться в минимальное/максимальное вещественное значение 0.0/1.0. То, что 255 на 1 меньше круглого 256 - это низкоуровневая особенность реализации и для задач перевода цвета неважна. Если бы входной диапазон бы 0..123, делили бы на 123, а не на 124, т.е. вообще неважно, какое там число следует за максимально возможным, круглое или нет.
Дак я не предлагаю новый алгоритм, я за первый, описанный в статье, который делит на 255, и, как следует из статьи, применяется в большинстве реализаций.
Я вообще не понял ваши контрпримеры. Два варианта разбиения отрезка на доли описаны в статье.
Вот вам тоже пример, не про цвет, но по-моему лучше демонстрирующий суть задачи. Контроллер скорости принимает команду установки скорости в трёх разных видах: как 28 шагов скорости (0..27), 14 (0..13) и 127 (0..126), в каждом из случаев максимальное значение означает "максимальную скорость". Внутри контроллера все три варианта преобразуются в 0..1, но по вашим формулам "максимальное значение" будет не 1.0, а тремя разными числами! Чтобы проверить, а максимальная ли скорость, предлагается сравнивать с тремя значениями, вместо одной единицы? Чтобы отмасштабировать вещественную скорость в ещё какой-нибудь выходной диапазон команд мотора (скажем, 0..255), придется тоже учитывать, из какого входного диапазона скорость была получена? Абсолютно непонятно, какая польза от такого подхода. (Это, если что, реальный стандарт управления модельными железными дорогами)
Мы же рассматриваем конкретную задачу перевода RGB из uint8 во float, там не может быть 255.555
Ну это верно с точки зрения систем счисления, а на практике чисто белый цвет (255) - это и есть "круглое" число, максимальное значение диапазона, и он должен быть отображаться в максимальное значение вещественного диапазона (1.0).
Эта же проблема указана и в самой статье, только с чисто черным цветом, который по альтернативной формуле из статьи перестает быть таковым, так что алгоритму, оперирующему вещественными числами, для определения "черный ли цвет?", надо знать, из какой глубины цвета он конвертирован.
А почему вы выбрали незакрытые с одной стороны диапазоны? В целых числах диапазон [0, 256) не имеет большого смысла, т.к. совпадает с [0, 255]. А диапазон [0, 255] в диапазон [0,1] надо переводить делением на 255.
Интересно, но все уже изобретено до нас. Вот, например, очень крутая библиотека для работы со звуком для RP2040/RP2350, а также esp32 и даже древнего esp8266. Она понимает кучу форматов, включая MIDI, и тоже использует модифицированный TinySoundFont.
https://github.com/earlephilhower/ESP8266Audio
Ну вот это и означает "так и не научились делать обратно-совместимые файлы". Видимо, вы просто пишете внутренние структуры из памяти в файл, а надо было сделать сериализатор/десериализатор, который пишет в файл независимо от компилятора и упаковки структур в оперативной памяти.
Для решения такой задачи непонятно, зачем вы вообще хотите сделать реалтайм на ПК. Для этого обычно отгружают реалтайм на микроконтроллер, а на ПК оставляют тяжёлые вычисления, интерфейс, и т.п.
Например, похожую задачу решает проект Klipper, где g-код для 3Д-принтеров обрабатывается на одноплатнике, а импульсы для шаговиков генерируются микроконтроллером. Этот стек используется одними из самых производительных принтеров на сегодняшний день. Дак вот, ПК-часть проекта написана на питоне! То есть при правильном разделении работ, задача успешно решается даже на языке, далеком от реалтайма настолько, насколько это вообще возможно.
Ещё вы делаете много разных оптимизаций, и хотелось бы измерений, как каждая из них влияет на результат, и не являются ли какие-то экономией на спичках (да и сравнение до/после тоже бы не помешало). И как эти выигрыши выглядят на фоне вклада ОС, которая может переключить контекст с вашего процесса на антивирус или учудить что-то подобное.
Звучит впечатляюще, но зачем вам вообще обрабатывать 400000 строк в секунду в реалтайме? Ни один станок или 3Д-принтер столько команд в секунду не выполнит.
Надо сказать, что это тот же модуль, что и в Casio ABL-100, только в пластиковом корпусе от модели F91W. ABL-100, в стальном корпусе, уже давно доступны, еще с 2024 г.
Тоже плюсую за Amazfit Bip. Всегда включенный экран, заряжать надо раз в месяц (изначально было раз в пару месяцев). Единственный минус - экран и близко не такой яркий и цветастый, как OLED, IPS, и др.
Если мне не изменяет память, буквально единицы этих стиляг-ослов (или вообще один?) смогли за считанные дни устроить полный коллапс общества, сопротивление которому психологически неподготовленные жители не смогли оказать. Решить все смог только волшебник-из-машины. То есть Носов намекал на хрупкость такой системы и неспособность к защите себя.
И затем статья делает примерно это же
Вы что-то путаете, микропитон работает как обычный - компилирует исходник в байт-код, а потом его интерпретирует. Это как раз cython, nuitka и т.п. делают C-код из питона и компилируют его в нативный.
А если два устройства одновременно начнут передачу, все же сломается? Потому что они оба будут в одну дифпару писать
Комментатор выше пишет, что вы можете заказать разработку и платы, и прошивки, и сайта, специализированным конторам, тогда у вас будет все вышеупомянутое, но разработчиком вы не будете. Ничего устаревшего в схеме нет.
Мне кажется, что вы где-то в начале пути Данинга-Крюгера, когда все кажется легко, потому что не осознаешь объема и сложности темы. Вы, как кажется, получили MVP, сделав 5% работы, а теперь до продуктового качества осталось запрограммировать остальные 95%.