Первое с чем столкнется начинающий пользователь при создании проекта с GPS навигацией,
Это добиться точности определения позиции. К примеру модуль BN 357 должен рассчитывать
координаты с точностью +-2м. Но по факту мы в нее не попадаем. Что же мешает этому?
Рассмотрим модуль BN 357,
он выдает координаты вида 114 градусов 1 минута 59768 с 5-ю десятичными знаками от минуты, (пример долготы).
Преобразовываем это в чистые градусы с десятичными долями.
ddd mm.mmmmm=(ddd + mm.mmmmm/60)=ddd.dddddd
Получаем 114.026628
Примерную точность этой координаты можно судить по десятичной части из расчета:
градусы дистанция
1 = 100 км
0.1 = 10 км
0.01 = 1 км
0.001 = 100 м
0.0001 = 10 м
0.00001 = 1 м
0.000001 = 1 дм
Теоретически мы можем добиться точности +-10 см, но практически без, удачного расположения спутников,
хорошего модуля GPS, хорошем состоянии атмосферы, и возможно дополнительных корректирующих наземных станций,
добиться таких результатов не получится.
Но чтобы быть уверенным на 100% в метровой точности,
математические расчеты должны быть с запасом до дециметров (т.е градусы с 6-ю знаками после запятой).
Теперь рассмотрим простой пример проекта навигации на ардуино Уно/Мега в FLProg.
У нас есть сохраненные координаты местности точным поверенным навигатором,
допустим та же долгота 114.026602 градуса. Здесь надо учесть еще одну тонкость.
ДАТУМы (взятых с других модулей или топо-карт) должны быть одинаковые с вашим модулем GPS. Иначе мы даже в сотку не попадем.
В примерах для этого будем использовать координаты, сохраненные этим же модулем.
Но и здесь есть нюансы. Не факт, что состояние атмосферы и расположение спутников в момент снятия данных было наилучшее.
Поэтому для более точных координат точки, надо снимать данные несколько раз, в разное время.
Или оставить на сутки изделие, снимая регулярно показания расстояния и курса, чтобы вычислить среднее значение,
во круг которого будет дрейфовать позиция.
И так, нам надо ввести долготу в проект, что бы ардуина привела нас точно на нее. И вот здесь
первые грабли )
FLProg округляет float до третьего знака. Как бы мы не старались, через константу, переменную, массив,
получаем 114.027 что в данном случае не допустимо.
Остается вариант передавать данные долготы текстом, и конвертировать в float непосредственно перед расчетными блоками.
Но и здесь невезуха точность повысилась всего на один разряд 4 знака.
Тех, кто живет на долготе с однозначным числом градусов, повезет больше,
т.к точность float на 8-ми битных контроллерах ардуино, находится в пределах 7-8ми знаков
(114.0266, считается все число и точка тоже).
Получается мы не можем надеяться на высокую точность навигатора сделанного на Унке.
Возьмем для этих целей ESP32. Все же 32 бита контроллер это не 8.
Проверим что будет получаться на ней. И опять невезуха.
Нужен тип Double, но его нет в FLProg. Придется сделать свой блок конвертора в Double.
Проверяем.
Точность float_Double в esp32.png
Точность float_Double в esp32.flp
И вот оно счастье… теперь можно делать расчеты, не боясь вводить астрономические константы ))
Главное здесь знать, какие блоки, ПБ, и их библиотеки в FLProg могут работать с типом Double,
не то переконвертят опять на float.
Теперь есть с чем сравнивать. Можно вернутся к Унке, и попробовать добиться той же точности.
Возьмем координаты, отделим целую часть от дробной, рассчитаем каждую, и сложим.
Конечно этим мы увеличим и без того нагрузку на проц, но здесь интересна сама возможность этого,
нежели практическое применение. Оказалось, и Унка может с этим справляться. Не так, как esp, но все же.
(пример проекта ниже постом)
Правда говоря при испытаниях результат касаемо точности не был ярко выражен, (те же +-2м как и на esp)
но шаг позиции стал все же мельче, по сравнению с не делимым числом.
Здесь бы сравнить на более точных модулях, но у меня нет таковых.
Вся эта вводная информация – мой путь при создании алгоритма этого блока.
Расписано что бы было понятно почему именно так сделан блок.
Возможно мое видение всего этого в чем-то и ошибочно.
.
. Попробывал залить в уно скетч для калибровки, что то там показал, но в результате уно превратился в полукирпич. Сейчас он, хочет прошивается, хочет нет. Те же скетчи другие унки грузятся нормально. Наверное загрузчик надо перепрошить.