FPV миникоптеры на 250х рамах (ZMR, Blackout, QAV250 и т.п.)
все цвета естественные.
вот пример
У меня так же Swift отдает землю синевой. Похоже это особенность этих камер.
В камере 2DNR лучше выключить - это цифровое шумоподавление, оно мало того что картинку делает менее резкой, так еще и задержку добавляет.
Сине-фиолетовые тени и земля - это скорее проблема оптики объектива, чем камеры - ультрафиолет выходит в видимый спектр.
Меня свифт с ик-фильтром устраивает, вот пример видео с борта, в очках цвета немного ярче и картинка четче.
Попробуй сначала подключиться к UART2: подсоединяете переходник к RX, TX, (+5 , gnd) можно подать туда где регуляторы подключаются. Пробовать соединиться . Потом попробуйте замкнуть boot, потом воткнуть в ПК, выставить настройки в cleanflight(no reboot sequence и.т.д) и попробовать перепрошить.
Ура. Получилось на UART3. Спасибо.
Кому не лень помогите, это вроде пиды, при разворотах квадр поддергивает, на писалке это не очень видно, но вот на курсовой сильно заметно подколбашивает видео с курсовой записать не могу, видео с писалки так что присмотритесь именно при развороте.
Если при резком разворте еще дать хорошо газу то тряска совсем жесть, в общем что уменьшить или увеличить? Кусок видео много времени не отнимет там 20 секунд drive.google.com/file/d/…/view?usp=drivesdk
поднять TPA и возможно прибрать P
Вот так у меня, p по ролл, питч яв снизил до 4 4 и 8.5 все по 0.5, это такой эффект на 3 лопостях на двушках ровно все!
Хочу написать то, что автор прошивки пишет о pid контроллерах
На самом деле больше нет rewrite или luxfloat
они основательно модифицированы и это в реальности что то совсем другое
Для F3 полетника luxfloat (float) по умолчанию, а для F1 это rewrite (int pid)
И при этом они оба работают с одними и теми же данными.
Я ради интереса проверял нагрузку на проц, разница в 1 проц это на уровне стат ошибки.
PS Забыл написать, Борис планирует вообще оставить один, говорит это облегчит ему тестирование прошивок.
Хочу написать то, что автор прошивки пишет о pid контроллерах
[URL=“www.rcgroups.com/forums/showpost.php?p=34975362&po…”]На самом деле больше нет rewrite или luxfloat
они основательно модифицированы и это в реальности что то совсем другое
Для F3 полетника luxfloat (float) по умолчанию, а для F1 это rewrite (int pid)
.
Вы очень много и интересно пишите, но для меня иногда очень сложно, если у меня прошивка betaflight 2.6 1 cc3d, то что мне надо поставить на прошивке 2.8.1 и sprf3? Чтобы был как rewrite? Тоесть чтобы rewrite 2.6.1 был похож на 2.8.1
Добрый вечер. Странно, но в исходниках видно, что реализация rewrite и luxfloat разная.В одном случае int32 в другом float. Вот и думай какой контроллер с каким типом данных быстрее работает. Странно, что замеры показали 1% в любом случае процессор операции сдвига быстрее должен делать чем умножение или деление. А ,на каком контроллере замеряли?
Вот прям недавно кто то писал, что на реврайте 16%, а на люксе 100% загрузка.
Я помню как поставил lux квадр вел себя так кабудто сломаный, его трясло, иногда врубался один мотор на полную остальные же стояли на месте настраивал я его часов 5 так и не настроил, поставив rewrite все заработало сразу! И меня не радует что реврайт на 2.8.1 не реврайт
Смотря какая микросхема там стояла STM32F1… или STM32F3…Если F3, то скорее всего 1%, а если F1,то 16% -100% похоже на правду.
Меня свифт с ик-фильтром устраивает
Swift и так с ИК фильтром на матрице , вы еще один поставили ??? мы пробовали сегодня с Димой Пиранией накрутить оптику с еще одним ик фильтром , но чтото не поняли нифига
Смотря какая микросхема там стояла
Это от прошивки зависит, а не мозга
betaflight:
cliPrintf("System Uptime: %d seconds, Voltage: %d * 0.1V (%dS battery - %s), CPU:%d%%\r\n",
millis() / 1000,
vbat,
batteryCellCount,
getBatteryStateString(),
constrain(averageSystemLoadPercent, 0, 100)
);
Где: constrain(averageSystemLoadPercent, 0, 100)
cleanflight:
cliPrintf("System Uptime: %d seconds, Voltage: %d * 0.1V (%dS battery - %s), System load: %d.%02d\r\n",
millis() / 1000,
vbat,
batteryCellCount,
getBatteryStateString(),
averageSystemLoadPercent / 100,
averageSystemLoadPercent % 100
);
Где: averageSystemLoadPercent / 100, averageSystemLoadPercent % 100
Т.е. от скорости вычислений не зависит загрузка ?!А, зависит от программы ?!Что-то я не совсем понял, что вы имели ввиду.
Там пишется просто вычисленное число из:
averageSystemLoadPercent = 100 * totalWaitingTasks / totalWaitingTasksSamples;
В одном случае оно делится на 100, в другом нет.
Нет, я о другом. Ставим на одной и той же прошивке разные способы реализации вычислений П, И, Д, и смотрим нагрузку на процессор.
Есть еще предложения?
Может уже кто советовал, много страниц, если было, сорри. У меня похожая хрень была в 3D. Как только переворот делал (моторы меняли направление вращения), так крышу у квадра сносило. Еще и регули могли перегрузится. Поставил кондер по питанию на СС3D, 1500 мкф на 6.3 вольтей, как рукой сняло. 😉
Гоночный 250 коптер с толкающим винтом. 130 км/час.
foxtechfpv.com/foxtech-screamer-250-fpv-racing-pen…
В нормальном положении этот винт будет толкать коптер в землю. Я пока не очень понимаю, как они это починили…
Сегодня полетный день окончился падением с 40 метров. Внезапно отказало управление и я в очки наблюдал сначало беспомощьное падение, затем перезагрузку OSD и удар о землю. Видео не писалось но остались логи. По логам видно что питание было в порядке. Однако внезапно rssi начал плавно падать до 0 (в течение одной секунды - фишка tbs crossfire) т.е. питание на приемник приходило. Через 1 секунду включился фейлсейф и на этом падение закончилось. Приемник не отвечал передатчику, хотя питание на него приходило. Пока грешу только на глюк передатчика tbs crossfire с прошивкой 1.20 либо
На аппу Futaba 14sg. Больше мыслей нет.
П.С. удар при падении был такой силы что Аккум превратился из квадрата в ромб, башню Kriger завалило на 30 градусов и она погнула алюминевые стойки и вырвала разъем uart из SPR F3, однако сама башня не сломалась, а вернулась в исходное положение.