|
Портировать контроллер BLDC с STM32 на Rockchip 3399?, Легко ли избавиться от STM, когда есть ARM SOC? |
|
|
|
Feb 27 2018, 00:05
|
Участник
Группа: Участник
Сообщений: 39
Регистрация: 14-01-18
Пользователь №: 101 066
|
Есть 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) ес-сно сохраняются.
|
|
|
|
|
Feb 27 2018, 05:57
|
Ally
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050
|
Цитата(baritono @ Feb 27 2018, 02:05) ... Двигателей будет от 2 до 6. Вроде мощи у RK3399 достаточно, интерфейсов тоже. Внешние чипы (DRV8302) ес-сно сохраняются. В этом опенсорсном проекте используется куча таймеров и специальная периферия для генерации PWM и синхронной с ним рабты ADC. А в RK3399 нет ни подходящего 6-и канального генератора PWM, ни синхронизируемого с ним ADC. Т.е. на RK3399 невозможно сделать нормальное управление даже одним BLDC мотором. Я бы рекомендовал посмотреть на i.MX RT1050. На них легко сделать 4-е полнофункциональных контроллера BLDC моторов. Если надо больше моторов, то потребуется сделать еще один модуль на i.MX RT1050.
|
|
|
|
|
Feb 27 2018, 07:02
|
Местный
Группа: Свой
Сообщений: 327
Регистрация: 30-10-05
Пользователь №: 10 288
|
Цитата(AlexandrY @ Feb 27 2018, 08:57) Я бы рекомендовал посмотреть на i.MX RT1050. На них легко сделать 4-е полнофункциональных контроллера BLDC моторов. Если надо больше моторов, то потребуется сделать еще один модуль на i.MX RT1050. А я бы порекомендовал посмотреть на KV58.
|
|
|
|
|
Feb 27 2018, 18:07
|
Участник
Группа: Участник
Сообщений: 39
Регистрация: 14-01-18
Пользователь №: 101 066
|
Большое спасибо за ответы. Вопрос снимается, буду использовать VESC как есть, по крайней мере для прототипа. Тем более, что софт, говорят, практически непортабелен: https://vesc-project.com/node/323 Насчёт Линукса и ОС РВ в целом соглашусь. Но RK3399 настолько мощнее и многоядернее STM32, что проблем быть не должно. На крайняк одно ядро можно освободить под это путём cgroups/isolcpus. Специализированные контроллеры брать не интересно - цель была упростить систему, повесив всю программируемую логику на центральный проц. Если не судьба, можно жить и с STM32.
Сообщение отредактировал baritono - Feb 27 2018, 18:09
|
|
|
|
|
Feb 27 2018, 22:05
|
Участник
Группа: Участник
Сообщений: 39
Регистрация: 14-01-18
Пользователь №: 101 066
|
Цитата(jcxz @ Feb 27 2018, 19:11) Никакая мыслимая многоядерность не заменит отсутствующей периферии - ногодрыгом не сделать 6-ногий ШИМ с dead-time-ми и тем более не сделать многоканальный АЦП. Придётся ещё плисину навесить, чтоб работало. Даже на ядре 1ГГц ногодрыгом GPIO не сделать нужный ШИМ? Если нет, можно ли какую-то микруху на GPIO или на другой интерфейс навесить для этих целей? Проблема в том, что VESC - это немало весьма специфического кода на C, который придётся поддерживать и развивать отдельно от основного. Хочется, чтобы весь код был в Линуксе, в одной архитектуре.
|
|
|
|
|
Feb 27 2018, 22:39
|
Гуру
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713
|
Цитата(baritono @ Feb 28 2018, 00:05) Даже на ядре 1ГГц ногодрыгом GPIO не сделать нужный ШИМ? А какая связь между частотой ядра и частотой GPIO? На какой частоте у Вас GPIO работает? Оно может вообще на 10МГц работать. И не только в частоте GPIO дело: чтобы сделать качественное управление, нужно точно выдерживать временные интервалы сигналов и временные зависимости сигналов между собой. Выдерживать их нужно с точностью до нескольких единиц нс (типичное время переключения современных силовых транзисторов - пару сотен нс). Без этого ничего путнего не получите. А сделать это можно только аппаратно, запрограммировав периферию на нужные действия. В STM32 такая периферия есть, есть она в Вашем МК? Опять-же - как измерять фазные токи? В схеме в этом проекте измеряются они на шунтах, шунты включены в нижние ключи ШИМ, а значит - нужно точно успевать запустить и закончить АЦ-преобразование за время гарантированного пассивного вектора по всем фазам. А длительность его стараются сделать как можно меньше, для увеличения эффективности работы инвертора. И ещё куча моментов. Всё это делать нужно одновременно с жёсткими временными зависимостями. Чего никак не достичь программно ногодрыгом, да ещё на многоядерной системе, где могут быть непредсказуемые задержки доступа разных ядер к общей шине, а ещё тем более - из под линуха. Цитата(baritono @ Feb 28 2018, 00:05) Если нет, можно ли какую-то микруху на GPIO или на другой интерфейс навесить для этих целей? Проблема в том, что VESC - это немало весьма специфического кода на C, который придётся поддерживать и развивать отдельно от основного. Хочется, чтобы весь код был в Линуксе, в одной архитектуре. Эту "микруху" автор исходников уже навесил - STM32F405, и видимо предусмотрел возможности управления её от внешнего МК - вот и используйте. Тем более, как видно по Вашим фразам, Вы вообще не разбираетесь в теме. Сильно сомневаюсь, что сможете что-то "портировать" не смотря ни на какие ГГц. Для этого надо сперва изучить теорию и аппаратные средства.
|
|
|
|
|
Feb 27 2018, 22:41
|
Гуру
Группа: Свой
Сообщений: 10 713
Регистрация: 11-12-04
Пользователь №: 1 448
|
Цитата(baritono @ Feb 28 2018, 01:05) Даже на ядре 1ГГц ногодрыгом GPIO не сделать нужный ШИМ? Не сделать: ногодрыг на 1ГГц Cortex-A зачастую медленнее и непредсказуемее, чем на 100MHz Cortex-M. Просто на первом никто не ставит такой задачи, и тот же GPIO может быть подключен через кучу мостов на медленной шине. Цитата(baritono @ Feb 28 2018, 01:05) Если нет, можно ли какую-то микруху на GPIO или на другой интерфейс навесить для этих целей? Проблема в том, что VESC - это немало весьма специфического кода на C, который придётся поддерживать и развивать отдельно от основного. Хочется, чтобы весь код был в Линуксе, в одной архитектуре. А смысл иметь этот код в Линуксе? Оставьте тот же STM32 в качестве "микрухи" - это дешево и не создаст лишней головной боли.
|
|
|
|
|
Feb 28 2018, 06:13
|
Профессионал
Группа: Свой
Сообщений: 1 687
Регистрация: 11-01-05
Из: Москва
Пользователь №: 1 884
|
Цитата(baritono @ Feb 27 2018, 22:07) Большое спасибо за ответы. Вопрос снимается, буду использовать VESC как есть, по крайней мере для прототипа. Тем более, что софт, говорят, практически непортабелен: https://vesc-project.com/node/323 Насчёт Линукса и ОС РВ в целом соглашусь. Но RK3399 настолько мощнее и многоядернее STM32, что проблем быть не должно. На крайняк одно ядро можно освободить под это путём cgroups/isolcpus. Специализированные контроллеры брать не интересно - цель была упростить систему, повесив всю программируемую логику на центральный проц. Если не судьба, можно жить и с STM32. Судя по всему, чувак решил очень нетривиальную задачу, само решение - результат большого исследования. Насколько я понимаю, там все совсем не просто, и попытка заменить мотор может стоить второго такого же исследования. Судя по всему главное в этом проекте - это понимание теории, реализованной в задаче, а вовсе не то, каким образом будет осуществляться ногодрыг. Поэтому для начала я бы попытался все просто повторить, и запустить на желаемом приводе. А потом возможно и задачи и хотелки радикально изменятся)))
--------------------
Если хочешь узнать, что ждет тебя на дороге впереди, спроси у тех, кто возвращается по ней.
|
|
|
|
|
Feb 28 2018, 07:28
|
Ally
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050
|
Цитата(a123-flex @ Feb 28 2018, 08:13) Судя по всему главное в этом проекте - это понимание теории Так проект же экспериментальный, там нет никаких железно отлаженных алгоритмов. Например обсервер скорости вращения ротора мужик взял из сомнительного исследования - 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. Автор постарался это сделать тщательно избегая комментирования своих сорсов. Ну это наверняка ему самому аукнется.
|
|
|
|
|
Feb 28 2018, 08:29
|
Гуру
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713
|
Цитата(a123-flex @ Feb 28 2018, 08:13) Судя по всему, чувак решил очень нетривиальную задачу, само решение - результат большого исследования. Там обычный FOC. Теория которого много где описана. Просто реализовал её. И не очень оптимально даже. Даже названия переменных и функций соответствуют названиям из теории. Цитата(a123-flex @ Feb 28 2018, 08:13) Судя по всему главное в этом проекте - это понимание теории, реализованной в задаче, а вовсе не то, каким образом будет осуществляться ногодрыг. А вот здесь - прямо в точку! Цитата(AlexandrY @ Feb 28 2018, 09:28) Обычные НЧ фильтры имеют длину в 128 коэффициентов! Причем профайлинга нигде не видно. Пробовл ли он вообще это юзать? У меня тоже сразу этот вопрос возник - насколько использованы ресурсы CPU по быстродействию? У автора в описании указано "Since there are plenty of CPU-resources left..." - только как это понимать, "plenty" - это загрузка CPU 20% или все 80%? "Сколько вешать в граммах?"
|
|
|
|
|
Feb 28 2018, 09:53
|
Ally
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050
|
Цитата(jcxz @ Feb 28 2018, 10:29) У меня тоже сразу этот вопрос возник - насколько использованы ресурсы CPU по быстродействию? У автора в описании указано "Since there are plenty of CPU-resources left..." - только как это понимать, "plenty" - это загрузка CPU 20% или все 80%? "Сколько вешать в граммах?" Не факт, что FOC он нормально запустил. FIR фильтры он формирует не обращая внимание на фазовые задержки. Какой режим управления : сенсорную коммутацию, безсенсорную коммутацию или FOC задается командами с внешнего интерфейса. Поэтому чисто на юзере проблемы с быстродействием если они возникнут.
|
|
|
|
|
Feb 28 2018, 13:49
|
Частый гость
Группа: Свой
Сообщений: 151
Регистрация: 19-04-07
Из: Иваново
Пользователь №: 27 168
|
Тут ещё многое зависит от того какую задачу требуется решать с применением электродвигателей. На мой взгляд задачу превильне решать с применением плис или современного SoC. В плис делаете аппаратный модуль генерации ШИМ + + канал токового АЦП + энкодерный канал если нужно. Так же с модуля генерации ШИМ сигнала выходит сигнал прерывания по фазовому циклу. По этому сигналу вы синхронизируете момент записи нового значения ШИМ и опрос АЦП токов в разные моменты времени. Обработка энкодера если нужна тоже аппаратная. В ПЛИС делаете регистры откуда забирать данные о состоянии мотора и регистры куда записывать задание. А уж какой процессор вы выберете для обсчёта регуляторов это дело вкуса. Ваш на частоте 1ГГц справится с обсчётом кучи моторов. Главное что генерация ШИМ, обработка АЦП и энкодеров идут в реальном времени и не нагружают процессор. Он по прерыванию фазового цикла например 10кГц обсчитывает регулятор мотора и выдаёт новое задание в ПЛИС. Правда при этом подходе про портирование опенсорс проекта не приходится говорить, но сейчас всякие FOC и прочее не проблема. ПРиложил Вам документ где объясняется как шим генерить и почему обычный процессор там не вариант. Если не хочется заморачиваться с ПЛИс у TI есть отличные мощные процессоры для управления моторами. Например http://www.ti.com/lit/ds/symlink/tms320f28377d.pdf У него аппаратный ШИМ. аппаратный модуль энкодеров и отдельные сопроцессоры реального времени для задач мотор контрола и аппаратная поддержка обсчёта тригонометрических функций. Я бы на вашем месте куда нибудь в эти стороны смотрел. Это конечно на порядок сложнее решения, но уж зато точно во всём разберётесь, да и моторы сможете любые крутить Да ещё ситара от TI кроме всего имеет на борту всё необходимое для управления 3-я моторами точно
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|