Краш при выходе из FS-RTL

итак по схеме по порядку:
1) оператор. Мою вину теперь доказать сложно.
2) Подвис пульт, АЦП микроконтроллера рассчитало неправильное значение ( маловероятно, так как канал смены режимов работал исправно )
3) Подвис ВЧ передатчик ( маловероятно, так как канал смены режимов работал исправно )
4) Подвис приемник и в канал газа выдавал значение равное или близкое к 1000 мс, хотя при потере сигнала должен выдавать нуль в канал газа - так настроен сэйфмоде на приемнике ( тоже маловероятно, так как канал смены режимов работал исправно )
5) Подвис ППМ-энкодер и почему-то выдавал значение близкое или равное 1000 мс, хотя он может выдавать либо на прямую либо 900 ( маловероятно, канал смены режимов работал исправно )
6) Подвис микроконтроллер 2560 и неправильно расчитал значение входящего в него канала газа. ( вот тут не знаааююю )

**************

Разгадать данную задачу я не могу.
Но в мое подозрение попадают ВЧ модули ( приемник и передатчик, так как по их вине сработал ФС, который вел коптер на домашнюю точку за минуту до падения )

Свою вину я отрицаю ( хотя, тут нет 100% уверенности в этом )

Аккумулятор точно не при чем, выше постом я уже объяснил почему так думаю.
Плюсом к этому хочу добавить, что если бы это была вина АКБ, то график ThrIn и график желаемой высоты не были бы такими.

**************

ВЧ часть попала под подозрение и после КРАША была протестирована по земле.
Приемник находился на 6 ом этаже а передачик странствовал по двум кварталам в округе. Тестом было выявлено, что во время полета ФС срабатывает неопраданно близко. ( по земле ловит намного лучше и дальше )
Виной тому может быть:
а) напраленная линия передачи 4G, 3G, GSM,WiFi и подобные.
б) особый алгаритм приемника, который начинает выдавать нуль в канал газа при малейшей потере сигнала...

 

я не правильно выразился - пусть будет "баганул" - неправильно расчитал и тп.

Пока установлены сосиски, направленны строго вертикально.
И естественно при тестах я учел диаграмму направленности.
Думаю тут виной направленная передача данных ( 3G, 4G, GSM, WiFi и прочее )
Они на определенной высоте "шумят"

На приемнике у меня настроен "сэйфмоде" ( safemode ), который при потере сигнала в канал газа выдает нуль ( это я так настроил ), для того что-бы правильно сработал Fail Safe в полетном контроллере.
Может быть глюкнул ( ошибка в расчете ) внутри режима SafeMode внутри приемника?
И при этом, переключение режимов естественно работало.

 

Больше всего мне непонятен график заданной высоты.
Почему на нем резкое падение в нуль, затем резкий подъем и плавное снижение?
Если бы я нажал резкое снижение высоты, то на графике, должно было быть резкое падение и все. Подъема графика быть не должно.
Требуется уточнить.
Пожалуй даже нужно проверить на практике.

Подобная проблема - http://forum.rcdesign.ru/f123/thread233564-235.html#post4983927

 

сто раз говорил, что у меня ORANGE OPEN LRS 433 MHz
турниговский давно уже снял

вот посмотрел лог вибраций ( тут видно когда моторы выключились и когда включились )


Выходит, что моторы включились еще в лойтере.
Ничерта не понимаю

 

Не стоит извиняться. Я ни в чем Вас не виню.

1) 1500
2) 1500
3) 0
4) 0
Остальные: заморозить

 

И вот вопрос: как точно апм рисует гпафики ?
На граыике: зеленое throut, красное dalt, а режим stabilize включился после того как заглохли моторы ?
Да ну ?
Наверно просто точка, на гграфик, которая указывает время включения режима, установлена не правильно..

До сих пор ищу возможную причину краша.

 

Ну да, оно последовательно пишет и считывает тоже последовательно. По-другому просто не может быть.
И если вы откроете файл с логами, например, в блокноте и найдете нужную нужное значение - увидите что оно после предыдущего и перед последующим.

 

Успокоил
Чето я сам об этом не подумал...

Какое у Вас умозаключение по поводу этого краша ?
Я уже готов проверить все мыслимые и немыслимые варианты.
Предлагайте. Буду проверять. ( нужно смоделировать подобную ситуацию )

 

А смысл какой ? Что бы FS не сработал? и что бы коптер ваще улетел к чертовой бабушке ?

 

А вот какие:
В полете перед потерей РУ происходит глюк в лоитере

Почему такое может быть?
Мы уменьшаем газ, ПК думает что мы хотим снизиться, но в этот момент происходит какой-то глюк с барометром и его показание растут. Умный ПК решает сбавить обороты, вы видите что коптер падает, даете полный газ, глюк с барометром пропадает, коптер летит ровно в лоитере, потом срабатывает фс и включается ртл. Все логично, все хорошо.
Далее РУ восстанавливается, но не до конца, а периодически (видим на графике красная линия подпрыгивает вверх), но ее хватает что бы включить стаб, но тут же отваливается.
Например, плохой контакт между приемником и АПМ или плохое питание приемника - сигнал вроде бы проскакивает и времени его отсутствия не хватает что бы включить FS, но, в то же время не достаточно что бы ПК понял что вы скоро оторвете стик пытаясь дать полный газ. Вы пытаетесь вернуть управление и щелкаете тумблером, включается лоитер и тут снова (например, от вибраций если плохая пайка) начинает гнать барометр, да и еще газ в минимуме - вот апм обороты то и сбавляет. А потом додумывается что барометр гонит - в логах ошибка баро, но уже поздно.
Что я вижу на графиках:
1. РУ отвалилось но не восстановилось. Проблема скорее всего в РУ. Возможно в месте соединения приемника с АПМ. Возможно питание по 5в нестабильно и т.д.
2. Есть косяк с барометром - или непропай или чего-нить попало или еще какая-нибудь гадость, капризные они.

Я уверен что дело в электронике, а не в ПО. А электроника - наука о контактах.

 

В моем приемнике настроен SafeMode следующим образом:
При потере сигнала приемник выставляет следующие значения на каналах: ( длительность импульса в милисекундах )
1 канал - 1500
2 канал - 1500
3 канал - 0
4 канал - 0
5, 6, 7 и 8 канал - выдает те значения, которые были до потери сигнала ( так называемая "заморозка" )

Далее PPM-энкодер видит, что по каналу газа у ни чего нет и включает инициализацию режима FailSafe.
Для этого он преобразует значения каналов следующим образом:

Далее эти значения поступают в основной чип ( ATMega 2560 )
Основной чип видит, что по каналу газа длительность равна 900мс и включает режим SafeMode.
А уже режим SafeMode включает внутри себя режим RTL, если есть 3D-Fix или LAND, если 3D-fix нету.

 

Я не настраивал сработку FailSafe при разряде батареи.
Проводок с делителя ( с датчика напряжения ) у меня есть, но не подключен.
Ну и соответственно полетный контроллер не знает о состоянии заряда батареи.
Это временная мера. Я просто еще не дошел до этого.

1) а у вас APM или AIOP ???
2) а как Вы организовали ключение FS ? При потере связи приемник сам выдает длительность 900 мс?

 

На графике baro alt - ни какого роста показаний не видно. Я там искал - увы...

В таком случае сработал бы FailSafe еще раз, но он не сработал, более того я смог включить режим LOITER.

У меня каждый канал по своему проводку.
Если проводок с канала газа отключить, то в полетном контроллере сработает FailSafe. *

Это получается что при длительности в 2000мс, полетный контроллер видит только 1000 ( не больше и не меньше )

Приемник питается от стабилизатора ( который в свою очередь изготовлен "по феншую" )
А полетный контроллер питается с контактов приемника.
По логам с питанием все было хорошо.

Покажите где на графике вы видите что РУ не восстановилось?????

Покажите где вы на графике это видите?
А если Вы про ошибку барометра - так это АПМ зафиксировал удар об землю. ( ERRBARO )

Я сам предполагал всего три варианта:

1) Косяк оператора ( речь обо мне ), но я склонен верить, что я невиновен...
2) Вина батарейки или регуляторов, но тут есть неоспоримый факт, подтверждающий обратное это график DALT ( на графике видно0, что желаемая высота упала в нуль и снова резко поднялась. Ни батарейка ни регуляторы не могли внести такую запись в логи )
3) Вина радиоуправления. Тут надо подумать...

 

Типа того, только не 2000мс, а в 1000 раз быстрее. Длительность полезного импульса в серво-PWM примерно 1-2ms Период примерно 20ms - это 50гц.
Что бы сработал FS, значение не должно изменяться в определенном диапазоне в течение какого времени?
Логи пишутся с какой частотой? По-моему она гораздо ниже чем частота выполнения цикла в АПМ. Так что не обязательно мы видим на логах то что происходит на самом деле. Мы видим усредненное значение.