Пишем программу для вывода логов формата CSV
На счет прлучения данных в реальном времени, скорей всего будет в другой программе.
Вы меня правильно поймите, для меня это обучение. Со свингом разобрался, буду штурмовать 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, плюс маркеры.
Вдобавок, сегодня открыл программу на ноутбуке и понял, что колёсика то нету, а это единственный способ обратного зума…
А аппа у тебя не Таранис случаем?
Не, Футаба десятка.
Я подумал было бы не плохо для разбора инцидентов совместить инфу от Питлаба и лог из Тараниса… Там есть графики положений всех органов управления…
Не, индивидуально для тараниса как то не очень… Вот если Збигнева попросить добавить логирование положений рулей, тогда да, у всех одно и тоже.
Домучил ветромер… Теперь автоматом просчитываются участки “разворотов” на которых замеряется ветер, как у Питлаба. Если замеров больше одного, создаётся раскладка по высотам. То есть если первый замер на 500м, второй на 1000, то ветер замеренный на 500м, присваивается от 0м до 500м, между 500м и 1000м пересчитывается промежуточные значения обоих замеров, 1000м и выше, присваивается ветер от замера на 1000м.
В лог-таблицу в ячейке ветер, заносится список замеров по высотам. Ну и соответственно, на панели статистики выводится ветер в зависимости от высоты в точке указателя мыши.
Если участков нет, то можно замерить старым способом и просто выбрать участок замера маркерами.
Народ, вопрос на засыпку… Знает ли кто таблички с контрастными цветами? В нете встречал похожее, но не то, так как в тех таблицах, очень много схожих оттенков. Естьли такое, что б допустим вводишь сколько всего нужно цветов, и прога тебе выводит список?
Естьли такое, что б допустим вводишь сколько всего нужно цветов, и прога тебе выводит список?
Так это на лету обычно генерируется. Задаются опорные цвета и между ними путем интерполяции получается сколько надо оттенков.
Достаточно знать принципы создания цвета (RGB…) и помнить, что яркость (сумма всех компонент) с точки зрения восприятия глазом важнее, чем цвет.
Мне нужно подобрать 26 различных цветов, что бы они были различимы. Вот именно, что каждый из 26, должен быть “опорный”, иначе похожие цвета, смотрятся одинаково. То есть, есть стабильный десяток, в котором не ошибёшься, дальше начинаются проблемы.
что каждый из 26, должен быть “опорный”, иначе похожие цвета, смотрятся одинаково.
Основных контрастных цветов всего 6, ну 8 если считать черный и белый. В случае 26 цветов - близкие оттенки неизбежны.
Но глаз все-же будет их различать - главное, чтобы на экране всегда были опорные цвета: или легенду выводить, чтобы можно было визуально сверяться с тем или иными цветом, или чтобы элементы разных цветов располагались рядом, позволяя видеть разницу между близкими оттенками путём сравнения.
Проясните моментик пожалуйста: направление ветра как я понял принято указывать, как не “куда дует”, а “от куда дует”?
То есть если указывается северный ветер, то само направление ветра с севера на юг. Меня немного парит эта неразбериха…
Как удобней показать ветер?
Допустим у меня ветер в градусах… немного муторно, допустим направления ветра 130 градусов… Я бы подумал, что это именно направление ветра, а не откуда дует.