ПО на базе Андроид для пилотов малой авиации.

ИМХО: связываться с российскими разработчиками софта вообще бесполезное занятие - либо стырят, либо денег сдерут.
Есть куча иностранных ресурсов с вольными прогерами - те все делают экономно. А наши кидаловы в 90%.
Имею опыт разработки софта на заказ - постоянно подводили и подводят, все приходится самому делать и тоже подводить заказчиков иногда.
 
ИМХО: связываться с российскими разработчиками софта вообще бесполезное занятие - либо стырят, либо денег сдерут.
Есть куча иностранных ресурсов с вольными прогерами - те все делают экономно. А наши кидаловы в 90%.
Имею опыт разработки софта на заказ - постоянно подводили и подводят, все приходится самому делать и тоже подводить заказчиков иногда.


А что делать? А не настолько силен в английском, чтобы адекватно общаться с иностранными разработчиками.

Есть спецы в английском, которые готовы взять на себя функцию переводчиков? Я даже покажу, в каком месте лучше всего вести переговоры с большими шансами найти нужных программистов. 🙂

Если таковых не окажется - буду дальше мучить голландцев. 🙂
 
defond, а акселерометр с гироскопом задействовать не планируете ? 

Давайте определимся - есть два проекта:

1. Основной - комплекс на основе собственных датчиков, где планшет выступает в качестве монитора.
2. Дополнительный - планшет сам является носителем датчиков

В Основном проекте - да, сделали взаимодействие и гироскопа и акселерометра.

Во втором случае - нет. И тут проблема в размещении самого планшета в кабине - кто-то жестко закрепит, кто-то нет. У кого-то он будет крепиться в кабине, а у кого-то на подвижной поверхности (к примеру мотодельтапланеристы). В случае неправильного крепления устройства ошибок будет очень много. А одного простого метода самостоятельного определения правильности крепления оборудования в самой программе нет, и сделать ее нереально.

Поэтому в простой версии навигатора - нет, не будет. Но мы рассматриваем вариант с подключением дополнительного оборудования. Поэтому в дальнейшем - вполне возможно.
 
А одного простого метода самостоятельного определения правильности крепления оборудования в самой программе нет, и сделать ее нереально.
А как же штатная калибровка датчиков? Вот у меня в планшете эта функция доступна в драйверах.
Установили, откалибровали и в путь...
 
А как же штатная калибровка датчиков? Вот у меня в планшете эта функция доступна в драйверах.
Установили, откалибровали и в путь... 


Девайс подвинулся и опять калибровать? А как быть с накопленной ошибкой?

Нет, штатные датчики для данных целей не подходят. По крайней мере, мы склоняемся именно к такому подходу.
 
А ежели болтами прикрутить к панели чтоб не ёрзал?

🙂 Думали над этим.

ИМХО для встраиваемых можно было бы задействовать и внутренние датчики. 

У стоковых "гироскопов и акселерометров" высокая степень накопления ошибки при небольших отклонениях и непредсказуемая работа от разных моделей планшетов.

В общем выгода от использования стоковых датчиков в расчете на геморрой с кодом, калибровкой, расчетом ошибок и т.п. получается небольшая. Но данное направление тоже рассматривается, если сможем оптимизировать алгоритм до адекватной степени, то конечно будем использовать.

-------

Сейчас бьемся над интерфейсом, чтобы в ближайшие недели хоть что то получить для тестов и с отображением карт в оффлайн (без интернета). Имеется задержка в прорисовке карт из-за большой детализации векторных карт. Сейчас пытаемся понизить детализацию без ущерба для информативности карт.
 
Ясно. Но если Шелезяка укомплектована инерционным датчиком, " гироскопом" и магнитным компасом,
используя альфа-бета фильтр можно получить достаточно качественный резульат.

Имеется задержка в прорисовке карт из-за большой детализации векторных карт. Сейчас пытаемся понизить детализацию без ущерба для информативности карт.
А каковы минимальные требования к железу?
 
А каковы минимальные требования к железу? 


В принципе очень лояльные. У меня на Самсунг Галакси Асе программа работает очень неплохо. Имеется 1-2 секундная задержка прорисовки карт из-за высокой детализации и примерно такая же задержка по динамике изменения параметров (скорость, высота, вариометр).

Для навигации такие задержки не критичны. А вот для пилотирования - очень нехорошо. Поэтому сойчас работаем над снижением уровня детализации, чтобы разгрузить проц.
 
Имеется 1-2 секундная задержка прорисовки карт из-за высокой детализации и примерно такая же задержка по динамике изменения параметров (скорость, высота, вариометр).

Для навигации такие задержки не критичны. А вот для пилотирования - очень нехорошо. Поэтому сойчас работаем над снижением уровня детализации, чтобы разгрузить проц.

Многие бюджетные китаские планшеты мощнее на порядок... 4 ядра что в цпу что в графике уже практически норма. Может стоит ориентироваться на более производительное железо не в ущерб качеству и функционалу? К моменту выхода альфа версии как раз будет актуально. А детализацию лучше сделать настраиваемой "под себя" имхо.
 
Дело не всегда в железе. Первые версии Навитела прекрасно работали на 250Ггц, считали положение с 3х спутников, а сейчас последние версии цепляются минимум за 5 спутников и скорость считают с неприличной погрешностью.
 
Дело не всегда в железе. Первые версии Навитела прекрасно работали на 250Ггц, считали положение с 3х спутников, а сейчас последние версии цепляются минимум за 5 спутников и скорость считают с неприличной погрешностью. 


Абсолютно правы!

Сейчас дело в коде и кол-ве данных. Если объяснить очень просто, то ситуация такая - есть 2 двери (2 процессора), есть 10 человек (10 операций), 1 человек может пройти через 1 дверь за 1 секунду. В итоге потребуется чуть больше 5 секунд, чтобы пропихнуть 10 человек через 2 двери. Больше, потому что вначале (или в процессе) Вам нужно упорядочить человеков и построить 2 очереди.

А теперь представьте, что дверей осталось 2, но человек стало 100. Потребуется уже не 50 секунд. А намного больше, Вам нужно потратить массу времени, чтобы вначале создать 2 очереди. А сам пропуск людей через двери не такая сложная задача.

Очень примерно ситуация выглядит вот так.

И сейчас мы как раз и бьемся над созданием алгоритма очереди. У нас получается, но времени это отнимает очень много.

Чтобы было понятно - данные о том, какие элементы выводить на карту, какого они будут цвета/размера/т.п. - храниться в одном файле. Сейчас там настолько много данных, что уже сама обработка файла с настройками занимает массу времени. И скорость обработки и внесения данных в файл настроек так же снизилась - представьте, что Вам надо в журнале "Наш спорт" заменить все окончания в словах "чка" на окончание "чки". Понятно, что есть структура, где находятся такие слова, но пропуск даже одного окончания приводит к ошибке и не всегда к заметной ошибке.

Буквально пару дней назад основной разработчик принял решение о выделение параметров отображения карты в отдельный файл настройки. Решение здравое и правильное. Но теперь нужно внести изменения в основной код программы, чтобы программа знала, что нужно читать этот файл, а не основной.

Вот так сейчас обстоят дела - пишем, тестим, переписываем, тестим, материмся, опять тестим, материмся еще больше, переписываем, бросаем все нахрен, идем спать... С утра все сначала - пишем, тестим...

Самое главное, что работа идет. Я понимаю, что Вы уже устали ждать, но работа и правда идет. Именно потому, что работа идет, я стал меньше писать в эту ветку.
 
Добрый день.

Извините за долгое молчание, в работе был по уши.

Многие моменты удалось решить, в общем прогноз благоприятный. 🙂

1. По поводу приложения на базе ОС Андроид - я в Java не специалист, поэтому ускорить работу на данный момент не могу. Голландцам я все данные, какие только можно на текущий передал, но повлиять на скорость разработки не могу. Меня уверяют, что данное направление они разрабатывают и подвижки уже есть, но результатов я пока не видел. Поэтому в данном направлении новостей особых нет.

2. По поводу основного комплекса - есть подвижки.

Мы опробовали приложение на базе ОС Виндовс 8, все работает. Поэтому есть вариант, что мы сможем выпустить ПО, которое будет работать на базе планшетов на ОС Вин8 (обычной, не RT).

Есть минус - эти планшеты дорогие по отношению планшетов на базе ОС Андроид.

В данный момент работаем над движком отображения карт.

Вот такие пока новости.

---------------------

В рамках работы над картографическими данными, нужны Ваши советы:

1. Нужно определиться с масштабом карт.

Какой минимальный масштаб нужен? В 1 см - 500 метров? Больше? Меньше?

2. Автомасштабирование карты. Какой масштаб лучше сделать? Меня учили на 1 км высоты смотреть на 10 км вперед. Соответственно рабочее поле должно включать в себя на 1 км высоты 10 км маршрута + 10% на опережение.

Жду Ваших предложений.

3. Жду предложений, по поводу отображаемых объектов на карте. Тропинки и велосипедные дорожки я думаю особо не нужны?

Так же жду Ваших предложений по поводу отображаемых на карте объектов.
 
С масштабом индивидуально. Один летит на дельте, другой на  джете, с одинаковыми прибором. Предлагаю отобразить сбоку ползунок масштаба. Автомасштабирование по желанию, но думаю не нужно.
На максимальном масштабе отражать лучше все. Как то была на Гармине Украинская карта , Аэроскан по моему, там все лесополки и каналы были.
На мелком масштабе все аэронавигационные данные, как на бумажных.
Какой минимальный масштаб нужен?

Зависит от экрана, на 5 дюймов и 100км в см пригодится.
 
По поводу масштаба карты могу рассказать свой опыт применения OziExplorer с топографическими картами. До этого года пользовался Garmin GPS-12, надежной и неутомимой. Весной захотелось красоты и поставил на дельталет автомобильный навигатор с топографическими картами. Предполагалось, что подлетая к лесному массиву по навигатору можно было определить его размеры, сами знаете для чего. Масштаб в 1 см 1 км оказался неудобен - с высоты 300 м я видел дальше, чем показывал навигатор. Масштаб двухкилометровки более подходит, но деталировка топографических карт этого масштаба уже не позволяет уточнить подробности местности.
Выводы. Масштаб 2 км в см для собственно навигации можно определить как самый мелкий. Если будет возможность увеличить карту до 500 м в см для наземной проработки - плюс программе. Масштабом мельче 50 км в см мне пользоваться не придется или крайне редко.
 
Масштаб в 1 см 1 км оказался неудобен - с высоты 300 м я видел дальше, чем показывал навигатор. Масштаб двухкилометровки более подходит, но деталировка топографических карт этого масштаба уже не позволяет уточнить подробности местности.
Выводы. Масштаб 2 км в см для собственно навигации можно определить как самый мелкий. Если будет возможность увеличить карту до 500 м в см для наземной проработки - плюс программе. Масштабом мельче 50 км в см мне пользоваться не придется или крайне редко.

Принял.

-------

Еще бы про топографические объекты рассказали - было бы вообще здорово. 🙂

1. Допустим 300 м. высоты - насколько вперед Вы бы хотели видеть маршрут.

2. Какие топографические объекты на карте нужны? Навигационные данные и иные специальные не берем, только топография и топографические объекты.

Допустим, если важнее дороги, то какой толщины на карты. Если лесные массивы, то насколько ярко выделены.

Аэродромы и авиационные объекты можем не обсуждать, они будут самыми яркими. 🙂
 
Назад
Вверх