OSD на ATmega1281
Может проц поменять? Раз с той и с этой платой датчиков крутится моделька. А проц то один. Такое ощущение что наводиться что то на АЦП…
старая версия была сделана на макетке соответственно там и проц(еще из старых партий без буквы А) и кварц и сама плата были другими, питается все это у меня от USB порта ноутбука, но пробовал и от акумулятора через КРЕНку,по тыкал осцилографам в места питания сенсоров и проца,возбуждений и генераций вроде не обнаружил.
Попробуйте такой test_imu.
Вот как то так:
Попробовал дла проверки прицепить эти сенсоры к MultiWii, так там все с ними работает.
Ничего не понимаю ,чертовщина какая то:wacko:
Явно с осями какая-то путаница… Сергей а прошивку сами компилировали или готовую заливали?
Попробуйте эту.
Если ничего не измениться, добавлю вывод данных акселя, будем разбираться…
Те что на видео залиты готовые. Сам пробовал компилировать старую версию ,все работало одинаково.
Попробуйте эту. Если ничего не измениться, добавлю вывод данных акселя, будем разбираться…
нет никаких изменений.
Ок. Продолжаем разговор…
Грузите это: test_imu.
Добавил вывод акселя по осям.
В горизонте должны быть цифры: 0, 0, 100.
Нос- широкая сторона платы с разъемами, если смотрим с хвоста на нос правый крен: 0,100,0
Кабрирование 90град: 100, 0, 0.
Верх платы сенсоры вверху?
В горизонте : -126, -20, 630
Правый крен:-126, -136, 530
Левый крен: -130, 91, 530
Кабрирование: -240, -22, 530
Пикирование: -10, -20, 520
в горизонте кверх ногами: -126, -25, 420
Это вот с этой прошивкой
Попробуйте эту.
Да, сенсоры вверху.
Готов сдаться…
Вверх ногами в горизонте?
отредактировал предыдущий пост добавил показания вверх ногами.
По тесту вроде как оси правильно расположены, только показания смещены от нуля сильно по X и Z.
Может можно в настройки добавить параметр смещения (типа ручной коректеровки нуля) ?
А вот сдаватся не надо, на Вас вся надежда
Вот в доках на ADXL 345 что то про смещение:
это не оно случаем?
Получше рассмотрел свои цифры ,оказалось что ось Y в инверсии еще в добавок.
Добавил в код
if(err) return err;
err=TWI_SendByte(ADXL345_ADDRESS<<1, 0x1e, 0x4f); //Х_offset
if(err) return err;
err=TWI_SendByte(ADXL345_ADDRESS<<1, 0x1f, 0x10); //Y_offset
if(err) return err;
err=TWI_SendByte(ADXL345_ADDRESS<<1, 0x20, 0x80); //Z_offset
по Z не хватает расхода чтобы дотянуть до нуля 😦
и незнаю как инвертировать ось Y
теперь в тесте стало так :
В горизонте : 0, 0, 430
Правый крен:0, -100, 320
Левый крен: 0, 110, 320
Кабрирование: -110, 0, 320
Пикирование:110, 0, 320
в горизонте кверх ногами: 0, 0, 220
на тесте с мультиком - компас адекватно реагирует?. есть ли варианты в ближайшем доступе другой платки с этими же датчиками? просто, насколько я помню, когда я свою иму паял у меня гир повёрнут по часовой стрелке на 90 гр. и вроде адекват был… может непропай на плате? по ножкам прерываний например?
Иван, тут имхо все чудесатее… Данные то с акселя явно читаются (т.е. по железу претензий не может быть)… Только почему то с жутким смещением, да еще одна ось с инверсией…
Сергей, в файле sensors.c можно переписать функцию
#define ADX345_OFFSET_X 0 //Задать смещение!!
#define ADX345_OFFSET_Y 0 //Задать смещение!!
#define ADX345_OFFSET_Z 0 //Задать смещение!!
u_char ADXL345_GetData(void)
{
float fv;
u_char err;
s_int buff[3];
err=TWI_RecData(ADXL345_ADDRESS<<1, 0x32, (u_char *)buff, 6);
if(err) return err;
fv=(float)buff[0];
gSensorData.Accel[0]=(fv/gCnfData.K_AccelGravity)-ADX345_OFFSET_X;
fv=(float)buff[1];
gSensorData.Accel[1]=-((fv/gCnfData.K_AccelGravity)-ADX345_OFFSET_Y); // invert Y!!!!
fv=(float)buff[2];
gSensorData.Accel[2]=(fv/gCnfData.K_AccelGravity)-ADX345_OFFSET_Z;
return 0;
}
Но это все какие-то странные костыли…
ЗЫ Креном вправо я назвал поворот по часовой…
Сергей если можно выложите пожалуйста крайний исходник IMU, я то старый какой то ковыряю ,он не совсем корректно с прогой test_imu работает (только с галкой дебаг)
ЗЫ Креном вправо я назвал поворот по часовой…
Совершенно верно я так и понял
c чего взяться тут инверсии? если поумочанию сенсоры стоят правильно. помоегу тут кто-то наплате глючит вопрос только кто… может в меге фьюзы не все стоят, может аксель глючный попался? (я свой по торопыжкински даже переполюсовал как то выжил… ) лезть сразу в код при условии что у всех он работает исправно по-моему это последнее дело…
Ок: imu souce.
Там только надо поменять настройку UART, у меня нестандартный кварц.
В режиме дебаг с платы иму передаются исходные данные с сенсоров, расчет ориентации делает сам test_imu.
Иначе плата иму выдает уже рассчитанные углы ориентации и данные о значениях непосредственно с датчиков недоступны… Те. может эти исходники и не нужны…
Да какой кварц у вас? Я выкладывал прошику которая работает на 16мгц, и программа ТестИМУ тоже была заточена под этот кварц, т.к. передача данных на другой скорости. В общем в архиве было всё под 16 мгц.
В посту 1081, прошивка и программа тест работает на 16 мгц 100 пудов!
rcopen.com/forum/f8/topic162911/1081
получил у себя нечто похожее с Korall на стадии калибровки после включения питания, если выждать - положить на стол плату иму до получения статус ОК всё пучком:)
Да какой кварц у вас? Я выкладывал прошику которая работает на 16мгц, и программа ТестИМУ тоже была заточена под этот кварц, т.к. передача данных на другой скорости. В общем в архиве было всё под 16 мгц. В посту 1081, прошивка и программа тест работает на 16 мгц 100 пудов!
Кварц 16 0000 ,я перепробовал все выложеные в этой ветки прошивки и проги test_imu и их комбинации ,те проши что под кривой кварц сыпят всякий мусор в окне Монитор. я их сразу отмел.Собственно комплект из Вашего архива это было последнее после чего я понял что у меня чтото работает не так (не проходит калибровка)
В режиме дебаг с платы иму передаются исходные данные с сенсоров, расчет ориентации делает сам test_imu. Иначе плата иму выдает уже рассчитанные углы ориентации и данные о значениях непосредственно с датчиков недоступны…
Может конечно в теории так и должно быть но по факту некоторые ранние версии test_imu полноценно работают только с ранними версиями прошивки, а с новыми начинают крутить квадрат только с галкой дебаг и при этом не читаются и не пишутся настройки,но в общем то теперь это уже не важно.
Похоже уже виден свет в конце тонеля , внес в код такие изменения :
if(err) return err;
err=TWI_SendByte(ADXL345_ADDRESS<<1, 0x1e, 0x4f); //Х_offset
if(err) return err;
err=TWI_SendByte(ADXL345_ADDRESS<<1, 0x1f, 0x10); //Y_offset
if(err) return err;
err=TWI_SendByte(ADXL345_ADDRESS<<1, 0x20, 0xf1); //Z_offsetreturn err;
}
//---------------------------------------------------------------------------------------------------
#define ADX345_OFFSET_X 0 //Задать смещение!!
#define ADX345_OFFSET_Y 0 //Задать смещение!!
#define ADX345_OFFSET_Z 5 //Задать смещение!!u_char ADXL345_GetData(void)
{
float fv;
u_char err;
s_int buff[3];err=TWI_RecData(ADXL345_ADDRESS<<1, 0x32, (u_char *)buff, 6);
if(err) return err;
fv=(float)buff[0];
gSensorData.Accel[0]=-((fv/gCnfData.K_AccelGravity)-ADX345_OFFSET_X); // invert X!!!
fv=(float)buff[1];
gSensorData.Accel[1]=-((fv/gCnfData.K_AccelGravity)-ADX345_OFFSET_Y); // invert Y!!!
fv=(float)buff[2];
gSensorData.Accel[2]=(fv/gCnfData.K_AccelGravity)-ADX345_OFFSET_Z;
return 0;
}
И УРА квадрат перестал плыть и ИМУ стала проходить калибровку, только теперь квадрат в режиме Accsel test наклоняется правильно , а в стандартном инвертированно по крену и тангажу ,а по курсу правильно.
Сергей msv подскажите где теперь это можно в коде подправить или достаточно просто развернуть плату на 180 покурсу (широкая сторона с разъемом станет хвостом)?
получил у себя нечто похожее с Korall на стадии калибровки после включения питания, если выждать - положить на стол плату иму до получения статус ОК всё пучком
я часа 2 ждал ,не помогло
у вас “левый” аксель похоже… с инверсными осями…
В общем разобрался как инвертировать гиру, немного по колхозному вышло
но главное что все теперь РАБОТАЕТ как надо
err=TWI_RecData(ITG3205_ADDRESS<<1, 29, buff, 6);
if(err) return err;
for(i=0, j=0; i<2; i++, j+=2)
{
da.ch[1]=buff[j];
da.ch[0]=(u_char)buff[j+1];
if(!f_calc) raw_buff[i]=da.i;
else
{
raw_buff[i]+=da.i;
fv=(float)raw_buff[i];
gSensorData.Gyro[i]=-(fv*gCnfData.K_GyroGain); // // invert X Y !!!
}
}
for(i=2, j=4; i<3; i++, j+=2)
{
da.ch[1]=buff[j];
da.ch[0]=(u_char)buff[j+1];
if(!f_calc) raw_buff[i]=da.i;
else
{
raw_buff[i]+=da.i;
fv=(float)raw_buff[i];
gSensorData.Gyro[i]=fv*gCnfData.K_GyroGain;
}
}
Огромное СПАСИБО всем помогавшим в особенности автору проекта Сергею msv.
Начинаю собирать ОСД:)
Ваш код уж очень хочется “причесать”:
for(i=0, j=0; i<2; i++, j+=2)
{
[1]=buff[j];
[0]=(u_char)buff[j+1];
if(!f_calc) raw_buff[i]=da.i;
else
{
raw_buff[i]+=da.i;
fv=(float)raw_buff[i];
if(i<2) fv=-fv; // invert X Y !!!!
gSensorData.Gyro[i]=fv*gCnfData.K_GyroGain;
}
}
}
Безусловно хорошо, что все хорошо закончилось… Но осадок, что так и непонятна причина такого поведения акселя, остался…
На на скорую руку на макетке собрал ОСД,и теперь задумал прикрутить свой приемник по протоколу LRS, здесь вроде описан протокол rcopen.com/forum/f8/topic162911/1125
но не совсем понятно, хочу уточнить некоторые детали:
- AF,50,0B,03, [ ch1,ch2,ch3,ch4,ch5,ch6,ch7,ch8, RSSI,Drop,Valid], CRC так должен выглядить пакет ?
- значение канала это 1 байт? 80 ручка в цнтре ?
- Флаг валидности (Valid) что должно быть если все ОК?
- Количество байт с данными в моем примере ( 0b ) правильно или еще +CRC ?
- CRC как считать ,XOR всех данных ?
- Для подключения к OSD достаточно отправлять эти данные на PE0(RXD0) (19200,8,n,1) 50 раз в секунду или требуются еще какието соединения?
Почти разобрался, отвечаю сам себе по всем пунктам да ,Valid 1=OK, 0=FS, CRC считается оказывается с количеством байт и типом пакета ( случайно подсмотрел как выглядит пакет от IMU ) а то никак не мог понять почему не работает.
Остался только не понятен параметр Drop ,пробовал отправлять любое число ОСД всё равно показывает ноль (только при включении там пробегают цифры от 128 на уменьшение ) также как и при ППМСУМ подключении, от куда он берется в оригинальной LRS и что означает?