Создание собственной системы стабилизации
Странно… не знал, ведь в радиосигнале информация не может быть параллельна, как же это они так “измудрились” к одному фронту привязать все каналы, хотя … пути господни…
Это же цифровой сигнал, приходит пакет, приемник его декодирует и выставляет значения каналов, к примеру.
Это же цифровой сигнал.
У меня futaba PCM (типа “цифра”) но импульсы всеж разнесены причем с “зазором”, как и в реале…
Вот rcopen.com/forum/f123/topic264377/49 простая ловилка PWM на tiny 2313 сам сейчас с такой летаю, как пишет автор, там ссылка есть на первоисточник, работает с любыми выходами приёмника…
I have used it without problems with my mikrokopter. It works without skipping frames on my Corona CR8D type 2 receiver (all servo channels output simultaneously). It should work fine on type 1 receivers also (servo channels output sequentially), but I don’t own any so I can’t test it.
действительно, что делать если прерывание следующего канала сработает сразу с завершением фронта предыдущего? как успеть записать значение шима???
Если сделать как у меня, то ничего страшного в этом не будет, я же не сбрасываю значение счетчика. А вот если сбрасывать, тогда да, будут проблемы.
У меня futaba PCM (типа “цифра”) но импульсы всеж разнесены причем с “зазором”, как и в реале…
А зазор какой, сколько есть времени на обработку?
А зазор какой, сколько есть времени на обработку?
0.3 мили/сек
простая ловилка PWM на tiny
Вот, а я еще хочу скажем в RS232 преобразовать (не проблема) тогда прям в USART заливай 16 байт (8х2), ПДП, и вперед…
Провел эксперимент.
Вот сигнал с 3-х каналов приемника.
Аппа Турнига 9х
Как видно, фронт идет сразу по всем каналам.
И сразу назревает проблема.
2 канала я еще более-менее успеваю обрабатывать, а вот уже не 3-х происходит сбой. Счетчик же тикает, пока до 3-го канала добираюсь, половину скважности ШИМ успевает обрезать.
Про 4 канала уже и говорить не хочется…
Значит, по фронту необходимо данные заносить сразу во все 4 канала, а уже по спаду в каждый канал свое значение…
Зато теперь знаю как избавится от слеек, сбрасывать счетчик по фронту. 😃
И сразу назревает проблема.
“Простая задача” оказалась не простой (хорошо, что я плату еще не начал делать), даааа…
Спасибо за эксперимент… (у меня только футабы есть), не знал…
Нашел решение, как обрабатывать все правильно.
Делать надо так:
сначала ловим переход из 0 в 1. Сбрасываем счетчик таймера.
Далее проводим переинициализацию таймера, чтобы он ловил переход из 1 в 0.
Записываем значения. снова проводим перенастройку. чтоб ловил из 0 в 1 и т.д. по кругу.
Таким образом ничего нигде не обрезается и все данные по всем 4-м каналом на 1-м таймере соответствуют действительности.
Плюс к этому избавляемся от переполнения счетчика таймера.
И к 303 камню как раз подходит! 😃
Код нужен ?
“Простая задача” оказалась не простой (хорошо, что я плату еще не начал делать), даааа…
Спасибо за эксперимент… (у меня только футабы есть), не знал…
Возможно для футабы придется писать код отдельно, также как для спектрумов…
Получаем вот такую ровную картину.
Все каналы кроме 3-го в центре, 3-й в минимуме.
Поторопился я, произошла небольшая ошибка.
Данные то считывал не напрямую с приемника, а уже с контроллера.
Напрямую с приемника сигналы выглядят вот так, со смешением. Между спадом и фронтом соседних каналов (величина смещения) 2мкс.
Со сбросом счетчика по фронту прекрасно работает. Значит этот способ будет работать в обоих вариантах, хоть по одному фронту сигналы приходят, хоть со смешением.
Плюс к этому экономим на памяти, так как хранить нужно всего 1 значение, вместо 3-х, как раньше.
В Вашем проекте нашел функции по ДЕинициализации петли ДУСа, каково их применение ?
отключение петли нужно для изменения настройки ДУС штатной функцией Ф3Дисковери.
И еще, я так понял, что для чтения акселя и магнетометра ПДП не применяется (?).
Нет, и2ц замороченный протокол и читается 6 байт, для организации ПДП накладных расходв больше.
произошла небольшая ошибка.
Оно и к лучшему 😃 , я чуть “на измену” не подсел… (рад что все срослось)
Оно и к лучшему 😃 , я чуть “на измену” не подсел… (рад что все срослось)
Да самому неудобно, что напугал зря! 😃
Прям целый детектив получился.
Зато в итоге разобрались как и что, избавились от всех проблем, что были в начале.
Всуну свои пять копее, это если фронт одновременный - сбрасываем счётчик, а по спаду генерим прерывания - по нужному каналу, не сбрасывая счётчик, пока по всем каналам не просмотрим ? а ещё лучше - сброс счётчика по фронту первого канала, и дальше прерывания и по фронту и по тылу, не сбрасывая счётчик до - опять же фронта первого канала, - и расчитать длительноть по каждому, тогда в любом случае сработает? может и глупость сморозил, я сейчас бумажными самолётиками для сына занят, из книжки “От идеи до модели”…
Всуну свои пять копее, это если фронт одновременный - сбрасываем счётчик, а по спаду генерим прерывания - по нужному каналу, не сбрасывая счётчик, пока по всем каналам не просмотрим ? а ещё лучше - сброс счётчика по фронту первого канала, и дальше прерывания и по фронту и по тылу, не сбрасывая счётчик до - опять же фронта первого канала, - и расчитать длительноть по каждому, тогда в любом случае сработает? может и глупость сморозил, я сейчас бумажными самолётиками для сына занят, из книжки “От идеи до модели”…
По первому варианту кода больше. Придется смотреть по всем каналам фронт или не по всем одновременно. Зачем делать лишнее действие?
По второму варианту получаем переполненние счетчика если фронт не одновременный, что ведет к “склейке” 2-х периодов между собой. Тоже не красиво. И также 3 переменные, вместо одной. Плюс к этому лишнее арифметическое действие на вычисление разницы между фронтом и спадом.
А вот когда счетчик сбрасываем по каждому фронту, получается на каждый канал свой счетчик таймера., максимальное значение которого 20000. Таким образом избавляемся от проблемы переполнения, экономим память, решение получается проще и быстрее по времени выполнения, так как значение счетчика сразу запоминаем, ничего вычислять не надо.
Такой вариант работает при любом приходе фронтов, хоть при одновременном, хоть при раздельном.
Код нужен ?
Дайте пожалуйста кусочек, обработчики прерывания только…
Вопрос автору темы: как думаете (знаете) питание на проц. обязательно на все “ноги” VDD разводить на плате ? , что то нигде не могу найти вразумительной инфы про это, на Avr-e вроде и с “одной стороны” работало…
Дайте пожалуйста кусочек, обработчики прерывания только…
Вот такой вот код получается:
"
Timer* timer = Timer::getInstance();
TIM_ICInitTypeDef TIM_ICInitStructure;
if (massTimer[channel].falling == 0)
{
TIMx->CNT = 0;
// Переключаем состояние на противоположное
massTimer[channel].falling = 1;
TIM_ICInitStructure.TIM_ICPolarity = TIM_ICPolarity_Falling; // Захват по спаду
}
else
{
massTimer[channel].capture = capture;
// Переключаем состояние на противоположное
massTimer[channel].falling = 0;
TIM_ICInitStructure.TIM_ICPolarity = TIM_ICPolarity_Rising; // Захват по фронту
}
switch (channel)
{
case CH_1:
TIM_ICInitStructure.TIM_Channel = TIM_Channel_1;
break;
case CH_2:
TIM_ICInitStructure.TIM_Channel = TIM_Channel_2;
break;
case CH_3:
TIM_ICInitStructure.TIM_Channel = TIM_Channel_3;
break;
case CH_4:
TIM_ICInitStructure.TIM_Channel = TIM_Channel_4;
break;
default:
break;
}
TIM_ICInitStructure.TIM_ICSelection = TIM_ICSelection_DirectTI; // Напрямую со входа
TIM_ICInitStructure.TIM_ICPrescaler = TIM_ICPSC_DIV1; // Делитель отключен
TIM_ICInitStructure.TIM_ICFilter = 0x0; // Фильтр отключен
timer->TIM_ICInit(TIMx, &TIM_ICInitStructure);
"
Как с погодой в стране незнаю, у меня солнышко, небольшой ветерок, моя площадка пуста и уже подсохла, так что полетал на мелкоплате, с акселем 😃 - увод имеется (триммирование акселя не помогает) но не смертельный, т.к. жена с дочкой гуляли неподалёку, постоянно отвлекался - коптер никуда не делся - так дрейфует по ветру, ну и как всегда вперёд и вправо, надо доделать квадрик и на нём попробовать, т.к. у трёхи моей уже и рама, и лучи кривоватые стали от многочисленных немягких посадок…
Вот такой вот код получается:
Не забудьте, что Вам придется еще учитывать возможные пропуски прерываний! а то показания “скакать” начнут…
Я передумав кучу вариантов все же остановился на использовании аппаратного режима чтения PWM, проще всего, но пришлось отказаться от 8 и задействовать только 4 (количество свободных счетчиков), а остальные решил на отдельное устройство выводить (все равно они дискретные как правило).
Я у себя немного накосячил, удалил гербер файлы для заказа, сейчас на скорую руку переделал, у кого есть GerbView, проверте пожалуйста, ибо у меня была 30-дневка - кончилась… там обе платы…
Top Layer: pcbname.GTL
Bottom Layer: pcbname.GBL
Solder Mask Top: pcbname.GTS
Solder Mask Bottom: pcbname.GBS
Silk Top: pcbname.GTO
Silk Bottom: pcbname.GBO
Drill Drawing: pcbname.TXT
Не забудьте, что Вам придется еще учитывать возможные пропуски прерываний! а то показания “скакать” начнут…
Я передумав кучу вариантов все же остановился на использовании аппаратного режима чтения PWM, проще всего, но пришлось отказаться от 8 и задействовать только 4 (количество свободных счетчиков), а остальные решил на отдельное устройство выводить (все равно они дискретные как правило).
А что значит пропуски прерываний?
Скорость изменения ШИМ мне кажется физически будет меньше, чем 50 Гц.
Нас ведь интересуют только изменения положения стика управления. Таким образом частоту опроса можно поставить хоть 1 Гц, так что даже если прерывание будет обрабатываться только раз в секунду, ничего страшного не будет.
Я бы с удовольствием его вызывал только при изменении скважности ШИМ, но увы, такого способа нет, во всяком случае программно.
Скорость изменения ШИМ мне кажется физически будет меньше, чем 50 Гц.
Нас ведь интересуют только изменения положения стика управления. Таким образом частоту опроса можно поставить хоть 1 Гц
ничего подобного. например, видели как упраляют 3D вертолетом профессионалы? они стики с такой скоростью дергаю что они их даже не видно становится. и приемники у них выдают частоту шима 70Гц. поэтому про частоту опроса в 1 Гц даже и не думайте, проверено. прием шима - это приоритетная задача, и нужно опрашивать его с той же частотой что и выдается он с приемника. а вот все остальные датчики, баро, компас, джипиэс, можно опрашивать в между делом и то, лучше как минимум в 2Гц.
ничего подобного. например, видели как упраляют 3D вертолетом профессионалы? они стики с такой скоростью дергаю что они их даже не видно становится. и приемники у них выдают частоту шима 70Гц. поэтому про частоту опроса в 1 Гц даже и не думайте, проверено. прием шима - это приоритетная задача, и нужно опрашивать его с той же частотой что и выдается он с приемника. а вот все остальные датчики, баро, компас, джипиэс, можно опрашивать в между делом и то, лучше как минимум в 2Гц.
Ну это я утрированно конечно про 1 Гц, частоту опроса можно подобрать такую, что никаких пропусков не будет и управление вполне плавное. Лично для меня дергать стики даже с частотой 3 Гц управляя коптером как-то не реально… Тем более что при управлении интересует только конечное положение стика, а не весь путь, что он проходит за 0,1 с.
Ну и в конце концов если так хочется, ставь частоту опроса приемника 50 гц (хотя это нафиг не нужно, но если очень хочется, то можно) скорость обработки прерывания позволяет хоть 500 поставить, там инструкций очень мало., обработка занимает точно меньше 0,2 мс
А вот насчет датчиков не согласен, так как раз желательна максимальная частота для сглаживания погрешнойстей измерения. Да тому же Калману чем больше данных скормишь, тем быстрее получишь величину, близкую к истинной, ИМХО.
P.S. И не путайте частоту ШИМ с приемника и частоту изменения ШИМ. Приемник может хоть 400Гц выдавать, это его личгное дело, опрашивать с такой частотой изменение смысла нет абсолютно.