1. Введение
Под постобработкой понимается получение навигационного решения по записанным данным (файлу лога) после завершения миссии. Постобработка может помочь в решении следующих задач:
-
верификация качества решения и конфигурационных параметров
-
уточнение конфигурационных параметров
-
получение более точного решения с помощью другого типа алгоритма обработки информации (оптимизация или сглаживание)
Предлагаемый программный пакет позволяет решать эти задачи для системы Acrux путем обработки логов в формате vbp.
2. Установка пакета
Программный пакет предоставляется в виде пакета для языка Python под названием acrux_pp
.
Он содержит компилируемое вычислительное ядро и обвязку на Python.
Компилируемое ядро предоставляется для операционной системы GNU Linux с архитектурой процессора x86-64 и поддерживает версии Python 3.6-3.10.
Также можно использовать Windows Subsystem for Linux (WSL).
Часть функционала не требует вычислительного ядра и может быть использована в любой операционной системе.
Пакет предоставляется в виде специального whl архива, который может быть установлен в помощью менеджера пакетов pip
.
Например для установки в пользовательский каталог:
pip install acrux_pp-0.14.1-py3-none-any.whl --user
Для удаления может быть использована команда
pip uninstall acrux_pp
3. Описание функционала
Пакет предоставляет следующие функции (в пространстве имен acrux_pp
):
-
get_log_info — извлечь информацию из лога (использует компилируемое ядро)
-
postprocess — выполнить постобработку (использует компилируемое ядро)
-
read_messages — прочитать сообщения из лога и представить их в виде таблиц (не использует компилируемое ядро)
Также предоставляется скрипт vbp_to_csv
, который преобразует лог vbp в набор csv файлов.
Функции снабжены строками документации (docstring). В этом руководстве даются неформальные пояснения к их использованию.
3.1. acrux_pp.get_log_info
Функция принимает путь до лога (строку) в бинарном формате (vbp) и выдает объект, содержащий различную информацию о данном логе. Функция полезна, чтобы быстро увидеть какие данные содержались в логе, насколько хорошо принимались сигналы ГНСС, какая использовалась конфигурация и т. д.
Пример использования:
>>> import acrux_pp
>>> from pprint import pprint
>>> log_info = acrux_pp.get_log_info("/home/n/Dev/acrux/nb/car/data/2021-12-29/5.vbp")
>>> print(log_info)
time_span: <class 'tuple'>
utc_span: <class 'tuple'>
duration: <class 'float'>
total_messages: <class 'int'>
message_counts: <class 'list'>
version_string: <class 'str'>
config_commands: <class 'list'>
median_cno: <class 'int'>
dual_antenna_availability: <class 'float'>
>>> pprint(log_info.message_counts)
[('CAN_CONFIG', 2),
('FILE_CONFIG', 2),
('ICOM_CONFIG', 6),
('INTERFACE_MODE', 50),
('LOG', 11),
('NTRIP_CONFIG', 2),
('NTRIP_TIMEOUT', 2),
('SERIAL_CONFIG', 16),
('IMPULSE_CONFIG', 6),
('SET_ROTATION', 2),
('SET_TRANSLATION', 6),
('SET_MOTION_PROFILE', 2),
('DMI_CONFIG', 2),
('VERSION', 2),
('PVA', 346593),
('PVA_SD', 346593),
('DYNAMICS', 346593),
('RAW_SENSOR', 564873),
('DMI', 173058)]
>>> print(log_info.median_cno)
47
>>> print(log_info.dual_antenna_availability)
0.8696130673102904
3.2. acrux_pp.postprocess
Это основная функция, которая запускает постобработку. Функция принимает один аргумент — путь до файла конфигурации в формате YAML и выдает объект, содержащий результаты постобработки. Формат файла конфигурации описывается далее, а в пакете прилагается пример такого файла (ищите его в директории, куда был установлен пакет).
3.2.1. Описание YAML-файла конфигурации
В файле конфигурации определяются следующие поля:
- log_path
-
Путь до файла лога.
- device_serial_number
-
Серийный номер прибора, на котором был записан лог. Этот параметр нужно задавать если в файле лога отсутствует сообщение VERSION и программа не может определить серийный номер автоматически. То есть в большинстве случаев его надо оставить пустым.
- processing_mode
-
Режим обработки. Может принимать одно из четырех значений:
-
forward — стандартная обработка типа фильтра, которая используется в реальном времени
-
backward — обработка типа фильтра, но данные обрабатываются в обратном порядке (из будущего в прошлое). Этот режим обычно не представляет интереса
-
backward_forward — сначала выполняется обработка в обратном порядке, а потом обычная обработка. Это позволяет получить наиболее точное и раннее начальное приближение для алгоритма типа “forward”
-
optimization — обработка типа оптимизации или “сглаживания”, часто именно этот режим понимают под постобработкой. Навигационное решение находится, как решение оптимизационной задачи, в которой учитывается весь массив входных навигационных данных. Алгоритм выполняет множество прямых и обратных проходов, пока не будет достигнута сходимость. Его выполнение требует намного больше времени, чем обработка в трёх предыдущих режимах, а также существенный объем оперативной памяти, пропорциональный длине лога. Для часового лога с полным набором данных (две антенны, одометр, данные RTCM 3 для обеих ГНСС частот) потребуется около 4 гигабайт оперативной памяти.
-
- align_time
-
Выравнивать ли время решения по целой секунде спутникового времени, true или false.
- output_period
-
Период выдачи решения.
- start_time, end_time
-
Начальное и конечное системное время в секундах, между которыми производится обработка данных. Опции могут быть полезны, чтобы исключить части лога при обработке.
- preload_ephemeris
-
Загрузить ли все эфемеридные данные сразу или загружать их последовательно, как это происходит в реальном времени, true или false. Значение true должно давать более точное в среднем решение, а значение false приблизит обработку к режиму реального времени (в режиме “forward”).
- rtcm3_mode
-
Режим использования данных RTCM 3. Может принимать следующие значения:
-
off — не использовать данные. Опция может быть полезна для экспериментов либо, чтобы исключить использование неподходящих данных, записанных в лог
-
on — использовать данные, как в реальном времени, загружая их последовательно
-
preload — загрузить все данные сразу, что уменьшит среднее время рассинхронизации между ровером и базой и может положительно сказаться на работе RTK
-
- rinex
-
Путь до RINEX файла с ГНСС измерениями. Также может быть передан список из нескольких путей. В этом случае будут выбираться данные с ближайшей в данный момент станции (среди тех, где имеются релевантные измерения). Поддерживаются файлы содержащие смешанные (M) измерения (O) версии 3.02, 3.03 и 3.04. Если хотя бы один файл был успешно загружен, то данные RTCM 3 из лога будут игнорироваться. Опция может быть полезна, если данные RTCM 3 не были записаны при работе системы, базовая станция находилась слишком далеко и т. п.
- estimate_imu_ant1
-
Режим оценивания положения главной антенны (ANT1) относительно ИИБ. Может принимать одно из четырех значений:
-
none — не оценивать
-
all — оценивать все компоненты
-
only_xy — оценивать только компоненты x и y
-
auto — использовать “only_xy”, если “processing_mode” равен “optimization”, и “none” в противном случае
-
- output_point
-
Геометрическая точка выдачи решения. Есть четыре варианта задать этот параметр:
-
user — использовать вектор, заданный командой
SET_TRANSLATION IMU_USER
-
imu — выдавать решение в точке ИИБ
-
ant1 — выдавать решение в точке главной антенны
-
список из трех значений [x, y, z] — эквивалентно применению команды
SET_TRANSLATION IMU_USER x y z
-
- use_ext_imu
-
Использовать ли данные внешнего ИИБ, если они имеются в логе, true или false. Если этот параметр выставляется в true, то нужно удостовериться, что навигационная конфигурация соответствует параметрам установки внешнего ИИБ.
- experiments
-
Секция, в которой содержатся параметры позволяющие провести эксперименты с работой алгоритма.
- toggle_gnss
-
Список моментов времени, в которые нужно произвести переключение использования данных ГНСС (с целью моделирования пропажи сигнала). Значения могут быть даны в секундах либо в долях времени лога. Например
toggle_gnss: [100.0, 200.0]
приведет к отключению всех ГНСС измерений на промежутке между 100-ой и 200-ой секундами лога. Аtoggle_gnss: [0.5]
приведет отключению всех ГНСС измерений с середины лога до и конца. - toggle_rtcm3
-
Список моментов времени, в которые нужно произвести переключение использования данных RTCM 3 (с целью моделирования пропажи потока поправок с базовой станции).
- toggle_dmi
-
Список моментов времени, в которых нужно произвести переключение использования одометрических данных.
- optimization
-
Секция, в которой содержатся параметры, управляющие алгоритмом оптимизации. В большинстве случаев менять параметры в ней не требуется.
- max_iterations
-
Максимальное число итераций алгоритма оптимизации.
- adjust_iterations
-
Число итераций на которых происходит переоценка множества корректных измерений и выбросов. После данного числа итераций эти множества фиксируются.
Задание навигационной конфигурации
Параметры навигационной конфигурации для постобработки загружаются из лога путем обработки соответствующих команд. Если данные команды отсутствуют или они не соответствуют желаемой корректной конфигурации, то их можно перезаписать с помощью создания файла commands.txt в директории файла лога. В этом случае команды, содержащиеся в логе, будут полностью игнорироваться, поэтому нужно ничего не забыть. Список команд навигационной конфигурации следующий:
-
SET_MOTION_PROFILE
-
SET_ROTATION VEHICLE_IMU
-
SET_ROTATION VEHICLE_USER
-
SET_TRANSLATION IMU_ANT1
-
SET_TRANSLATION ANT1_ANT2
-
SET_TRANSLATION IMU_DMI
-
SET_TRANSLATION IMU_USER
-
DMI_CONFIG
3.2.2. Описание результата постобработки
Результат постобработки представляет из себя объект, содержащий следующие поля (для обращения к ним используется .):
-
state — таблица типа DataFrame пакета pandas, содержащая оценки навигационных и прочих параметров
-
sd — аналогичная таблица, содержащая оценки точности соответствующих параметров из таблицы state
-
dynamics — таблица типа DataFrame пакета pandas, содержащая угловые скорости и ускорения
-
commands — список команд навигационной конфигурации в консольном формате, которые использовались для запуска алгоритма
-
updated_commands — список команд навигационной конфигурации в консольном формате, содержащие уточненные параметры после обработки данных. Эти команды могут быть введены в прибор для уточнения его конфигурации. Нужно иметь ввиду, что значения СКО выдаются из алгоритма без подстройки и могут оказаться слишком низкими для дальнейшего практического использования. Рекомендуется умножать значения на некоторый фактор около 3, а также использовать инженерную интуицию и не вводить слишком низкие значения
-
state_2, sd_2, dynamics_2 — для режима “optimization” эти поля содержат решение в режиме “backward_forward”, а для других режимов они будут содержать пустые таблицы с таким же набором колонок
-
rtcm3_status — таблица типа DataFrame с информацией об использовании данных RTCM 3 или RINEX. Содержит данные в моменты времени получения ГНСС измерений, когда использовались данные RTCM 3. Включает идентификатор базовой станции (или индекс RINEX файла), её географические координаты, расстояние до неё в метрах, возраст поправок в секундах, число используемых сигналов для различных созвездий (обозначены кодами RINEX) на первой и второй частоте
-
stats — таблица, содержащая статистику по использованным измерениям. Данная таблица может быть использована для оценки корректности и оптимальности работы алгоритма
-
gnss_pvt — таблица, содержащая решение ГНСС премника. Может быть использована для сравнения с решением в state для оценки корректности работы алгоритма
-
config — словарь с прочитанной YAML конфигурацией запуска
Таблицы state и sd индексированы по системному времени и имеют столбцы соответствующие содержанию навигационных логов PVA и PVA_SD, а также некоторые дополнительные параметры:
-
gps_week, gps_second (только в state) — неделя и секунда GPST
-
utc (только в state) — время UTC
-
filter_status (только в state) — статус работы фильтра в виде целого числа
-
position_type (только в state) — тип позиционного решения в виде целого числа
-
lat, lon, alt (в state) и north, east, down (в sd) — широта, долгота в градусах, высота в метрах и их точности в метрах
-
VN, VE, VD — компоненты скорости вдоль географических осей в м/с
-
roll, pitch, heading — углы ориентации в градусах
-
distance — пройденное расстояние в метрах
-
dmi_sf_error - безразмерная ошибка масштабного коэффициента одометрического датчика относительно 1. Уточненный метрический масштабный коэффициент может быть вычислен, как \$hat k = k / (1 + Delta hat k)\$
-
vehicle_imu_misal_y, vehicle_imu_misal_z — углы несоосности в градусах (малые) относительно осей транспортного средства за счет неверного задания
SET_ROTATION VEHICLE_IMU
. Уточненная матрица ориентации между транспортной и приборной системами координат может быть вычислена, как \$hat C = R(hat alpha) C\$, где \$R(hat alpha)\$ — матрица ориентации, соответствующая вектору повороту \$hat alpha = \[(0, hat alpha_y, hat alpha_z)]^T\$ -
imu_ant1_x, imu_ant1_y, imu_ant1_z — положение первой антенны относительно ИИБ в осях транспортного средства в метрах
-
ant1_ant2_elevation, ant1_ant2_azimuth — углы возвышения и азимута вектора между первой и второй антеннами относительно осей транспортного средства в градусах. Уточненные компоненты вектора могут быть вычислены следующим образом \$hat a = l \[(cos hat vartheta cos hat psi, cos hat vartheta sin hat psi, -sin hat psi)]\$, где \$l\$ — длина вектора согласно конфигурации, а \$hat vartheta, hat psi\$ — оценки углов возвышения и азимута соответственно
-
imu_to_car_axis — смещение от ИИБ до фиксированной оси автомобиля в метрах вдоль оси x транспортной системы координат. Присутствует только при использовании профиля движения CAR. Оценка носит вспомогательный и отчасти формальный характер и не предназначена для получения точных геометрических параметров.
Если из-за настроек какие-то параметры в алгоритме не фигурировали (например SET_TRANSLATION ANT1_ANT2
не вводилась), то соответствующих столбцов в таблице не будет.
Таблица dynamics содержит столбцы rate_x, rate_y, rate_z, acc_x, acc_y, acc_z, в которых находятся компоненты угловой скорость в град/сек и ускорения в м/с2, выраженные в осях транспортного средства.
Результат постобработки можно сохранить на диск с помощью использования метода save
, в который нужно передать путь до директории.
3.3. acrux_pp.read_messages
Функция принимает путь до лога (строку) в бинарном формате (vbp) и выдает объект, содержащий таблицы типа DataFrame с содержанием сообщений. Извлекаются следующие типы сообщений:
-
PVA
-
PVA_SD
-
DYNAMICS
-
FULL_SOLUTION
-
PVA_COV
Столбцы в таблицах имеют такие же имена, как и в результатах acrux_pp.postprocess
.
Для сообщений FULL_SOLUTION к параметрам точности добавлен суффикс “_sd”.
3.4. Скрипт vbp_to_csv
Скрипт вызывается следующим образом:
vbp_to_csv /home/me/Data/log.vbp
Результирующие таблицы будут записаны в директорию /home/me/Data/log
.
4. Руководство по анализу логов на пример правильности навигационных настроек
Воспроизводимый пример обработки лога с комментариями в формате "jupyter notebook" можно найти в репозитории по ссылке https://github.com/nmayorov/acrux-pp-tutorial
5. История версий
Версия 0.20.0
-
Добавлена выдача оценки смещения от ИИБ до фиксированной оси автомобиля (imu_to_car_axis) при использования профиля движения CAR
-
Исправлена ошибка, которая препятствовала инициализации алгоритма в режимах "backward" и "optimization" при использовании профиля движения NONE
-
Исправлена ошибка с “падением” обработки в режиме “optimization” в случае переключения базовых станций
-
В результат постобработки поле
updated_config_commands
переименовано вupdated_commands
-
В результат постобработки добавлены поля
commands
,config
, а также возможность сохранения на диск с помощью методаsave
-
В поля
commands
иupdated_commands
записываются все команды, которые определяют навигационную конфигурацию
Версия 0.19.0
-
Исправлена ошибка, когда в режиме "backward" данные RINEX не использовались
-
На 60% уменьшено потребление памяти в режиме "optimization"
Версия 0.18.0
-
Добавлен функционал для чтения vbp логов (не использует компилируемое ядро)
-
Добавлена возможность чтения RINEX файлов с наблюдениями, как замена опции
ext_rtcm3_path
Версия 0.17.0
-
Реализована обработка сообщений типа DMI без известного направления движения
-
Реализована обработка сообщений типа DMI с приращениями пути
-
Улучшена логика выбора базовой станции в режиме
rtcm_mode: ext
, когда предоставляются несколько файлов. Теперь станции без актуальных измерений игнорируются -
В результат postprocess добавлены поля state_2, sd_2, dynamics_2, которые для режима "optimization" содержат результаты в режиме "backward_forward"
-
В результаты postprocess добавлено поле rtcm3_status, которое содержит данные о базовых станциях транслирующих RTCM 3
-
В результаты postprocess добавлено поле stats, которое содержит статистику по использованным измерениям
-
В результаты postprocess добавлено поле gnss_pvt, которое содержит решение ГНСС приемника
Версия 0.16.1
-
Версия от которой будут отсчитываться изменения