Портировать контроллер BLDC с STM32 на Rockchip 3399?, Легко ли избавиться от STM, когда есть ARM SOC? Опции

[baritono]

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

[baritono]

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

Сообщение отредактировал baritono - Feb 27 2018, 18:09

[a123-flex]

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

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

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

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

[AlexandrY]

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

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