Пишем программу для вывода логов формата CSV
Да сам затупил малёх, вернее не ожидал такого момента.
Для просчёта ветра, создаю два массива на 360 ячеек. Далее с некоторыми условиями, прохожу по всему логу и суммирую скорости в этот массив в ячейку подходящую под курс .Во второй массив при каждом прибавлении скорости, прибавляю единицу. На выходе два массива, один с “интегрированной” скоростью, другой с счётчиком, так же по каждому курсу. Далее каждую ячейку первого массива, делю на соответствующее значение счётчика, с проверкой на ноль.
В итоге получаю массив с средними скоростями по каждому курсу.
Следующий шаг, выбираю курс с наибольшей скоростью. Так вот на этом этапе, я не мог предположить, что возможен случай, когда в массиве, вообще ни окажется ни одного значения.
Теперь организовал следующую проверку: разбиваю массив на 8 секторов. И в каждом секторе, обязано быть хотя бы одно значение, если нет, то просчёт прерывается и выдаёт нули, что говорит о невозможности определения ветра.
То есть, если максимальная 60км\ч курсом 120, и даже курсом 300 есть значение скорости 50км\ч, это ничего не значит, если в массиве нет хотя бы по одному значению скорости в других секторах (скажем от 0 до 45, 46-90 и тд…), так как может быть самолёт не летал по ветру с условиями по которым, скорость учитывается в изначальной интеграции.
Условия пока следующие: ток ±1А от среднего по всему логу, вертикальная скорость ±0.7м/с. Можно ещё проанализировать угол тангажа и проверить, когда первых двух условий не хватает и пробивается “левое значение скорости”.
Можно пойти путём, которым пошли разрабы Питлаба. То есть можно отслеживать темп изменения курса (то есть частное) и выявить участки, где курс меняется на 360 градусов при одинаковом темпе разворота (можно задать нижний придел этого темпа) и без скачков тока.
Тогда попадание будет сто пудовым. Но это будет работать только на тех логах, на которых пилот совершал такие развороты.
Переделал алгоритм усреднения угловых величин.
То есть раньше усреднение скажем 358 градусов и 2 градуса, давало 180, что бред ядерный. Теперь суммируется как вектор и на примере 358 и 2, даст ответ 0.
Кстати, в последнее время в связи просмотра большого кол-ва всяких логов, заметил одну не понятную мне особенность. Я и раньше замечал, но не придавал особого внимания.
Так вот, летим мы допустим с одинаковым газом и одинаковой воздушной скоростью строго по ветру (наземная при этом равна воздушная +ветер), потом разворачиваемся на 180 и летим с той же воздушной против ветра (наземная при этом равна воздушная - ветер). Но теперь обращаю внимание на тангаж, он же относительный угол атаки (воздушная скорость не поменялась, вертикальная в обеих случаях 0). Так вот почему при полёте ПО ветру, тангаж меньше, чем при полёте против ветра? В обеих случаях воздушка одинаковая, почему меняется тангаж?
Полет по ветру и против - без изменения высоты?
А как тангаж измеряется?
В градусах… Не понял вопроса…
Не понял вопроса…
Не в чём измеряется, а как измеряется. Показания IMU или, ну не знаю, может через траекторию по жыпиэс?
Показания с IMU.
Сейчас думаю, как выводить данные статуса автопилота. Всего два вида: сам статус типа выкл\стаб\авто и параметры навигации, коих много.
Рисовать слова на графике не вариант, так как всё будет сливаться.
Идея следующая: на графике (где ни будь сверху) рисуем широкую полосу . Цвет полоски зависит от статуса: типа красный - выкл, зелёный - стаб, синий - авто. Далее там где параметр навигации поменялся, выводим вертикальную чёрную линию на цветной полосе. То есть будет наглядно видно режим автопилота и где поменяли режим навигации. На панели статистики, добавить окно автопилота и уже там будет видно какая именно навигация, то есть только там будет текстовая информация. Другого решения я не нашёл.
Да, кодировать цветом - нормальный вариант
А тангаж на сколько градусов отличался по ветру и против?
Перепад около 1.5-2 градуса… Единственное, что приходит на ум, низходящие\восходящие потоки помимо ветра и мой Х8 в соответствии куда они дуют, поднимает или опускает нос…
Такс… Как и говорил организовал вывод статуса автопилота и его навигацию.
Малость подкорректирую меню и выложу. Хочу включение\отключение панели статистики и панели с “галками” вывести наружу в виде кнопок.
Шаг следующий, получение информации онлайн через СОМ порт…
Перепад около 1.5-2 градуса.
Так это тупо разные режимы могут быть! Диапазон допустимых углов атаки от 0 до 12 с хвостом градусов. Конечно, не у любого реального самолета можно во всем даиапазоне этих углов нащупать полетные режимы, но перепад в пару градусов - запросто.
PS: а на планшетах и профих моб. устройствах не пробовали запускать?
Нет, не пробовал. Что бы открыть полноценный jar, нужно устанавливать JRE на андроид, что требует рут права и прочий головняк.
Да и как то несуразно swing библиотеку открывать на телефоне…
полноценный jar, нужно устанавливать JRE
Так наверняка есть способы завернуть вместе с ВМ и сделать красивый АПК-шник.
требует рут права …
В чём проблема с рутом? Если честно, вообще не представляю, как будучи хоть чуточку разработчиком (а не просто пользователем) пользоваться андроидом без рута…
Прошу опять простить за занудство. )
На андроиде видел только запуск консольных приложений.
Оконные приложения на андроиде считаю абсурдом.
Если хотим написать на андроид, то нужно изночально на него писать, как вы написали калькулятор .
Никому в голову не приходит, заставить его работать на пк…
Так и здесь библеотека swing чисто оконный вариант.
Оконные приложения на андроиде считаю абсурдом.
Долго ли на полный экран переделать?
Ну, или, точнее здесь надо не от долго/недолго отталкиваться, а от целесообразности: мобильная версия подобных программ крайне интересна, чтобы прямо на полетах можно было информацию лопатить. Далеко не все возят ноут с собой.
Никому в голову не приходит, заставить его работать на пк.
Вы не поверите, оно отлично на десктопе работает 😃 Правда смысла нет, так как под ПК подобных программ навалом и функционал богаче.
На счет прлучения данных в реальном времени, скорей всего будет в другой программе.
Вы меня правильно поймите, для меня это обучение. Со свингом разобрался, буду штурмовать JavaFx.
Там уже аппаратная поддержка и много новых вкусных плюшек.
Правильней было бы на с#, но не хочу прыгать. Хочу изучать языки последовательно.
Я так понимаю для написания на андроид нужно знать язык разметки.
Так же, подобная программа у питлаба на андроид есть и платная. Не хочу никому переходить дорогу.
А так, можно попытаться нарисовать прикольне приборы.
Подумать как выводить 3д глобус… в общем сейчас Остапа понесет.
Пока нет даже начала, все это треп.
Начал изучать библиотеку для работы с сом портами, дальше нужно разбираться с самим питлабом, что именно он шлет.
(опять извиняюсь за оффтоп)
Правильней было бы на с#, но не…
- Все эти языки похожи, что там изучать? Разьве что фрэймворки и библиотеки, чтобы с нуля меньше писать надо было;
- Выбор языка или среды разработки определяется задачами. Но с точки зрения решаемых задач и платформ, особой разницы между явой и шарпом - нет. Очень похожие “звери”.
для написания на андроид нужно знать язык разметки.
Какой еще язык разметки? Смотря на чём писать. Сейчас - эпоха кроссплатформенных инструментов и движков, уже практически никто не изучает что-то, узко специализированное под одну платформу.
Так же, подобная программа у питлаба на андроид есть и платная. Не хочу никому переходить дорогу.
Вот здесь, простите, полная глупость! Рынок софта - это не мафия. Здесь можно и иногда нужно “переходить дорогу” - делая аналоги или даже клоны. Копирование функционала даже под копирайт не попадает.
А так, можно попытаться нарисовать прикольне приборы. Подумать как выводить 3д глобус… в общем сейчас Остапа…
Это же превосходно, когда столько всего хочется! Вспоминаю свои школьные годы- когда хотелось столько всего напрограммировать, но не знал, как… А сейчас - знаю и могу (с определенными затратами времени) сделать практически всё, но не хочу… 😵
Ну для тех кто уже в этом варится, новый язык фигня. Я три месяца назад написал свой привет мир, изза этого, хочу все делать последовательно, у меня и так каша в голове, если начну сейчас по разным языкам мотаться, фигня получится.
Языки разметки, имел в виду XML, смотрел пример, там чел сам алгоритм писал на жаве, а сама оболочка XML.
Или я не то смотрел…?
…у меня и так каша в голове, если начну сейчас по разным языкам…
Так принципы построения программ везде одни и теже, на любых языках. (Кроме разьве что функциональных я.п. но это сильно высокие материи и к практическому программированию отношения не имеют).
Основная разница - в способах ввода и вывода информации (опрос пользовательских событий, работа с файловой системой, работа с графикой, звуком, работа с портами): конкретное использование этих вещей немного отличается, хотя и там есть общие или очень похожие вещи, универсальные между разными языками и средами разработки.
Языки разметки, имел в виду XML, смотрел пример, там чел сам алгоритм…
В андроид студии в смысле? Ну структура проектов там такая. Видимо есть более низкий уровень приложения, который черновую работу делает, и сделали так, чтобы он (этот низкий уровень) в качестве параметров жрал XML-ку.
В любом случае “изучать” - очень громко в данном случае: обычно в XML используют человекопонятные слова, чтобы без объяснений было все понятно, а если какие-то специфичные задачи надо решить (то, что из смотрения в саму XML понять нельзя) - то гуглить примеры, копипастить, но голову не забивать.
Обновлённая версия:
drive.google.com/open?id=0B-tFJd0x5X5xdnFHWV9LZHFP…
По большому счёту добавлен статус бар автопилота, чуток доделан ветро-калькулятор, программа запоминает открыта\закрыта статус панель и панель выбора параметров лога, вроде как вылизал все непонятки с зумом\перетаскиванием, нормальная работа сглаживания угловых величин.
В связи с последними спорами на тему эффективности набора высоты в ветке о самодельных моделях для фпв, появилась следующая мысля:
В добавок к уже имеющемуся графику эффективности и средней эффективности за весь полёт, добавить два курсора, коих можно двигать по графику.
Далее высчитывать среднюю эффективность набора высоты и пройдённой дистанции между этими курсорами. Так же в догонку можно добавить съеденную энергию\ёмкость акка, качество (только на этапах спуска с выключенным мотором). Так же с помощью этих курсоров задавать границы данных для просчёта ветра для большей точности.
Что скажете? Это кому то нужно?
Что скажете? Это кому то нужно?
ИМХО стоит делать любые фичи, какие приходят в голову. Тем более, раз проект для обучения (хотя и для коммерческих такой подход “придумал - реализовал” не чужд).
И можно автоматически разбить всю траекторию на участки - подъёма и спуска (слегка сгладить и определить точки минимумов и максимумом по высоте, между ними и будут участки) - и сразу для каждого участка считать какие-нибудь параметры. Эффективность, качество планирования и т.д.