OSD на ATmega1281

Иван

на тесте с мультиком - компас адекватно реагирует?. есть ли варианты в ближайшем доступе другой платки с этими же датчиками? просто, насколько я помню, когда я свою иму паял у меня гир повёрнут по часовой стрелке на 90 гр. и вроде адекват был… может непропай на плате? по ножкам прерываний например?

msv

Иван, тут имхо все чудесатее… Данные то с акселя явно читаются (т.е. по железу претензий не может быть)… Только почему то с жутким смещением, да еще одна ось с инверсией…
Сергей, в файле 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;
}

Но это все какие-то странные костыли…
ЗЫ Креном вправо я назвал поворот по часовой…

korall

Сергей если можно выложите пожалуйста крайний исходник IMU, я то старый какой то ковыряю ,он не совсем корректно с прогой test_imu работает (только с галкой дебаг)

msv:

ЗЫ Креном вправо я назвал поворот по часовой…

Совершенно верно я так и понял

Иван

c чего взяться тут инверсии? если поумочанию сенсоры стоят правильно. помоегу тут кто-то наплате глючит вопрос только кто… может в меге фьюзы не все стоят, может аксель глючный попался? (я свой по торопыжкински даже переполюсовал как то выжил… ) лезть сразу в код при условии что у всех он работает исправно по-моему это последнее дело…

msv

Ок: imu souce.
Там только надо поменять настройку UART, у меня нестандартный кварц.
В режиме дебаг с платы иму передаются исходные данные с сенсоров, расчет ориентации делает сам test_imu.
Иначе плата иму выдает уже рассчитанные углы ориентации и данные о значениях непосредственно с датчиков недоступны… Те. может эти исходники и не нужны…

ubd

Да какой кварц у вас? Я выкладывал прошику которая работает на 16мгц, и программа ТестИМУ тоже была заточена под этот кварц, т.к. передача данных на другой скорости. В общем в архиве было всё под 16 мгц.
В посту 1081, прошивка и программа тест работает на 16 мгц 100 пудов!
rcopen.com/forum/f8/topic162911/1081

Иван

получил у себя нечто похожее с Korall на стадии калибровки после включения питания, если выждать - положить на стол плату иму до получения статус ОК всё пучком:)

korall
ubd:

Да какой кварц у вас? Я выкладывал прошику которая работает на 16мгц, и программа ТестИМУ тоже была заточена под этот кварц, т.к. передача данных на другой скорости. В общем в архиве было всё под 16 мгц. В посту 1081, прошивка и программа тест работает на 16 мгц 100 пудов!

Кварц 16 0000 ,я перепробовал все выложеные в этой ветки прошивки и проги test_imu и их комбинации ,те проши что под кривой кварц сыпят всякий мусор в окне Монитор. я их сразу отмел.Собственно комплект из Вашего архива это было последнее после чего я понял что у меня чтото работает не так (не проходит калибровка)

msv:

В режиме дебаг с платы иму передаются исходные данные с сенсоров, расчет ориентации делает сам 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_offset

return 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 ждал ,не помогло

Иван

у вас “левый” аксель похоже… с инверсными осями…

korall

В общем разобрался как инвертировать гиру, немного по колхозному вышло
но главное что все теперь РАБОТАЕТ как надо

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.
Начинаю собирать ОСД:)

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;
    }
  }
}

Безусловно хорошо, что все хорошо закончилось… Но осадок, что так и непонятна причина такого поведения акселя, остался…

korall

На на скорую руку на макетке собрал ОСД,и теперь задумал прикрутить свой приемник по протоколу LRS, здесь вроде описан протокол rcopen.com/forum/f8/topic162911/1125
но не совсем понятно, хочу уточнить некоторые детали:

  1. AF,50,0B,03, [ ch1,ch2,ch3,ch4,ch5,ch6,ch7,ch8, RSSI,Drop,Valid], CRC так должен выглядить пакет ?
  2. значение канала это 1 байт? 80 ручка в цнтре ?
  3. Флаг валидности (Valid) что должно быть если все ОК?
  4. Количество байт с данными в моем примере ( 0b ) правильно или еще +CRC ?
  5. CRC как считать ,XOR всех данных ?
  6. Для подключения к OSD достаточно отправлять эти данные на PE0(RXD0) (19200,8,n,1) 50 раз в секунду или требуются еще какието соединения?
korall

Почти разобрался, отвечаю сам себе по всем пунктам да ,Valid 1=OK, 0=FS, CRC считается оказывается с количеством байт и типом пакета ( случайно подсмотрел как выглядит пакет от IMU ) а то никак не мог понять почему не работает.
Остался только не понятен параметр Drop ,пробовал отправлять любое число ОСД всё равно показывает ноль (только при включении там пробегают цифры от 128 на уменьшение ) также как и при ППМСУМ подключении, от куда он берется в оригинальной LRS и что означает?

Иван
korall:

На на скорую руку на макетке собрал ОСД,и

на каком проце собрали?

korall

Вы компилировали под 2560 или прям так залили,и что все работает ?

msv
korall:

Остался только не понятен параметр Drop

В текущей версии OSD не использует счетчик Drop от LRS. OSD/AP сам насчитывает дропы по состоянию флага Valid. Те. приемник должен все время гнать пакеты в LRS с периодом ~20ms (по готовности данных или тайм-ауту), указывая в поле Valid=1, если передаются актуальные данные, и Valid=0, если пакет передается приемником по ТА.

Иван
korall:

Вы компилировали под 2560 или прям так залили,и что все работает ?

я пробовал компилить и так вкатывал - всё путём… только вот если пользовать бут который Сергей сделал наверное не всё прокатит, я не пробовал пока:)

там заморочился только когда печатку делал - порты меги 2560 и 1281 чтобы на одни и те же линии подключались там сервы видео… звук…

msv

Подлючил MPXV7002DP, вроде работает, дуешь- скорость какую-то показывает.
Хочу разобраться в теории…
Итак, скорость определяется по известной формуле:
V(км/ч)=3.6*sqrt( 2*P(Па) / R(кг/м^3) );
Принимаем R (плотность воздуха)=1.3кг/м^3, получаем:
V=sqrt( (3.6*3.6*2/1.3)*P )= sqrt( 19,94 * P(Па) );
Чувствительность манометра 1V/1000Па, а 1V=1024/5=204 квантов АЦП (для Vref=5V);
получаем:
V=sqrt( 19,94 * n*(1000/204) )=sqrt( 98 *n); где n - отсчеты АЦП относительно смещения нулевой разницы давлений.
Для нулевой разницы сенсор дает половину напруги, те ~512попугаев АЦП.
(Пока сделал, смещение, соответсвующее нулю, принимается среднее значение получаемое за 4сек после включения АП). Если АЦП насчитает всего на единицу больше (513-512=1) это уже будет соответствовать скорости sqrt(98)=9,9км/ч!
Можно посчитать дальше: 2->14, 3->17, 4->20, 5->22, 6->24, 7->26, 8->28, 9->30, 10->31 итп…
Вообщем с ростом скорости точность быстро возрастает, но меньше 20-30км/ч получается не измерение, а индикация…

ubd

Сергей, я так понимаю, его не нужно калибровать? Просто по даташиту, он работает стандартно 1V на 1000 Па?
А то ещё придётся его на машину крепить и ехать сличая скорость со спидометра и вводя калибровочную константу в КП. Я тогда застрелюсь…