Пишем программу для вывода логов формата CSV
Да, кодировать цветом - нормальный вариант
А тангаж на сколько градусов отличался по ветру и против?
Перепад около 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…
По большому счёту добавлен статус бар автопилота, чуток доделан ветро-калькулятор, программа запоминает открыта\закрыта статус панель и панель выбора параметров лога, вроде как вылизал все непонятки с зумом\перетаскиванием, нормальная работа сглаживания угловых величин.
В связи с последними спорами на тему эффективности набора высоты в ветке о самодельных моделях для фпв, появилась следующая мысля:
В добавок к уже имеющемуся графику эффективности и средней эффективности за весь полёт, добавить два курсора, коих можно двигать по графику.
Далее высчитывать среднюю эффективность набора высоты и пройдённой дистанции между этими курсорами. Так же в догонку можно добавить съеденную энергию\ёмкость акка, качество (только на этапах спуска с выключенным мотором). Так же с помощью этих курсоров задавать границы данных для просчёта ветра для большей точности.
Что скажете? Это кому то нужно?
Что скажете? Это кому то нужно?
ИМХО стоит делать любые фичи, какие приходят в голову. Тем более, раз проект для обучения (хотя и для коммерческих такой подход “придумал - реализовал” не чужд).
И можно автоматически разбить всю траекторию на участки - подъёма и спуска (слегка сгладить и определить точки минимумов и максимумом по высоте, между ними и будут участки) - и сразу для каждого участка считать какие-нибудь параметры. Эффективность, качество планирования и т.д.
И можно автоматически разбить всю траекторию на участки - подъёма и спуска (слегка сгладить и определить точки минимумов и максимумом по высоте, между ними и будут участки) - и сразу для каждого участка считать какие-нибудь параметры. Эффективность, качество планирования и т.д.
Тоже так думал… но ничего путного в голову не пришло. Так как в итоге нужно одно значение каждого параметра. А если подходящих участков несколько?
Изначально думал на счёт определения ветра. Но предположим пилот совершил два замерочных круга (Так Питлаб меряет ветер, чем грех не воспользоваться ), один на высоте 1000 метров, другой на 500. На каждой высоте разный ветер.
Какой выводить? А так, пользователь сам решает в каком диапазоне чего искать.
Конечно можно и до списка дойти в котором расписывать все найденные “участки”, но это чересчур заморочено и не наглядно, потребует очередную панель, что ещё больше загромоздит окно программы.
Так как в итоге нужно одно значение каждого параметра. А если подходящих участков несколько?
Правильно - выводить значения отдельно для каждого участка. Поверз гравика можно сектора нарисовать и в каждом секторе подписать параметры для него.
Либо по итогу анализа всех участков, выводить минимальное, максимальное и среднее (правильнее даже среднеквадратичное) значение параметра (три числа).
На каждой высоте разный ветер.
Какой выводить?
По аналогии с предыдущим пунктом.
потребует очередную панель, что ещё бо…
Зачем? Поверх графика рисовать, там же куча незанятного пространства! Подобрать шрифт, цвет, местоположение.
Тут такое дело… что сектор может быть большой, а может и пол минуты. То есть нужно следить за размером и начинать выводить надпись с определённого масштаба по оси Х. Как раз по этой причине, не выводил названия режимов автопилота, а выводил условные обозначения.
Здесь то же самое. Допустим взять программу SeeYou, в ней тоже просчитывается разные этапы и выводится списком в отдельном окошке, что жутко не удобно, плюс ко всему у пользователя завязаны руки и он сам ничего не может проверить, а так же всё дико врёт: ошибка ветра до 90 градусов, качество от -100 до плюс 100 и прочий бред.
Можно сделать некий симбиоз, и фильтровать участки короче определённого времени, плюс считать данные по маркеру.
В любом случае маркеры должны быть. Как бы они уже есть…))
Для просчёта качества считаю “псевдо воздушную скорость” путём вычитания от вектора скорости вектор ветра, как появятся у Питлаба нормальные датчики, удалю это нафиг и буду считать просто с воздушной скоростью. То есть пока, что пользователь если хочет уточнить ветер, выбирает нужный участок, нажимает “просчитать заново ветер”. А для определения качества на нужном этапе, просто выбирает его маркерами и если ток в этом промежутке равен нулю (ну или почти), получает число (нажимать ничего не нужно, пересчёт срабатывает после отпускание кнопки мыши от ползунка маркера).
На счёт автоматизации, нужно ещё раз продумать, что б от этого была реальная польза, а не как в SeeYou - не пришей кобыле хвост.
Это большая тема - называется разработка UI. Самый простой подход - просто брать и пробовать: вывести так, вывести эдак, переделать.
И не забывать, что вывод тех или иных параметров всегда можно отдать на откуп пользователю: менюшка с настройками.
Вроде как нашёл лёгкий и в тоже время на мой взгляд наглядный способ.
В добавок к поиску эффективности подъёма и качеству по маркерам, сделать ещё два графа “моментальных” велечин. Один такой уже есть, который показывает эффективность пути, так будут ещё два. Там где условия будут не подходящими, график просто уйдёт за пределы экрана в верх.
Таким образом, станет наглядно видно где чto, плюс маркеры.
Вдобавок, сегодня открыл программу на ноутбуке и понял, что колёсика то нету, а это единственный способ обратного зума…
А аппа у тебя не Таранис случаем?