Телеметрия (часть 1)
Компилятор CodeW. abs работает коректно.А вот математа не лезет во float а double я так понял чтов МК ничем не отличается от float. А какая у вас математика, просто я пробывал просто по через теорему Пифагора ничего толкогово не получилось.Буду благодарен если поделитесь кодом или хотябы формулами.А растояния я не планирую больше 10 км от место старта.
Компилятор CodeW.
Кодевижн чтоли? Он с плавающей точкой вообще через зад работает…
Переведи вычисления на дабл, должно помочь.
>Гироскопы “включать”, разумеется, не всегда, а по команде с пульта.
Можно. Это избавляет от необходимости постоянной коррекции - состояние в момент включения и есть ноль.
А подробнее можно? Что и где в момент включения есть ноль?
Кодевижн чтоли? Он с плавающей точкой вообще через зад работает…
Переведи вычисления на дабл, должно помочь.
Пробывал таже песня при маленьких расстояниях происходит переполнение.При больших работает как часы.
У цифровых передача информации все равно идет последовательно
Да вот в том-то и дело, что Серж как-то жаловался на НЕ последовательную Футабу ПЦМ номер не вспомню.
Так что самое правильное но быть может не самое дешёвое - взять состояние принятых каналов по UART из хакнутого или самодельного приёмника типа Вад64, и туда же в приёмник отдать состояние выходных каналов по тому-же UART.
Но это так - мечты/мечты.
А использовать не дешёвые бортовые гиры для стабилизации модельки (особенно такой как верт) по 3м осям в нормальном полёте очень даже не помешает и полёт по камере могет значительно облегчить. Хотя математически и тут всё не так уж и просто, особенно если делать ПИ(Д) алгоритмы - я что-то плохо себе представляю, как будет лететь самаль, которому задали крен 30 градусов и кабрирование 1 градус, он же будет иметь угловую скорость вокруг вертикальной оси к примеру, при этом хвост станет пытаться эту скорость убрать и сохранять первоначальный азимут полёта. Что будет дальше - не представляю, но наверняка придётся сводить команды самалю к высоко уровневым согласованным манёврам. Потому как взаимо проникновение каналов гир будет ещё и через полётные свойства модели идти.
Насчёт фьюзов через флип…
Вот ссылочка на соответсвующий документ: www.atmel.com/dyn/resources/…/doc7769.pdf.
На странице 12, п. 7 FAQs, читаем 3-ий вопрос-ответ:
- Can I modify the fuse bits using Flip?
• No, Flip cannot modify the fuse bits. To modify the fuse bit you can use either the JTAG ICE
MKII, the AVRISP MKII, or parallel programming.
>3. Can I modify the fuse bits using Flip?
>• No, Flip cannot modify the fuse bits. To modify the fuse bit you can use either the JTAG ICE
>MKII, the AVRISP MKII, or parallel programming.
Да, я это уже успел увидеть. Ну, пока дефолтное состояние фьюзов меня устраивает.
Компилятор CodeW. abs работает коректно.А вот математа не лезет во float а double я так понял чтов МК ничем не отличается от float. А какая у вас математика, просто я пробывал просто по через теорему Пифагора ничего толкогово не получилось.Буду благодарен если поделитесь кодом или хотябы формулами.А растояния я не планирую больше 10 км от место старта.
Устраиваем систему координат на плоскости в точке старта так: ось Х - с запада на восток, ось Y - с юга на север.
Расстояния от базы до самика по этим осям будет равно:
DX ~ Rземли*(разница долгот между стартом и самиком выраженная в радианах)*cos(широта точки старта)
DY ~ Rземли*(разница широт между стартом и самиком выраженная в радианах)
При этом используется известный факт, что для маленьких углов a
sin(a) ~ tg(a) ~ a
Дальше считайте азимуты как Вам угодно 😃
Так что самое правильное но быть может не самое дешёвое - взять состояние принятых каналов по UART из хакнутого или самодельного приёмника типа Вад64, и туда же в приёмник отдать состояние выходных каналов по тому-же UART.
Но это так - мечты/мечты.
Я давно предлагаю Тимофею свои доработки мультиплексовских приемников (именно для этого), но он пока не хочет… 😛
Добавлю свои три копейки по гироскопам в каналах управления эроплана. Пробовал вкорячивать вертолётную гиру по очереди на все каналы. На крен и тангаж очень полезно-летит как по рельсам даже в ветер.А вот на хвост противопоказано-при полёте с небольшим креном модель поворачивает в сторону крена а хвост пытается противодействовать этому. В результате модель начинает лететь со всё большим боковым скольжением и увеличивающимся креном, теряет скорость и управляемость и валится в штопор. Единственная полезность от гиры на хвосте-хорошее удержание курса при пробежке по земле, но после взлёта нужно отключать.
С уважением.
>А вот на хвост противопоказано-при полёте с небольшим креном модель поворачивает в сторону крена а хвост пытается противодействовать этому.
+1
Тоже думал об этом, но не так живо представлял себе поведение модели. Ну и отлично, мне же меньше работы будет 😃
Гуру, простите. Пошел убиваться об стену. Надо читать доки: оказывается, специально для таких идиотов, как я, у Атмеги128 есть специально обученные ноги в количестве 8 штук, которые могут генерить прерывания при изменении состояния на входе.
Впрочем, эти ноги частично пересекаются по функциям с SPI, так что вопрос остается в силе. Впрочем, атмега128 и USART свой в режиме SPI может использовать. Пойду всё-таки искать подходящую стену.
Ну вот типа: например. Из моего декодера PPM. Использует ICP. Если по каналам, я использовал “подключатель” на hct125d- лишний драйвер тоже не помешает, для выравнивания фронтов. Что касается самих импульсов, я думаю, что если с контроллера выводятся напрямую к машинкам(в приемнике)- то одновременно стартуют…(все включил, по счетчику отключил)
[codebox]
//////////////////////////////////////////////////////////////
#define PULSEZ 32
#define RC_SEQ_PRESENT 0
#define RC_SEQ_ACKQ 1
#define TURN_LED_ON PORTB|=_BV(LED_0)
#define TURN_LED_OFF PORTB&=~_BV(LED_0)
volatile uint16_t MeasuredIcpz[PULSEZ*2], RcvdData[8], cntz;
uint8_t ChnlCnt, SYS_LOGIC_BITS, pulse_Piece;
//////////////////////////////////////////////////////////////
void InitCapture (void) {
cli();
TCCR1B=0;
TCNT1=0;
TCCR1B |=_BV(CS11) |_BV(ICES1);// Период измерения равен 8*65536/XTAL
TIMSK |=_BV(TICIE1) |_BV(TOIE1);
sei();
}
ISR (TIMER1_CAPT_vect){
TCCR1B&=~_BV(CS11);//стоп таймер
TCNT1=0; //счетчик в ноль
if (bit_is_clear(TCCR1B,ICES1)) TCCR1B|=_BV(ICES1);// переключаем полярность срабатывания
else TCCR1B&=~_BV(ICES1);
TCCR1B|=_BV(CS11);// таймер старт
if (ICR1<5555) {// мин. значение длительности на которое следует реагировать (для JR при кварце 12mhz в моем случае)
//TURN_LED_OFF;
SYS_LOGIC_BITS|=_BV(RC_SEQ_PRESENT); // последовательность присутствует!
MeasuredIcpz[pulse_Piece]=ICR1;// сохраняем все данные???
if (MeasuredIcpz[pulse_Piece]>777) {// канальный синхро ~550 не нужен
///////////////////////////////////////////////////////
RcvdData[ChnlCnt]=(RcvdData[ChnlCnt]+MeasuredIcpz[pulse_Piece])>>1;// усредняем???
///////////////////////////////////////////////////////
if (ChnlCnt++>=7) ChnlCnt=7;// сохраняем 8 каналов
}
if (pulse_Piece++==(PULSEZ*2)-1) pulse_Piece=0;
} else {
cntz=pulse_Piece;
ChnlCnt=0;
pulse_Piece=0;
SYS_LOGIC_BITS|=_BV(RC_SEQ_ACKQ);// если больше 5555 - посылка принята!
}
}
ISR (TIMER1_OVF_vect){// при переполнении таймера сбрасываем бит наличия и счетчики
cntz=pulse_Piece;
pulse_Piece=0;
SYS_LOGIC_BITS&=~_BV(RC_SEQ_PRESENT);
SYS_LOGIC_BITS&=~_BV(RC_SEQ_ACKQ);
//TURN_LED_ON;
}
[/codebox]
Типа, вот. просто и понятно. Работает шикарно. Input Capture Noise Canceler -не пробовал, за ненадобностью
MeasuredIcpz и cntz можно выкинуть
Мужики спасибо.Мне както даже стыдно в сложных расчетах разобрался а на простых завис.
Теперь мой простенький автопилот работает.
А подробнее можно? Что и где в момент включения есть ноль?
Текущее положение есть ноль. Его автопилот и поддерживает дальше.
Вот ссылочка на соответсвующий документ: www.atmel.com/dyn/resources/…/doc7769.pdf.
На странице 12, п. 7 FAQs, читаем 3-ий вопрос-ответ:
Да, я нашёл уже.
В принципе, так и есть - бутлодер работает внутри чипа, а запись фьюзов из приложения невозможна.
Мой программер работает через ISP, посему ему пофиг.
Впрочем, кроме делителя на 8, который можно подправить из софта, и маленького периода вачдога, котрый от туда же правится, претензий к фьюзам нет.
Коллеги, на плате автопилота не предполагается делать какое-то меню настроек, кнопки и т.д. Все настройки - с компука, через USB.
Это приемлемо?
Сейчас еще есть время подумать и решить, надо ли настройки кнопками на плате и экранное меню поверх видеосигнала, или не надо.
И еще вопрос: а где лучше хранить собственно пользовательские настройки автопилота, телеметрии и т.д.? В EEPROM Атмеги или во внешней памяти?
С одной стороны заманчиво подстраивать автопилот пямо в поле кнопками, поглядывая через очки в меню. А с другой стороны, не усложнит ли это конструкцию?
У меня вот другое немного предложение: а не замутить ли простенькую систему автослежения для патч антенки приемника, как пан-титл у камеры? Чтоб антенка сама доворачивалась по максимуму сигнала.
С одной стороны заманчиво подстраивать автопилот пямо в поле кнопками, поглядывая через очки в меню. А с другой стороны, не усложнит ли это конструкцию?
Как программист могу сказать точно - написать код, отвечающий за отрисовку и функционал меню (меню сразу должно подразумевать многоуровневость) очень просто.
Т.е. сейчас меню - функция желательная, но не обязательная (а через пол-года год вполне может стать очень и очень нужной).
Если здесь демократия и можно голосовать, 😃 то я “за” меню.
У меня вот другое немного предложение: а не замутить ли простенькую систему автослежения для патч антенки приемника, как пан-титл у камеры? Чтоб антенка сама доворачивалась по максимуму сигнала.
Если по максимуму сигнала, то антенна должна непрерывно “мотать головой”, чтобы этот самый максимум искать…
Такую систему делал еще год назад какой-то гаврик на rc-groups (точную ссылку навскидку не дам, но найти несложно). Однако, насколько я помню, для нормальной работы этой системы ему пришлось добавалять детектор корректности принимаемой синхры, потому как “максимум rss” и “лучшая картинка” - это не всегда одно и то же.
Я же собирался делать антенный привод, ориентирующийся по координатам (благо gps все равно летает, а значит есть и стартовая позиция и текущая, и высота), так что, единственное, что нужно сделать - это передать “вниз” текущие координаты в цифре… Нашел открытый проект подходящего радиомодема и даже прикупил под азимутальный привод недорогую “яхтенную” 360-градусную серву, но вот времени на реализацию пока не хватает.
Коллеги, на плате автопилота не предполагается делать какое-то меню настроек, кнопки и т.д. Все настройки - с компука, через USB.
Это приемлемо?
Да, но тогда необходимо таскать с собой комп обязательно.
Сейчас еще есть время подумать и решить, надо ли настройки кнопками на плате и экранное меню поверх видеосигнала, или не надо.
Меню - это звучит вкусно. И комп не надо таскать с собой. Вместо кнопок предлагаю использовать квадратурный энкодер с интегрированной кнопкой. Очень удобная штука для навигации по меню (для подключения необходима одна ножка с внешним прерыванием по перепаду и одна без оного + одна на кнопку). Но, может быть, навигацию по меню попробовать осуществить при помощи передатчика? (аналогично переключению размеров шрифта).
И еще вопрос: а где лучше хранить собственно пользовательские настройки автопилота, телеметрии и т.д.? В EEPROM Атмеги или во внешней памяти?
Если на данный момент памяти достаточно и есть, например, двукратный запас по объёму (“на вырост”), то, имхо, в меге. В противном же случае - во внешней.
И еще вопрос: а где лучше хранить собственно пользовательские настройки автопилота, телеметрии и т.д.? В EEPROM Атмеги или во внешней памяти?
Епрома меги хватит за глаза.
Коллеги, на плате автопилота не предполагается делать какое-то меню настроек, кнопки и т.д. Все настройки - с компука, через USB.
Это приемлемо?
Я за меню через очки. Джойстик на кее есть, купить такой же для будующей платы элементарно.
Просто ноутбук есть не у всех, а памяти в меге просто валом. У меня меню, писаное под 51-й, занимает 2 кб, причём в проге только интерпретатор, а само меню находится во внешней епромке.
Там массив структур. Первые 8 байт - коды сегментов (у меня там дисплей). 9-й байт - способ отображения (сколько сегментов высвечивать тупо, сколько засвечивать преобразоваными числами и т.д., перебирается свитчем). Ну и далее по 2 байта на кнопку. Action и NextItem. То бишь что сделать и куда потом пойти по нажатию этой кнопки. Action аналогично выбирается свитчем из нескольких вариантов (инкрементировать переменную по адрезу Х, декрементировать, сбросить или ничего не делать…).
Очень удобно - один интерпретатор, а туда можно забивать сколько угодно итемов и хранить их где угодно. Это стандарт для МКашного применения, так ещё на Z80 писали, где память внешняя была. Могу скинуть свои и немецкие менюшки для примера, но они под Кейл 51-х.