Полетные режимы вашего квадрика и направление на экране аппы
Вкусную плюшку вы придумали, было бы не плохо добавить на экране отображение Hdop GPS . Без этого параметра GPS 3D Fix не о чём не говорит.
Пожеланий и хотелок уже много, поэтому предлагаю сообществу совместно разработать дизайн и состав отображаемых параметров. Все желаемые параметры на одну страницу не войдут, поэтому давайте сделаем еще одну страницу № 6. Для владельцев atmega64 шестая страница, скорее всего, будет отключена. Вот список того, что можно отобразитьpixhawk.ethz.ch/mavlink/#HEARTBEAT (смотрите MAVLink Messages с #0 по #254)
Пожеланий и хотелок
Hdrop и 3D Fix это одини из главных параметров и к хотелкам типа здоровья сенсоров отношения не имеет.
Hdrop и 3D Fix это одини из главных параметров и к хотелкам типа здоровья сенсоров отношения не имеет.
но, насколько я понимаю, они нужны только в предстартовое время, т.к. когда поймали спутники и взлетели, GPS прием уже не должен ухудшится (предполагается полет на открытом пространстве), ухудшение приема GPS после взлета возможно только в случае каких-либо неисправностей (отломилась антенна и висит на проводке, сдох GPS и т.д.)
или у Вас бывает как то по другому?
Я задумывал изначально один экран предстартовый - там все предполетные проверки и один полетный, где отображаются важные для полета параметры.
но, насколько я понимаю, они нужны только в предстартовое время, т.к. когда поймали спутники и взлетели, GPS прием уже не должен ухудшится
Вот тут Вы сильно ошибаетесь, сигнал этот не всегда стабилен. Да и при старте получается это значение на АПЕ не посмотришь.
При высоком Hdop возможен улёт аппарата в Китай (из личного опыта) и не только у меня.
Ну ок, можно сделать и hdop. Вопрос только в том, как все это уместить на нашем маленьком экранчике
Вопрос только в том, как все это уместить на нашем маленьком экранчике
Конечно как Вы и сказали выше было бы не плохо чтобы высказался народ ( у кого какие хателки).
На первой странице экрана отображать самые жизненно необходимые параметры чтобы это было доступно и для atmega 64 и для 128 ,ну а на второй странице отображать все второстепенные параметры без которых можно и прожить, доступно будет только для atmega 128.
Хотелка.
Вид экрана:
12 0v 0A 12.5V 99% ]]]]*
.___
*
20 / 150 A.HOLD 3D 2,5м
где верхняя строка как у Вас,
далее положение точки взлета в середине, коптера и направления его носа относительно взлета - думаю по координатам это не так сложно посчитать, а координаты текущие и во время арма известны. Пусть грубо и упрощенно.
нижняя строка - высота/удаление от старта - режим полета - состояние GPS и HDOP
Положение газа и состояние датчиков - мне лично фиолтеово. Ручку я и так вижу, а датчики подразумеваются исправными, иначе летать идти не стоит.
Ручку я и так вижу
ThrOut показывает не тот уровень, что от аппы, а тот, что от ардупилота. Поясняю: даем газ на полную, переключаемся в режим LAND - газ будет убывать по факту так, как считает нужным ардупилот, вплоть до самого минимума и посадки, независимо от положения стика газа. Также и в других режимах. У меня был случай когда коптер взмывал вверх на минимальном газе (включился geo fence, потому что взял старую home position). Вообще этот параметр один из тех, которые помогут увидеть, быстро сообразить в чем проблема и предотвратить ситуацию, когда ваш коптер полетел в Китай ). А то, обычно в таких случаях, мы понимаем причину уже после потери/краша, потому что в воздухе нужно быстро принимать решения и иногда они бывают неверны. Ну, я пилот неопытный - поэтому пишу свои личные ощущения. У кого рука набита, тому вообще, наверно, никой телеметрии не надо )
То же и со здоровьем датчиков. Попала вода, например, на контроллер или холодная пайка, или еще миллион причин и коптер полетел куда-то неизвестно почему. А если увидел что mag health bad или gps health bad, то уже понятно почему и что делать. Также если здоровье не очень, то и не полетишь. А не зная этого полетишь и потеряешься. В этом же параметре отображается и включение FAILSAFE - поэтому и throut и health я бы оставил на экране.
Удаление от старта пока под вопросом. Отпишусь когда разберусь с этим.
Про направление носа: если квадрат сделать в центре, то по краям остается место, которое можно использовать. Предлагайте, что туда впихать.
Еще вопрос о слабовидящих. Не зря почти вся стандартная телеметрия FrSky сделана крупным шрифтом на страницах 1-4, потому что даже человек со 100% зрением в поле с трудом разглядывает мелкий шрифт. Если проблемы со зрением, то еще сложнее. Давайте подумаем, что сделать крупным шрифтом, а что мелким.
Кстати, для владельцев atmega64, положение носа отображается кратно 15 градусам, для остальных версий отображается более точно (округляется второй знак после запятой в значениях синуса и косинуса)
А если увидел что mag health bad или gps health bad, то уже понятно почему и что делать. Также если здоровье не очень, то и не полетишь. А не зная этого полетишь и потеряешься
Дело в том что в АРМ есть функция (приарм чек) если она включена и вы делаете с пульта арминг при не исправных или не калиброванных датчиках АРМ выдаст сообщение на экран о проблеме и не даст заармить.
Надо изучить детально функции Мишен Планера касающихся режимов управления АРМ
Про PreArm check я, разумеется, в курсе.
Удаление от старта пока под вопросом. Отпишусь когда разберусь с этим.
Посмотрел, как это сделано в коде MinimOSD-extra. Действительно, считается отдельно, но не бог весть как. См. code.google.com/p/minimosd-extra/…/OSD_Func.h , строка 44 //------------------ Home Distance and Direction Calculation ----------------------------------
UPD : откровенно не понял, зачем они пересчитывают длину градуса долготы в каждом цикле :
// shrinking factor for longitude going to poles direction
float rads = fabs(osd_home_lat) * 0.0174532925;
double scaleLongDown = cos(rads);
double scaleLongUp = 1.0f/cos(rads);
Здравствуйте.
Не нашел у нас дешевых ардуин, сделал сам.
Т.к. я использую приемник D8R-II без корпуса, жестко воткнутый в разъемы полетной платы (минус провода, минус разъмы, минус SPPM/SBUS = выше надежность, имхо), то сделал переходник, сразу втыкаемый в приемник.
Вот что получилось 😃
Скомпилировал прошивку (для тараниса), прошил, все работает.
Но есть вопросы.
- Время от включения APM до отображения параметров телеметрии на пульте очень велико - минут 10. Причем полетный режим, напряжение, какой-то Vfas отображаются мгновенно. Спутники ловит тоже почти сразу, так что дело в не спутниках 100%.Иногда вообще так и не начинает показывать телеметрию, кроме режима полета. С чем может быть связано?
- В чем измеряется высота? Загнал квадрик чуть-ли не в тучу - на экране 1,1. 1,1 чего? На уровне 3 этажа дома показывает 0,1.
- Что за параметр Dist? Изменяется от 2700 до 2850. Реагирует на поворот.
- Можно ли как-то увеличить скрость обновления данных телеметрии, хочется четко выдерживать углы поворота коптера, а т.к. задержка большая, смысла в этом не наблюдается.
Да, это все на экране тараниса, на турниге не пробовал еще. Но, думаю, разницы быть не должно - телеметрию же дает переходник в приемник, а не пульт.
Скорее всего что не хватает скорости быстродействия atmega. Какая у вас частота? От контроллера данные приходят со скоростью 57600 (несколько разных параметров примерно 2 раза в секунду, другая часть параметров 5 раз в секунду) по прерыванию. Отправка на frsky со скоростью 9600 происходит “в свободное время”, поэтому может просто не успевает все отправить, т.к. идет активный прием телеметрии от контроллера. В моей версии прошивки это немного оптимизировано, но требования к быстродействию ардуины тоже высоки.
Частота отдачи телеметрии с контроллера на ардуину задается (!) в прошивке ардуины
в файле github.com/vizual54/…/Mavlink.cpp
строка MAVRates[maxStreams] = {0x02, 0x02, 0x05, 0x02, 0x05, 0x02}
где 0x02 - частота 2 Гц, где 0x05 - частота 5 Гц. Что именно отдается долго объяснять (параметры отдаются группами) подробнее смотрите в файлах прошивки контроллера.
Также вам пригодится частота отдачи телеметрии от ардуины к frsky
смотрите github.com/vizual54/…/FrSky.cpp
там есть функции sendFrSky5Hz, sendFrSky1Hz - параметры, которые отдаются с частотой 5Гц и 1Гц соответственно.
Как можете там увидеть курс передается с частотой 1Гц, поэтому да, он бесполезен. Перенесите строку “bufferLength += addBufferData(COURSE, dataProvider);” из функции sendFrSky1Hz в функцию sendFrSky5Hz, еще в функции sendFrSky5Hz уберите строчки про ACCX, ACCY, ACCZ.
Это должно помочь и с быстродействием и с курсом.
Частоту выставил фьюзами как в обычной ардуино -осциллятор на 16 Мгц.
Правда сейчас не помню, убрал ли галочку “делить частоту на 8” - надо проверить.
Еще раз проверил и перепроверил свою платку - вроде все ОК.
На таранисе ведет себя так - режимы полета, напряжения, и VFas изменяются всегда и стабильно.
Количество спутников, координаты и прочее - далеко не всегда. Иногда спутники ловятся уже давно и стабильно - а в телеметрии данных нет.
Сброс телеметрии, сброс платки и мозгов коптера ситуацию не меняют.
Однако. На турниге, прошитой этой спецпрошивкой в это же время, с этой же платой и мозгами, приемником и мозгами все отлично. Перебиндиваю на таранис - координаты не отображаются.
Значит, дело в таранисе?
может достаточно будет просто обновить родную прошивку.
А лучше сразу прошить последнюю OpenTX
Нужна же:
-> Модифицированная прошивка er9x FrSky 812
Нужна же…
у человека две аппы. речь шла о таранисе. схема подключения ардуины и ее прошивка почти одинаковые для турниги и тараниса, если использовать телеметрию FrSky
Нужна же
На турниге все отлично работает.
Таранис чет тупит, то работает, то не работает.
Я дико извинияюсь, если не разобрался. Вот openrcforums.com/…/Er9x_firmware_information есть строка
#ARDUPILOT - used if you have modified your radio to receive ardupilot data
Это про ваш мод как раз ?
PS большое спасибо за проект.