baritono 0 27 февраля, 2018 Опубликовано 27 февраля, 2018 · Жалоба Есть VESC - известный опенсорсный контроллер BLDC: http://vedder.se/2015/01/vesc-open-source-esc/ Моё устройство планируется на Rockchip 3399: http://www.orangepi.org/Orange%20Pi%20RK3399/ (не обязательно на этой плате, но они все похожи). Есть ли шанс малой кровью портировать этот VESC, написанный на C, c STM32 + ChibiOS на ARM53/72 + Linux? Двигателей будет от 2 до 6. Вроде мощи у RK3399 достаточно, интерфейсов тоже. Внешние чипы (DRV8302) ес-сно сохраняются. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 63 27 февраля, 2018 Опубликовано 27 февраля, 2018 · Жалоба Есть ли шанс малой кровью... Ни малейшего. Ибо Linux - это не ОСРВ совсем. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 2 27 февраля, 2018 Опубликовано 27 февраля, 2018 · Жалоба ... Двигателей будет от 2 до 6. Вроде мощи у RK3399 достаточно, интерфейсов тоже. Внешние чипы (DRV8302) ес-сно сохраняются. В этом опенсорсном проекте используется куча таймеров и специальная периферия для генерации PWM и синхронной с ним рабты ADC. А в RK3399 нет ни подходящего 6-и канального генератора PWM, ни синхронизируемого с ним ADC. Т.е. на RK3399 невозможно сделать нормальное управление даже одним BLDC мотором. Я бы рекомендовал посмотреть на i.MX RT1050. На них легко сделать 4-е полнофункциональных контроллера BLDC моторов. Если надо больше моторов, то потребуется сделать еще один модуль на i.MX RT1050. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
gosha-z 2 27 февраля, 2018 Опубликовано 27 февраля, 2018 · Жалоба Я бы рекомендовал посмотреть на i.MX RT1050. На них легко сделать 4-е полнофункциональных контроллера BLDC моторов. Если надо больше моторов, то потребуется сделать еще один модуль на i.MX RT1050. А я бы порекомендовал посмотреть на KV58. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Vasily_ 41 27 февраля, 2018 Опубликовано 27 февраля, 2018 · Жалоба Я бы порекомендовал, TLE9879QXA40 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
baritono 0 27 февраля, 2018 Опубликовано 27 февраля, 2018 (изменено) · Жалоба Большое спасибо за ответы. Вопрос снимается, буду использовать VESC как есть, по крайней мере для прототипа. Тем более, что софт, говорят, практически непортабелен: https://vesc-project.com/node/323 Насчёт Линукса и ОС РВ в целом соглашусь. Но RK3399 настолько мощнее и многоядернее STM32, что проблем быть не должно. На крайняк одно ядро можно освободить под это путём cgroups/isolcpus. Специализированные контроллеры брать не интересно - цель была упростить систему, повесив всю программируемую логику на центральный проц. Если не судьба, можно жить и с STM32. Изменено 27 февраля, 2018 пользователем baritono Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 27 февраля, 2018 Опубликовано 27 февраля, 2018 · Жалоба Но RK3399 настолько мощнее и многоядернее STM32, что проблем быть не должно. Никакая мыслимая многоядерность не заменит отсутствующей периферии - ногодрыгом не сделать 6-ногий ШИМ с dead-time-ми и тем более не сделать многоканальный АЦП. Придётся ещё плисину навесить, чтоб работало. :rolleyes: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
baritono 0 27 февраля, 2018 Опубликовано 27 февраля, 2018 · Жалоба Никакая мыслимая многоядерность не заменит отсутствующей периферии - ногодрыгом не сделать 6-ногий ШИМ с dead-time-ми и тем более не сделать многоканальный АЦП. Придётся ещё плисину навесить, чтоб работало. :rolleyes: Даже на ядре 1ГГц ногодрыгом GPIO не сделать нужный ШИМ? Если нет, можно ли какую-то микруху на GPIO или на другой интерфейс навесить для этих целей? Проблема в том, что VESC - это немало весьма специфического кода на C, который придётся поддерживать и развивать отдельно от основного. Хочется, чтобы весь код был в Линуксе, в одной архитектуре. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 27 февраля, 2018 Опубликовано 27 февраля, 2018 · Жалоба Даже на ядре 1ГГц ногодрыгом GPIO не сделать нужный ШИМ? А какая связь между частотой ядра и частотой GPIO? На какой частоте у Вас GPIO работает? Оно может вообще на 10МГц работать. И не только в частоте GPIO дело: чтобы сделать качественное управление, нужно точно выдерживать временные интервалы сигналов и временные зависимости сигналов между собой. Выдерживать их нужно с точностью до нескольких единиц нс (типичное время переключения современных силовых транзисторов - пару сотен нс). Без этого ничего путнего не получите. А сделать это можно только аппаратно, запрограммировав периферию на нужные действия. В STM32 такая периферия есть, есть она в Вашем МК? Опять-же - как измерять фазные токи? В схеме в этом проекте измеряются они на шунтах, шунты включены в нижние ключи ШИМ, а значит - нужно точно успевать запустить и закончить АЦ-преобразование за время гарантированного пассивного вектора по всем фазам. А длительность его стараются сделать как можно меньше, для увеличения эффективности работы инвертора. И ещё куча моментов. Всё это делать нужно одновременно с жёсткими временными зависимостями. Чего никак не достичь программно ногодрыгом, да ещё на многоядерной системе, где могут быть непредсказуемые задержки доступа разных ядер к общей шине, а ещё тем более - из под линуха. Если нет, можно ли какую-то микруху на GPIO или на другой интерфейс навесить для этих целей? Проблема в том, что VESC - это немало весьма специфического кода на C, который придётся поддерживать и развивать отдельно от основного. Хочется, чтобы весь код был в Линуксе, в одной архитектуре. Эту "микруху" автор исходников уже навесил - STM32F405, и видимо предусмотрел возможности управления её от внешнего МК - вот и используйте. Тем более, как видно по Вашим фразам, Вы вообще не разбираетесь в теме. Сильно сомневаюсь, что сможете что-то "портировать" не смотря ни на какие ГГц. Для этого надо сперва изучить теорию и аппаратные средства. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 63 27 февраля, 2018 Опубликовано 27 февраля, 2018 · Жалоба Даже на ядре 1ГГц ногодрыгом GPIO не сделать нужный ШИМ? Не сделать: ногодрыг на 1ГГц Cortex-A зачастую медленнее и непредсказуемее, чем на 100MHz Cortex-M. Просто на первом никто не ставит такой задачи, и тот же GPIO может быть подключен через кучу мостов на медленной шине. Если нет, можно ли какую-то микруху на GPIO или на другой интерфейс навесить для этих целей? Проблема в том, что VESC - это немало весьма специфического кода на C, который придётся поддерживать и развивать отдельно от основного. Хочется, чтобы весь код был в Линуксе, в одной архитектуре. А смысл иметь этот код в Линуксе? Оставьте тот же STM32 в качестве "микрухи" - это дешево и не создаст лишней головной боли. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
a123-flex 0 28 февраля, 2018 Опубликовано 28 февраля, 2018 · Жалоба Большое спасибо за ответы. Вопрос снимается, буду использовать VESC как есть, по крайней мере для прототипа. Тем более, что софт, говорят, практически непортабелен: https://vesc-project.com/node/323 Насчёт Линукса и ОС РВ в целом соглашусь. Но RK3399 настолько мощнее и многоядернее STM32, что проблем быть не должно. На крайняк одно ядро можно освободить под это путём cgroups/isolcpus. Специализированные контроллеры брать не интересно - цель была упростить систему, повесив всю программируемую логику на центральный проц. Если не судьба, можно жить и с STM32. Судя по всему, чувак решил очень нетривиальную задачу, само решение - результат большого исследования. Насколько я понимаю, там все совсем не просто, и попытка заменить мотор может стоить второго такого же исследования. Судя по всему главное в этом проекте - это понимание теории, реализованной в задаче, а вовсе не то, каким образом будет осуществляться ногодрыг. Поэтому для начала я бы попытался все просто повторить, и запустить на желаемом приводе. А потом возможно и задачи и хотелки радикально изменятся))) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 2 28 февраля, 2018 Опубликовано 28 февраля, 2018 · Жалоба Судя по всему главное в этом проекте - это понимание теории Так проект же экспериментальный, там нет никаких железно отлаженных алгоритмов. Например обсервер скорости вращения ротора мужик взял из сомнительного исследования - http://cas.ensmp.fr/~praly/Telechargement/...aly-Astolfi.pdf, о чем прямо в тексте и сообщает. В его PID алгоритме реализован anti wind-up примитивным ограничением диапазона. А основной алгоритм базируется на безсенсорной коммутации BLDC с измерением напряжения обратной ЭДС. Эти алгоритмы очень хорошо описаны в апнотах всех основных производителей. Обычные НЧ фильтры имеют длину в 128 коэффициентов! Причем профайлинга нигде не видно. Пробовл ли он вообще это юзать? Заслуга разработчика - это создание приложения BLDC Tool и видеологера с врезками телеметрии из BLDC Tool. Но протокол не документирован, и жестко зашит в программе. Протокол может работать только через один из интерфейсов: CAN, USB, UART и еще какой-то там левый модуль. Сам BLDC Tool прошивает для своей работы некие левые бинарники вместо штатного фирмваре. Т.е. похоже автор кое-что скрывает. В свой проект фирмваре он засунул историю всех версий железа, причем версии железа не описаны. Это тоже будет сильной привязкой к услугам автора. Хотя ссылка в целом интересная. Но проект явно не предназначен даже для интеграции с другой аппаратной платформой. Он заточен исключительно под BLDC Tool. Автор постарался это сделать тщательно избегая комментирования своих сорсов. Ну это наверняка ему самому аукнется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 28 февраля, 2018 Опубликовано 28 февраля, 2018 · Жалоба Судя по всему, чувак решил очень нетривиальную задачу, само решение - результат большого исследования. Там обычный FOC. Теория которого много где описана. Просто реализовал её. И не очень оптимально даже. Даже названия переменных и функций соответствуют названиям из теории. B) Судя по всему главное в этом проекте - это понимание теории, реализованной в задаче, а вовсе не то, каким образом будет осуществляться ногодрыг. А вот здесь - прямо в точку! :laughing: Обычные НЧ фильтры имеют длину в 128 коэффициентов! Причем профайлинга нигде не видно. Пробовл ли он вообще это юзать? У меня тоже сразу этот вопрос возник - насколько использованы ресурсы CPU по быстродействию? У автора в описании указано "Since there are plenty of CPU-resources left..." - только как это понимать, "plenty" - это загрузка CPU 20% или все 80%? "Сколько вешать в граммах?" Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 2 28 февраля, 2018 Опубликовано 28 февраля, 2018 · Жалоба У меня тоже сразу этот вопрос возник - насколько использованы ресурсы CPU по быстродействию? У автора в описании указано "Since there are plenty of CPU-resources left..." - только как это понимать, "plenty" - это загрузка CPU 20% или все 80%? "Сколько вешать в граммах?" Не факт, что FOC он нормально запустил. FIR фильтры он формирует не обращая внимание на фазовые задержки. Какой режим управления : сенсорную коммутацию, безсенсорную коммутацию или FOC задается командами с внешнего интерфейса. Поэтому чисто на юзере проблемы с быстродействием если они возникнут. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SergeySoG 0 28 февраля, 2018 Опубликовано 28 февраля, 2018 · Жалоба Тут ещё многое зависит от того какую задачу требуется решать с применением электродвигателей. На мой взгляд задачу превильне решать с применением плис или современного SoC. В плис делаете аппаратный модуль генерации ШИМ + + канал токового АЦП + энкодерный канал если нужно. Так же с модуля генерации ШИМ сигнала выходит сигнал прерывания по фазовому циклу. По этому сигналу вы синхронизируете момент записи нового значения ШИМ и опрос АЦП токов в разные моменты времени. Обработка энкодера если нужна тоже аппаратная. В ПЛИС делаете регистры откуда забирать данные о состоянии мотора и регистры куда записывать задание. А уж какой процессор вы выберете для обсчёта регуляторов это дело вкуса. Ваш на частоте 1ГГц справится с обсчётом кучи моторов. Главное что генерация ШИМ, обработка АЦП и энкодеров идут в реальном времени и не нагружают процессор. Он по прерыванию фазового цикла например 10кГц обсчитывает регулятор мотора и выдаёт новое задание в ПЛИС. Правда при этом подходе про портирование опенсорс проекта не приходится говорить, но сейчас всякие FOC и прочее не проблема. ПРиложил Вам документ где объясняется как шим генерить и почему обычный процессор там не вариант. Если не хочется заморачиваться с ПЛИс у TI есть отличные мощные процессоры для управления моторами. Например http://www.ti.com/lit/ds/symlink/tms320f28377d.pdf У него аппаратный ШИМ. аппаратный модуль энкодеров и отдельные сопроцессоры реального времени для задач мотор контрола и аппаратная поддержка обсчёта тригонометрических функций. Я бы на вашем месте куда нибудь в эти стороны смотрел. Это конечно на порядок сложнее решения, но уж зато точно во всём разберётесь, да и моторы сможете любые крутить Да ещё ситара от TI кроме всего имеет на борту всё необходимое для управления 3-я моторами точно Designing_a_Direct_PWM_Interface_2014_1.pdf Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться