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

Для таких дистанций можно считать Землю плоской и расстояние считать по Пифагору, с учётом того что дельта растояния по долготе зависит от широты.


Мало данных: если у вас PC или Cortex-M4F - можно работать с плавучкой и будет всё равно быстро, если что-то типа PIC16 - то совсем по другому - работать лучше с целыми величинами. Опять же в какое время должен вложится обсчёт?



Ещё момент - нужно ли учитывать что полушария бывают западное и восточное?

Я вот так считаю:


На Cortex-M4F довольно быстро.

Почему через арксинус? Sqrt недостаточно? Или точность выше?

расчет будет проводится на STM32f100.
Вот и я думаю, зачем усложнения в вычислениях косинусами, арксинусами. По сути задача на моё мнение сводится к вычислению гипотенузы в треугольнике. Где гипотенуза искомое расстояние, а катеты, разница между координатами (проэкции на широту и долготу). Учитывая что это все растояния будут не более 500 метров, точность не высокая, даже ошибка в пару метров устроит, то можно все упростить.

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

Давно пользуемся таким методом.

Можно затабулировать с каким-то шагом, например для каждого градуса.

Что за тема?

Гораздо лучше, быстрее и точнее считать расстояния не по географическим, а по прямоугольным координатам. Все GPS-приемники считают в XYZ (относительно центра Земли), но в стандартном NMEA вывод наружу прямоугольных координат не предусмотрен. Приходится переключаться на бинарные протоколы.

Формулы здесь: http://gis-lab.info/qa/great-circles.html Алгоритм проще писать с плавающей точкой. Переписывать с фиксированной IMHO заметный маразм (float работает и на PIC18 но тянет за собой много мат. функций в ПЗУ). Понадобятся: синус и косинус, корень квадратный и atan2 -- всё кордиком (если вручную, с фикс. точкой). Но, повторюсь, маразм, ибо с плавающей может даже быстрей считаться (для фикс. точки разрядность бОльшая).

Если памяти на float нет (double не нужен и медленее, cosf() вместо cos() и т.п.), то остаётся только считать на плоскости. В 16 битах расстояния до ~65км с погрешностью до 500м на больших расстояниях. Понадобятся корень квадратный (32 бита кордиком) и косинус (12 бит кордиком).


Сообщение отредактировал Frolov Kirill - May 1 2013, 12:55

Тема по стояночному дрейфу координат:
http://electronix.ru/forum/index.php?showtopic=96786
Кстати, таки получилось у меня сделать хороший фильтр стояночных звезд. Вкратце: использую очередь с адаптируемым размером, обсчитываю по оригинальному фильтрующему
алгоритму всю группу накопленных в ней точек (фрейм). В итоге подавляет как быстрый, так и медленный дрейф, последовательно приближаясь к средней координате. Но даже при медленном начале движения с маневрами четко фиксирует и выдает начало трека. Вместе с использованием отправки точек по перемещению (тоже адаптируемому) и по повороту дает очень плавный трек без никаких артефактов даже в условиях города (помехи, застройка). А при быстром относительно равномерном движении размер очереди (и латентность фильтра) минимальны.
Проверено на Quectel M12 под OCPU: для его 32bit ARM7 это легкая задача.

Было бы интересно проверить на своем приемнике - не планируете опубликовать ?

Пока нет, к сожалению: алгоритм работает в составе коммерческого софта.

Доброй ночи,
всем пользователям модемов от Телит, предлагается новый сервис M2M Locatе, для определения местоположения модуля по базовым станциям, причем все вычисления проходят на стороне сервиса M2M locate. Более подробно об этом сервисе можно прочитать по ссылке - Telit M2M Locate

Желаю удачи!

А можно поподробнее алгоритм? ТА хоть используется?


Как то даже неконкурентно в сравнении с тем же Quectel: у них все бесплатно и неограниченно...