Портировать контроллер 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]

Ещё раз всем спасибо, очень продуктивная дискуссия. Добавлю несколько уточнений. По специальности я программист, но не embedded, и тем более не профи в электронике. В данном проекте я выступаю как автор идеи и инвестор. Если я решу отказаться от VESC, делать замену будут нанятые люди с соответствующим опытом. Моя задача - понять, что это даст и во что выльется.

Речь идёт тяговых двигателях мобильной робототехнической платформы. Это могут быть и мотор-колёса, и традиционные, с внутренним ротором. Обороты низкие (до 300 об/мин, если без редуктора). Стартовый момент высокий (100 кг/см и выше). На прототипе, вероятно, будут стоять мотор-колёса от гироскутера, вот они под управлением VESC: https://www.youtube.com/watch?v=xPtFhArhz-8 Датчики холла там есть, и будет добавлен энкодер. Высокооборотных, шаговых и др. моторов не будет.

RK3399 тут некоторые недооценивают. У него есть таймеры и другие фичи, характерные для контроллеров: http://opensource.rock-chips.com/wiki_RK3399 (внизу ссылка на даташит) Там 6 ядер, разделённых на три кластера: два ядра A72 2HGz, четыре A53 1.5GHz + два ядра M0 (фактически встроенный 32-битный контроллер с "deterministic, high-performance interrupt handling for time-critical applications"). Cовременный Линукс позволяет выделить процессу ядро практически в эксклюзивное пользование, без переключения контекстов, прерываний (даже системного таймера, т.н. tickless режим). К тому же у кластеров ядер отдельные кэши.

Портировать VESC я уже раздумал. Но в том, что RK3399 + низкоуровневый обвес (АЦП, ШИМ) не подходит под задачу - пока не убедили. Специализированные BLDC-микрухи брать не очень хочется, т.к. желательна возможность модификации алгоритмов и нежелательна жёсткая завязка на вероятных партнёров. ПЛИС - пожалуй, лучший вариант на перспективу, но для прототипа дороговато, да и ясности по требованиям достаточной нет.

Сообщение отредактировал baritono - Feb 28 2018, 21:22

[jcxz]

RK3399 тут некоторые недооценивают. У него есть таймеры и другие фичи, характерные для контроллеров:

Так мы не оцениваем его, мы отвечаем на ваши вопросы. Вы ничего не говорили ни про его таймеры ни про прочую необходимую периферию. А только про ядра да ногодрыг. Вам и сказали, что так задачу не решить.

Специализированные BLDC-микрухи брать не очень хочется, т.к. желательна возможность модификации алгоритмов и нежелательна жёсткая завязка на вероятных партнёров. ПЛИС - пожалуй, лучший вариант на перспективу

Если под "специализированными BLDC-микрухами" Вы имеете в виду МК с нужной периферией, то какая разница - писать прошивку для него или прошивку для ПЛИС?

Ведь если колесо поворотное, то силу и управление на привод нужно подавать ЧЕРЕЗ ТОКОСЪЕМНИК. Кроме того, у колеса есть проскальзывание.

Так ли нужно именно "ЧЕРЕЗ ТОКОСЪЕМНИК"? Например на асинхронник с короткозамкнутыми обмотками, ток в обмотки ротора подаётся без всяких токосъёмников. И там уже течёт ток. Проскальзывание да - при этом необходимо.

[baritono]

Если под "специализированными BLDC-микрухами" Вы имеете в виду МК с нужной периферией, то какая разница - писать прошивку для него или прошивку для ПЛИС?

В ПЛИС можно засунуть ещё много полезного, получив в итоге что-то гораздо более подходящее под задачу, чем RK3399 + МК. ПЛИС набирают популярность, они предлагаются уж в облачных сервисах и в комплекте с обычными процами. Опыт работы с ними точно пригодится. ПЛИС-решение можно развивать, а МК может через несколько лет устареть, пропасть, попасть под санкции, и на колу мочало начинай сначала.

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

Интересно было бы это "легко" разбить на основные составляющие. Допустим, есть отладочная плата от NXP, есть RK3399, есть мотор-колесо от гироскутера. Нужно, чтобы линуксовая софтина с RK3399 могла задать или считать параметры: скорость, момент, потребляемый ток. Какие этапы и ориентировочные трудозатраты предстоят?

Заслуга разработчика - это создание приложения BLDC Tool и видеологера с врезками телеметрии из BLDC Tool.
Но протокол не документирован, и жестко зашит в программе.
Протокол может работать только через один из интерфейсов: CAN, USB, UART и еще какой-то там левый модуль.

Сам BLDC Tool прошивает для своей работы некие левые бинарники вместо штатного фирмваре. Т.е. похоже автор кое-что скрывает.
В свой проект фирмваре он засунул историю всех версий железа, причем версии железа не описаны. Это тоже будет сильной привязкой к услугам автора.

Хотя ссылка в целом интересная.
Но проект явно не предназначен даже для интеграции с другой аппаратной платформой. Он заточен исключительно под BLDC Tool.
Автор постарался это сделать тщательно избегая комментирования своих сорсов. Ну это наверняка ему самому аукнется.

А по поводу этого что скажете: https://odriverobotics.com/#features ? Тоже опенсорс, на той же аппаратной базе, но относительно новая разработка.

[AlexandrY]

А по поводу этого что скажете: https://odriverobotics.com/#features ? Тоже опенсорс, на той же аппаратной базе, но относительно новая разработка.

Не похоже на новую разработку.
Парень просто клонировал проект VESC и перенес с ChibiOS на FreeRTOS. Но это ему было не сложно потому как обе используют один и тот же HAL.
Поубирал все экспериментальные фичи и тюнингировал под два мотора.
Тулсов для тюнинга своих не создал. Код как всегда скверно документирован.
Но что-то на питоне с протоколом сварганил. Такой питон под линуксом наверно пойдет.
Может это и есть то что вам нужно.

Кста, там парень и на FPGA сделал. Но внутри то все равно стоит процессорное ядро NIOS и его надо программировать и отлаживать.
Так что в этой теме FPGA не дает никакой пользы, NIOS будет работать медленней нативного микроконтроллера.
Если вы конечно не знаете какого нибудь секретного алгоритма FOC пользующего всю мощь аппаратных фильтров.
Но чет с этим тут никто не светился на моей памяти.