Перейти к содержанию
    

Портировать контроллер BLDC с STM32 на Rockchip 3399?

Есть 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) ес-сно сохраняются.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

... Двигателей будет от 2 до 6. Вроде мощи у RK3399 достаточно, интерфейсов тоже. Внешние чипы (DRV8302) ес-сно сохраняются.

В этом опенсорсном проекте используется куча таймеров и специальная периферия для генерации PWM и синхронной с ним рабты ADC.

А в RK3399 нет ни подходящего 6-и канального генератора PWM, ни синхронизируемого с ним ADC.

Т.е. на RK3399 невозможно сделать нормальное управление даже одним BLDC мотором.

 

Я бы рекомендовал посмотреть на i.MX RT1050. На них легко сделать 4-е полнофункциональных контроллера BLDC моторов.

Если надо больше моторов, то потребуется сделать еще один модуль на i.MX RT1050.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я бы рекомендовал посмотреть на i.MX RT1050. На них легко сделать 4-е полнофункциональных контроллера BLDC моторов.

Если надо больше моторов, то потребуется сделать еще один модуль на i.MX RT1050.

А я бы порекомендовал посмотреть на KV58.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Большое спасибо за ответы. Вопрос снимается, буду использовать VESC как есть, по крайней мере для прототипа. Тем более, что софт, говорят, практически непортабелен: https://vesc-project.com/node/323 Насчёт Линукса и ОС РВ в целом соглашусь. Но RK3399 настолько мощнее и многоядернее STM32, что проблем быть не должно. На крайняк одно ядро можно освободить под это путём cgroups/isolcpus. Специализированные контроллеры брать не интересно - цель была упростить систему, повесив всю программируемую логику на центральный проц. Если не судьба, можно жить и с STM32.

Изменено пользователем baritono

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Но RK3399 настолько мощнее и многоядернее STM32, что проблем быть не должно.

Никакая мыслимая многоядерность не заменит отсутствующей периферии - ногодрыгом не сделать 6-ногий ШИМ с dead-time-ми и тем более не сделать многоканальный АЦП. Придётся ещё плисину навесить, чтоб работало. :rolleyes:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Никакая мыслимая многоядерность не заменит отсутствующей периферии - ногодрыгом не сделать 6-ногий ШИМ с dead-time-ми и тем более не сделать многоканальный АЦП. Придётся ещё плисину навесить, чтоб работало. :rolleyes:

 

Даже на ядре 1ГГц ногодрыгом GPIO не сделать нужный ШИМ? Если нет, можно ли какую-то микруху на GPIO или на другой интерфейс навесить для этих целей? Проблема в том, что VESC - это немало весьма специфического кода на C, который придётся поддерживать и развивать отдельно от основного. Хочется, чтобы весь код был в Линуксе, в одной архитектуре.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Даже на ядре 1ГГц ногодрыгом GPIO не сделать нужный ШИМ?

А какая связь между частотой ядра и частотой GPIO? На какой частоте у Вас GPIO работает? Оно может вообще на 10МГц работать.

И не только в частоте GPIO дело: чтобы сделать качественное управление, нужно точно выдерживать временные интервалы сигналов и временные зависимости сигналов между собой.

Выдерживать их нужно с точностью до нескольких единиц нс (типичное время переключения современных силовых транзисторов - пару сотен нс).

Без этого ничего путнего не получите.

А сделать это можно только аппаратно, запрограммировав периферию на нужные действия. В STM32 такая периферия есть, есть она в Вашем МК?

Опять-же - как измерять фазные токи? В схеме в этом проекте измеряются они на шунтах, шунты включены в нижние ключи ШИМ, а значит - нужно точно успевать запустить и закончить АЦ-преобразование за время гарантированного пассивного вектора по всем фазам. А длительность его стараются сделать как можно меньше, для увеличения эффективности работы инвертора.

И ещё куча моментов. Всё это делать нужно одновременно с жёсткими временными зависимостями. Чего никак не достичь программно ногодрыгом, да ещё на многоядерной системе, где могут быть непредсказуемые задержки доступа разных ядер к общей шине, а ещё тем более - из под линуха.

 

Если нет, можно ли какую-то микруху на GPIO или на другой интерфейс навесить для этих целей? Проблема в том, что VESC - это немало весьма специфического кода на C, который придётся поддерживать и развивать отдельно от основного. Хочется, чтобы весь код был в Линуксе, в одной архитектуре.

Эту "микруху" автор исходников уже навесил - STM32F405, и видимо предусмотрел возможности управления её от внешнего МК - вот и используйте.

Тем более, как видно по Вашим фразам, Вы вообще не разбираетесь в теме. Сильно сомневаюсь, что сможете что-то "портировать" не смотря ни на какие ГГц. Для этого надо сперва изучить теорию и аппаратные средства.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Даже на ядре 1ГГц ногодрыгом GPIO не сделать нужный ШИМ?

Не сделать: ногодрыг на 1ГГц Cortex-A зачастую медленнее и непредсказуемее, чем на 100MHz Cortex-M.

Просто на первом никто не ставит такой задачи, и тот же GPIO может быть подключен через кучу мостов

на медленной шине.

 

Если нет, можно ли какую-то микруху на GPIO или на другой интерфейс навесить для этих целей? Проблема в том, что VESC - это немало весьма специфического кода на C, который придётся поддерживать и развивать отдельно от основного. Хочется, чтобы весь код был в Линуксе, в одной архитектуре.

А смысл иметь этот код в Линуксе? Оставьте тот же STM32 в качестве "микрухи" - это дешево и не создаст

лишней головной боли.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Большое спасибо за ответы. Вопрос снимается, буду использовать VESC как есть, по крайней мере для прототипа. Тем более, что софт, говорят, практически непортабелен: https://vesc-project.com/node/323 Насчёт Линукса и ОС РВ в целом соглашусь. Но RK3399 настолько мощнее и многоядернее STM32, что проблем быть не должно. На крайняк одно ядро можно освободить под это путём cgroups/isolcpus. Специализированные контроллеры брать не интересно - цель была упростить систему, повесив всю программируемую логику на центральный проц. Если не судьба, можно жить и с STM32.

Судя по всему, чувак решил очень нетривиальную задачу, само решение - результат большого исследования.

Насколько я понимаю, там все совсем не просто, и попытка заменить мотор может стоить второго такого же исследования.

 

Судя по всему главное в этом проекте - это понимание теории, реализованной в задаче, а вовсе не то, каким образом будет осуществляться ногодрыг. Поэтому для начала я бы попытался все просто повторить, и запустить на желаемом приводе.

 

А потом возможно и задачи и хотелки радикально изменятся)))

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Судя по всему главное в этом проекте - это понимание теории

Так проект же экспериментальный, там нет никаких железно отлаженных алгоритмов.

Например обсервер скорости вращения ротора мужик взял из сомнительного исследования - 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.

Автор постарался это сделать тщательно избегая комментирования своих сорсов. Ну это наверняка ему самому аукнется.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Судя по всему, чувак решил очень нетривиальную задачу, само решение - результат большого исследования.

Там обычный FOC. Теория которого много где описана. Просто реализовал её. И не очень оптимально даже.

Даже названия переменных и функций соответствуют названиям из теории. B)

 

Судя по всему главное в этом проекте - это понимание теории, реализованной в задаче, а вовсе не то, каким образом будет осуществляться ногодрыг.

А вот здесь - прямо в точку! :laughing:

 

Обычные НЧ фильтры имеют длину в 128 коэффициентов! Причем профайлинга нигде не видно. Пробовл ли он вообще это юзать?

У меня тоже сразу этот вопрос возник - насколько использованы ресурсы CPU по быстродействию?

У автора в описании указано "Since there are plenty of CPU-resources left..." - только как это понимать, "plenty" - это загрузка CPU 20% или все 80%? "Сколько вешать в граммах?"

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

У меня тоже сразу этот вопрос возник - насколько использованы ресурсы CPU по быстродействию?

У автора в описании указано "Since there are plenty of CPU-resources left..." - только как это понимать, "plenty" - это загрузка CPU 20% или все 80%? "Сколько вешать в граммах?"

Не факт, что FOC он нормально запустил.

FIR фильтры он формирует не обращая внимание на фазовые задержки.

Какой режим управления : сенсорную коммутацию, безсенсорную коммутацию или FOC задается командами с внешнего интерфейса.

Поэтому чисто на юзере проблемы с быстродействием если они возникнут.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Тут ещё многое зависит от того какую задачу требуется решать с применением электродвигателей. На мой взгляд задачу превильне решать с применением плис или современного SoC. В плис делаете аппаратный модуль генерации ШИМ + + канал токового АЦП + энкодерный канал если нужно.

Так же с модуля генерации ШИМ сигнала выходит сигнал прерывания по фазовому циклу. По этому сигналу вы синхронизируете момент записи нового значения ШИМ и опрос АЦП токов в разные моменты времени. Обработка энкодера если нужна тоже аппаратная. В ПЛИС делаете регистры откуда забирать данные о состоянии мотора и регистры куда записывать задание. А уж какой процессор вы выберете для обсчёта регуляторов это дело вкуса. Ваш на частоте 1ГГц справится с обсчётом кучи моторов. Главное что генерация ШИМ, обработка АЦП и энкодеров идут в реальном времени и не нагружают процессор. Он по прерыванию фазового цикла например 10кГц обсчитывает регулятор мотора и выдаёт новое задание в ПЛИС.

Правда при этом подходе про портирование опенсорс проекта не приходится говорить, но сейчас всякие FOC и прочее не проблема.

 

ПРиложил Вам документ где объясняется как шим генерить и почему обычный процессор там не вариант.

 

Если не хочется заморачиваться с ПЛИс у TI есть отличные мощные процессоры для управления моторами. Например http://www.ti.com/lit/ds/symlink/tms320f28377d.pdf У него аппаратный ШИМ. аппаратный модуль энкодеров и отдельные сопроцессоры реального времени для задач мотор контрола и аппаратная поддержка обсчёта тригонометрических функций. Я бы на вашем месте куда нибудь в эти стороны смотрел.

 

Это конечно на порядок сложнее решения, но уж зато точно во всём разберётесь, да и моторы сможете любые крутить

 

Да ещё ситара от TI кроме всего имеет на борту всё необходимое для управления 3-я моторами точно

Designing_a_Direct_PWM_Interface_2014_1.pdf

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...