Создание собственной системы стабилизации
главное из этого - чтобы лапы can не были заняты шимом выходным, или ещё чем…
Ну потому что ESC32 в теории CAN умеет, а по факту, реализации нету в коде (ну или не было раньше, мот уже есть)
Если в коде нет, то нафиг они за такую цену. Если только как плата под разработку ПО, но всё равно дорого.
Если в коде нет, то нафиг они за такую цену. Если только как плата под разработку ПО, но всё равно дорого.
Если в коде нет, значит можно дописать 😃
А если ждать когда кто нибудь всё придумает и сделает, то зачем эта тема нужна?
Да и цена вроде адекватная, по сравнению с оригиналом (ESC32)
Если в коде нет, значит можно дописать 😃
А если ждать когда кто нибудь всё придумает и сделает, то зачем эта тема нужна?
Да и цена вроде адекватная, по сравнению с оригиналом (ESC32)
Насколько я помню - они до 4S только, а значит применение очень ограниченное - в основном мелкие коптеры-игрушки и FPV. То есть бестолковые. Там, где нужна обратная связь и раскрываются преимущества CAN, требуется и напряжение побольше, для серьезных машинок.
Если в коде нет, значит можно дописать
Это понятно, но кто будет писать? У меня 6 месяце ушло на понимание принципов получения горизонта от ДУСа и акселя, хотя вроде всё понятно и примеров море. А чтоб нормальный код регуля написать нужно подробно изучить принципы и теорию работы БК мотора как электромашины (векторы напряжения и тока, скольжение поля и пр., я давно это мимо проходил), описать это коде. Тупой порт открытого (и правильного (!)) кода, а надо ещё найти таковой, может дать только обратку по оборотам, ну и возможно, если схема предусматривает, токам фаз.
где нужна обратная связь и раскрываются преимущества CAN, требуется и напряжение побольше, для серьезных машинок.
Можно поподробней, какие параметры гонят регули обратно и как их использовать? Пока представляю только 2 применения: диагностика аварийных ситуаций и автоподстройка ПИДов.
Это понятно, но кто будет писать? У меня 6 месяце ушло на понимание принципов получения горизонта от ДУСа и акселя, хотя вроде всё на понятно и примеров море. А чтоб нормальный код регуля написать нужно подробно изучить принципы и теорию работы БК мотора как электромашины (векторы напряжения и тока, скольжение поля и пр., я давно это мимо проходил), описать это коде. Тупой порт открытого (и правильного (!)) кода, а надо ещё найти таковой, может дать только обратку по оборотам, ну и возможно, если схема предусматривает, токам фаз.
Можно поподробней, какие параметры гонят регули обратно и как их использовать? Пока представляю только 2 применения: диагностика аварийных ситуаций и автоподстройка ПИДов.
Какие именно эти регули гонят - не знаю, но принципиально могут возвращать информацию о срыве синхронизации, вращается мотор или нет, какой ток потребляет каждый мотор, с какой частотой вращается мотор и на основании этих данных можно более точно управлять, ловить аварийные ситуации и садиться с частичной потерей двигателей, отключать мотор, застрявший в траве при приземлении и много чего еще. Но это нетривиальная автоматика. Тут требуется серьезная поддержка в полетном контроллере. Я таких полетных контроллеров с открытым кодом не знаю.
А чтоб нормальный код регуля написать нужно подробно изучить принципы и теорию работы БК мотора как электромашины (векторы напряжения и тока, скольжение поля и пр., я давно это мимо проходил), описать это коде. Тупой порт открытого (и правильного (!)) кода, а надо ещё найти таковой, может дать только обратку по оборотам, ну и возможно, если схема предусматривает, токам фаз.
Так софт под этот регуль Open Source, и он доступен, я имел ввиду только добавить поддержку CAN.
Можно поподробней, какие параметры гонят регули обратно и как их использовать? Пока представляю только 2 применения: диагностика аварийных ситуаций и автоподстройка ПИДов.
Так пока нету таких систем, которые бы использовали подобную информацию, вот и ниодин геруль их и не гонит (да и через PWM это невозможно).
На сколько я помню, vis.asta например получал от каждого регуля потребляемый ток, температуру (двигателя? регуля?), обороты. Ну и наверное нештатные ситуации, типа заклинивания.
Даже если контроллер и не будет в состоянии учитывать эту информацию, то ее можно хотя бы в телеметрию пускать (ну и в лог писать). Возможно это поможет в случае краша, разобраться что не так было.
Так пока нету таких систем, которые бы использовали подобную информацию, вот и ниодин геруль их и не гонит (да и через PWM это невозможно).
На сколько я помню, vis.asta например получал от каждого регуля потребляемый ток, температуру (двигателя? регуля?), обороты. Ну и наверное нештатные ситуации, типа заклинивания.
Даже если контроллер и не будет в состоянии учитывать эту информацию, то ее можно хотя бы в телеметрию пускать (ну и в лог писать). Возможно это поможет в случае краша, разобраться что не так было.
Да, Виктор получает довольно много инфы с регулей, они у него как раз на CAN шине. Для телеметрии инфы слишком много - частота работы регуля обычно от 8 кГц. А если писать только события, то ее все равно надо обрабатывать на борту. В любом случае, я не вижу смысла ставить такие регули пока нет готовности с ними работать по полной, иначе слишком дорого, а толку чуть.
Кто нибудь подскажите: как ошибку USART посчитать (%-baudrate) у F303 ??
Начальные условия: кварц-16 Мгц, требуемая частота fCLK - 56 мгц… В даташите таблица есть только под 8-мгц кварц…
Чет похоже у меня проблема с обменом между “камнями” из за этого… (часто зависает).
хмм… насколько помню она считается практически идентично для всех процессоров и является по сути отклонением расчетного значения счетчиков от задаваемого
В даташите таблица есть только под 8-мгц кварц…
А причём тут кварц? всё равно она делится до 1МГц-а какой бы кварц не стоял, и все расчёты делителей скачут уже от этого…
А причём тут кварц?
Example 1
To obtain 9600 baud with fCK = 8 MHz.
● In case of oversampling by 16:
USARTDIV = 8 000 000/9600
BRR[31:0] = USARTDIV = 833d = 0x0341
● In case of oversampling by 8:
USARTDIV = 2 * 8 000 000/9600
USARTDIV = 1666,66 (1667d = 0x683)
BRR[3:0] = 0x3 << 1 = 0x1
BRR = 0x681
Tx/Rx baud
fCK
USARTDIV
-------------------------------= -
Tx/Rx baud
2×fCK
USARTDIV
= --------------------------------
Tx/Rx baud
fCK
USARTDIV
= --------------------------------
Тут еще “оверсамплинг” какой то, короче я запутался…
Error calculation for programmed baud rates at fCK = 72 MHz
for oversampling by 16 and by 8
Baudrate Oversampling by 16 (OVER8 = 0) Oversampling by 8 (OVER8 = 1)
S.No Desired Actual
USART_
BRR value
% Error =
(calculated -
Desired
baudrate)/Desired
Ага в 303 не как в 407 там System Clock берётся от частоты кварца но можно задать частоту i2s Clock - дабы считать ошибки www.st.com/web/en/catalog/tools/PF258143#
но можно задать частоту i2s
это как же(?), мне то usart нужен… ?
видать придется в дебри STD LIB лезть… (а неохота 😃)
Кстати… Сергей… вы таки победили ЮСБ-виртуал компорт?
ато тут столкнулся со статейкой habrahabr.ru/post/165853/ как раз по этой части…
как раз будет куда применить на первое время дискавери платку мне…
Кодятник есть рабочий, и практически внедрён в harakiri надо только правильно его вклинить (если не усб значит усарт), но блин пока мысли в кучу не собрались и первоочередная задача сделать новую плату - “привет pixhawk” так сказать, а тут ещё осенняя тоска заела, надо как-то себя перебороть 😦 да кстати и ненадо на вы 😃
я в порте маховия сделал просто - усб = уарт0 (ну в смысле для остальной прошивки)… остальные уарты - по списку. разница только в том месте где запихиваем в буфер приема и выдаем в буфер передачи…
не так тоже самое, только надо разделить красиво, чтобы переключалось автоматом, скажем если cli я навечно могу повесить на усб, то телеметрию желательно переключать…
хмм… мы сейчас про порт вия разговариваем? так там давно уже с 2.2 версии без разницы куда и что вешать… либо я сейчас туплю
эта фигня генерит system_stm32f3xx.c если что…
так там давно уже с 2.2 версии
ну вот тут не так 😦 и довольно глубоко зарыто… дело в том что сделано то оно под naze32 а там один усарт, а второй переключаемый: либо входа от приёмника, либо gps, либо s.bus, или же спектрумовское извращение…
у меня то драйвер сделан на 3 порта - 1-й телеметрия, 3-й gps, 2-й остальная лабуда…
хммм а в чем проблема?
по сути сделано все довольно просто - вместо одного буфера имеем столько, сколько у нас уартов + инкременируемая переменная для чтения текущего буфера…
наскок помню у меня переделка кода с 2.1 на 2.2 в этом месте заняла не более пары часов
П.С. сам пока отошел от программинга - делаю себе ФПВ шлем на 5.6 матрице 1280х800 (шлем выклеил, жду 28-й день саму матрицу - почта рассеи как всегда тупит) + рисую в солидворке (как раз и его осваиваю) себе складную раму наподобии рамы Сушки
делаю себе ФПВ шлем на 5.6 матрице 1280х800
Чуть подробнее, если можно… (че за матрица)
VGA-HDMI-AV-Audio-Ypbpr-USB-Optional-of-LCDdriver-board-support-5-6-inch-LCD-modules - 120$ за все удовольствия… если быть точным - матрица + контроллер с HDMI/VGA/RCA входом…
потом думаю прикупить андроид стик и впихнуть его в шлем для полного счастья)))) чтоб не ток FPV, но и фильмаки в нем по вайфаю смотреть
сори за ОФФ, нужна помощь зала. Ктонибудь прошивал ардуиновский bootloader в атмеги?
стукнитесь в личку плиз, что бы тут не мусорить - есть пара простых вопросов(не получилось прошить)
Шил ардуиной когдато через LPT
Если комуто интересно - в ардуине бутлоадер можно залить и простым “пять проводков” программатором и STK200 в файле hardware\arduino\programmers.txt нужно прописать
stk200.name=STK200
stk200.protocol=stk200и он появится в меню а самое главное работает…
фьюзы выставляет само проблем небыло…
была когда-то шняга, даже с Кальманутым фильтром сражалась по двум осям:
померла геройски - остатки переехали на STM а часть на работе программатором служит…
всё это где-то в начале темы 😦