Создание собственной системы стабилизации
мы спорим помоему ни о чём, у меня весь цикл на F103-м занимает 4000 мкс (это с Кальманом и со всякой дребеденью) т.е. какое-то прерывание если и попадёт в шим, то сдвиг на 1-2 мкс (78 - 156 тактов) ну как-то - да приёмник шумит больше…
шанс меньше 0,0001%
Согласен, на практике может и прокатить, но лучше не рисковать…
Оно не исчезнет ессно, но обработается позже согласно приоритетов которые Вы раздадите всем прерываниям, а у Вас импульсы то в реалтайме и ни как не засинхронизированы с другими.
Функция вызванная из прерывания - и является телом прерывания!!!
Все верно!
Но, во-первых сама ошибка ни на что не повлияет, так как на следующей итериции цикла я получу правильное значение.
А главное, переключение фронтов все равно произойдет.
Еще раз говорю, 2 дня назад у меня стабильно каждые 0,4 секунды происходила склейка 2- периодов. То есть частота, выдаваемая на моторы падала до 25 гц, а величина заполнения ШИМ вместо допустим 1500мкс была 3000мкс. Это никак не влияло на поведение моторов.
Так что проблема надуманная. ИМХО.
P.S. Если очень переживаете, ставьте наивысший приоритет да и все.
Читать значения датчиков по прерыванию - не самая лучшая идея
Качество стабилизации , по моему , основная задача а оно зависит в первую очередь от частоты опросы ДУСа, аксель всеравно 50-ти герцовый фактически. Хочу как раз у себя попробовать (этож экперимент!) основноу приоритет отдать ДУСу, а остальные подождут…
вот я тут makefile поломал, ну и как искренне русский теперь бы инструкцию почитать, как они вообще делаются 😃
Качество стабилизации , по моему , основная задача а оно зависит в первую очередь от частоты опросы ДУСа, аксель всеравно 50-ти герцовый фактически. Хочу как раз у себя попробовать (этож экперимент!) основноу приоритет отдать ДУСу, а остальные подождут…
Чтение датчиков занимает кучу времени. Делать это в прерывании - не самая хорошая идея, имхо.
Тем более что ты все равно с ДУСа будешь иметь нектороый шум, который еще надо отфильтровать, и частота у тебя сама собой упадет.
Тут больше важно иметь все показания со всех датчиков одномоментно, то есть производить обноваление показаний с единой частотой для всех датчиков, допустим те же 50Гц.
вот я тут makefile поломал, ну и как искренне русский теперь бы инструкцию почитать, как они вообще делаются 😃
А от чего make ? На чем “сидишь” ?
eclipse gcc Cygwin+maple
- не самая хорошая идея
Это как раз все надо пробовать, “поиграть” -так сказать, все остальное и так как в известных готовых проектах, ограничено “железом”.
Это как раз все надо пробовать, “поиграть” -так сказать, все остальное и так как в известных готовых проектах, ограничено “железом”.
Ну чтож, тогда будет очень любопытно узнать результаты.
eclipse gcc Cygwin+maple
Ууу, ядерная смесь! 😃
Увы, не подскажу, сам на IAR и VisualStudio.
Качество стабилизации , по моему , основная задача а оно зависит в первую очередь от частоты опросы ДУСа
Вы меня не поняли. Читать значения акселя, надо с той частотой, на которую вы его настроили (ну если мы говорим о цифровом сенсоре). Только читать не обязательно сию минуту как пришло прерывание от него, у вас есть время это сделать до следующего прерывания.
Вот примерный алгоритм главного цикла программы
loop {
if (Gyro_ready) {
Read_gyro_data;
new_data_received = true;
}
if (accel_ready) {
Read_accel_data;
new_data_received = true;
}
if (new_data_received) {
Update_DCM; // Обновление алгоритма стабилизации DCM, MARG, CF, EKF ну или что у вас там
Set_Output_PWM; // Выставляем новые значения PWM на моторы
}
... другая работа что у нас еще осталась, например отправить телеметрию
}
Суть сего в том, что в прерывании от Гиры, вы выставляете флаг Gyro_ready и все. Прерывание занимает пару микросекунд времени, в итоге даже если прерывание от гиры, попадет на прерывание от Приемника, вы потеряете пару-тройку микросекунд, что при длине импульса PWM от 1000 до 2000мкс - практически - ничто.
Компилер CodeSourcery ARM EABI (2011.09-69)
это есть, ааа сейчас попробую пересобрать, кажется догнал в чём беда…
No rule to make target `objSTM32/dummy/../AeroQuad32/AeroQuadMain.elf', needed by `elf'. Stop.
нет правила для сборки, блин где ж его найти, патчи настроены всё видится, чего-то ещё не хватает, затык был сначала тут:
LIB_MAPLE_HOME = …/Libmaple/libmaple
убрал лишнюю точку - всё увиделось LIB_MAPLE_HOME = ./Libmaple/libmaple
проверте пожалуйста
сам и проверил на работе всё нормально…
Компилятор начал подавать признаки жизни, но что-то не так 😦
**** Build of configuration Default for project AeroQuad ****
make all
Compiling C: AeroQuad32/MapleCompatibility/flash_stm32.c
Compiling C++: AeroQuad32/AeroQuadMain.cpp
Compiling C++: AeroQuad32/MapleCompatibility/EEPROM.cpp
Compiling C++: Libraries/AQ_I2C/Device_I2C.cpp
Compiling C++: Libraries/AQ_Math/AQMath.cpp
Creating library: Libmaple/libmaple/libmaple.a
arm-none-eabi-ar rcs Libmaple/libmaple/libmaple.a objSTM32/dummy/./AeroQuad32/MapleCompatibility/flash_stm32.o objSTM32/dummy/./AeroQuad32/AeroQuadMain.o objSTM32/dummy/./AeroQuad32/MapleCompatibility/EEPROM.o objSTM32/dummy/./Libraries/AQ_I2C/Device_I2C.o objSTM32/dummy/./Libraries/AQ_Math/AQMath.o
Linking: objSTM32/dummy/./AeroQuad32/AeroQuadMain.elf
arm-none-eabi-gcc: ./Libmaple/libmaple/libmaple/syscalls.o: No such file or directory
rm Libmaple/libmaple/libmaple.a
make: *** [objSTM32/dummy/./AeroQuad32/AeroQuadMain.elf] Error 1
**** Build Finished ****
попробуй либы компильнуть отдельно make -C Libmaple/libmaple library компилится?
сейчас не могу
./Libmaple/libmaple/libmaple/syscalls.с - фаил есть
может здесь Creating library: Libmaple/libmaple/libmaple.a ещё каталог libmaple нужен?
так Libmaple/libmaple/libmaple/libmaple.a ?
к этим
Device_I2C.cpp из ./Libmaple/libmaple/libmaple/ библиотеки цепляются…
может здесь Creating library: Libmaple/libmaple/libmaple.a ещё каталог libmaple нужен?
Не нужен
Device_I2C.cpp из ./Libmaple/libmaple/libmaple/ библиотеки цепляются…
По-моему для компиляции Device_i2C из ./Libmaple/libmaple/libmaple ничего не линкуется
может и не к нему, вечером точно посмотрю…
Чтение датчиков занимает кучу времени. Делать это в прерывании - не самая хорошая идея, имхо.
А вы с какой частотой опрашиваете ШИМ с приемника? И с какой гиро и аксель?
А вы с какой частотой опрашиваете ШИМ с приемника? И с какой гиро и аксель?
Гиру и аксель с максимальной планирую. Данные забирать на обработку по готовности. Пока ни с какой. Но так то каждый цикл желательно. Например, если в МультиВий время цикла 3000 мкс, то получается частота 33Гц примерно.
А ШИМ поступает с приемника с частотой 50Гц. Обрабатывать планирую не чаще 5 Гц. Хотя тоже надо пробовать, как будет сказываться на управлении.
то получается частота 33Гц примерно.
Не 33, а 333Гц
А ШИМ поступает с приемника с частотой 50Гц. Обрабатывать планирую не чаще 5 Гц. Хотя тоже надо пробовать, как будет сказываться на управлении.
я посчитал, с какой скоростью я дергаю стики на 3D самоле, получилось примерно полный размах стика, (от 1мс до 2 мс) проходит где-то за 0,2с. т.е. получается я дергаю стиком с частотой 5Гц в пике. т.е. если опрашивать приемник реже 5 раз в секунду, то можно просто не успеть за стиком. Кароче, сейчас у меня сделано именно опрос приемника с частотой 5Гц, каждые 0.2с, и это очень, очень плохо. машинка вообще не успевает отработать все движения стика.
я думаю надо с максимальной, с частотой самого приемника шим мерить и выдавать наружу. Кто как думает? у кого как сделано?