High gps hdop


Предварительная проверка безопасности перед снятием с охраны Pre-Arm

Предварительная проверка безопасности при снятии с охраны (Pre-arm Check)

APM с прошивкой 3.0.1 (и выше) включает в себя предварительную проверку безопасности при снятии с охраны, которая приводит к тому, что одна из проблем была выявленна:

  • Проверяет, что была выполнена калибровка Радио.
  • Проверяет, что была выполнена калибровка акселерометра.
  • Проверяет, что компас здоровый и правильно передает данные.
  • Проверяет, что смещение компасе не слишком большое (т.е. корень SQRT (х ^ 2 + у ^ 2 + Z ^ 2)
  • Проверяет, что калибровка на живую компаса или на базе журналирования была выполнена или что "COMPASS_LEARN" включен.
  • Проверяет адекватное напряжение магнитного поля: (APM1/APM2 около 330, PX4/Pixhawk около 530)
  • Проверяет, что барометр здоровый и правильно обменивается данными.
  • Если круговая ограда (Fence) включена или снимаете с охраны в режиме Loiter проверка безопасности проверяет, что:
    • у вас есть фиксация спутников по GPS
    • параметр GPS HDOP
  • Путевая скорость меньше 50 см / сек
  • Проверяет, что полетный контроллер питается между 4,5 и 5,5 вольт для АРМ 1 или АРМ 2
  • Проверяет, что 7 и 8 канал не настроен на управление на одну и ту же функцию.
  • Если включен Radio FailSafe проверяет минимальное значение стика газа канала не ниже FS_THR_VALUE
  • Проверяет параметр ANGLE_MAX (т.е. максимальный угол наклонав большинстве режимов) является больше 10 и меньше 80 градусов
  • Проверяет уровень PWM по четырем первым каналам , если они меньше 1300 и не больше 1700

Если все остальное нормально, за исключением того, когда вы пытаетесь снять с охраны (Arming) стиком газа вниз и вправо (режим Mode2 на аппаратуре), он будет на самом деле не сниматься с охраны и двигатели не будут вращаться он, вероятно, не прошел проверку Pre-Arm безопасности. Вы должны заметить, что красный светодиод будет мигать двумя быстрыми вспышками по кругу.

Видео с подробным описанием Pre-Arm safety check

Отключение Pre-Arm Safety Check

Если вы уверены, что проверка на сбок не настоящая проблема вы можете отключить её:

  • Подключение APM к Mission Planer
  • Зайдите в раздел Config/Tuning -> Standart Params
  • установитe Pre-Arm Check на значение "Disabled" или, если вы используете AC3.1 (или выше), вы можете пропустить этот пункт, который вызывает сбой.
  • Нажмите кнопку "Write Params"

В идеале вы должны определить причину сбоя Pre-Arm, и если она может быть решена, верните этот параметр к исходному положению - "Enabled"

Чтобы понять, что вызвало сбой Pre-Arm Check:

  • Подключите свой полетный контроллер к компьютеру через порт USB.
  • Запустите Mission Planner и соединитесь с ArduPilot нажав кнопку "Connect" в правом верхнем углу.
  • Включите аппаратуру радиопередатчика и удерживайте стик газа вниз и вправо (процедура постановки на охрану - Disarm).
  • Первый причиной проверки отказа Pre-Arm безопасности будет отображаться красным цветом в окне HUD Mission Planner.
  • Каждая проблема и адрес будет сообщаться при попытке снять с охраны, как указано выше.
  • Когда все проблемы были исправлены, вы увидите проверку "снятия с охраны" (Pre-Arm Check) в окне HUD.
  • После этого можно отключить от компьютера и имеють хорошую гарантию того, что снятие с охраны (arming) будет происходить в обычном режиме.

Устранение проблем предварительной проверки снятия с охраны (Pre-arm fix):

  • Если не прошла проверка Радио rалибровки - сделайте повторно калибровку радио .
  • Если не прошла проверка калибровки акселерометра - сделайте повторно калибровку акселерометра .
  • Если происходит сбой компаса - сделайте заново живую калибровку компаса .
  • Если проверка барометра (высотомера) не работает, то ваш контроллер скорее всего имеет аппаратную проблему с барометром.
  • Если проверка позиция GPS не удалась
    • ждать HDOP вашего GPS, чтобы он опустился ниже 2.0, прежде чем пытаться снимать с охраны. Вы можете сделать это более легко - наблюдая в области быстрого экрана Mission Planner.
    • Отключите Geofence в Config/Тюнинг -> Geofence
    • Снимите с охраны (arming) в полетный режим Стабилизации (Stabilize mode) и позже перейдите в режим Loiter (этот режим (loiter) не рекомендуется на момент старта, потому что хорошая фиксация по спутникам GPS требуется для Loiter и HDOP является хорошим показателем того, что GPS позиция хороша)
    • увеличить параметр GPS_HDOP_GOOD от 200 до 250 (это также не рекомендуется по тем же причинам, что и выше)
  • Если проверка напряжения питания полетного контроллера не успешная:
    • проверить UBEC , который используется для подачи напряжения на АРМ напряжение должно быть между 4,5 и 5,5 вольт (чем ближе к 5V, тем лучше)
    • проверить, если какие-либо периферийные устройства, которые питаются от АРМ и имеют слишком высокий потребляемый ток.
  • Если на канал 7 и 8 было установлено тоже самое (одинаковая функция) измените один из них с помощью Mission Planner Config/Тюнинг -> PIDS

ardupilot-mega.ru

Pre-Arm Safety Check — Copter documentation

Copter includes a suite of Pre-arm Safety Checks which will prevent the vehicle from arming if any of a fairly large number of issues are discovered before take-off including missed calibration, configuration or bad sensor data. These checks help prevent crashes and fly-aways but they can also be disabled if necessary.

Recognising which Pre-Arm Check has failed using the GCS

The pilot will notice a pre-arm check failure because he/she will be unable to arm the copter and the LED will be flashing yellow. To determine exactly which check has failed:

  1. Connect the Flight Controller to the ground station using a USB cable or Telemetry.
  2. Ensure the GCS is connected to the vehicle (i.e. on Mission Plannerand push the “Connect” button on the upper right).
  3. Turn on your radio transmitter and attempt to arm the vehicle (regular procedure using throttle down, yaw right)
  4. The first cause of the Pre-Arm Check failure will be displayed in red on the HUD window

Failure messages

RC failures (i.e. transmitter/receiver failures):

RC not calibrated : the radio calibration has not been performed. RC3_MIN and RC3_MAX must have been changed from their default values (1100 and 1900) and for channels 1 to 4, the MIN must be less than 1300 and the MAX greater than 1700.

Barometer failures:

Baro not healthy : the barometer sensor is reporting that it is unhealthy which is normally a sign of a hardware failure.

Alt disparity : the barometer altitude disagrees with the inertial navigation (i.e. Baro + Accelerometer) altitude estimate by more than 2 meters. This message is normally short-lived and can occur when the flight controller is first plugged in or if it receives a hard jolt (i.e. dropped suddenly). If it does not clear the accelerometers may need to be calibrated or there may be a barometer hardware issue.

Compass failures:

Compass not healthy : the compass sensor is reporting that it is unhealthy which is a sign of a hardware failure.

Compass not calibrated : the compass(es) has not been calibrated. the COMPASS_OFS_X, Y, Z parameters are zero or the number or type of compasses connected has been changed since the last compass calibration was performed.

Compass offsets too high : the primary compass’s offsets length (i.e. sqrt(x^2+y^2+z^2)) are larger than 500. This can be caused by metal objects being placed too close to the compass. If only an internal compass is being used (not recommended), it may simply be the metal in the board that is causing the large offsets and this may not actually be a problem in which case you may wish to disable the compass check.

Check mag field : the sensed magnetic field in the area is 35% higher or lower than the expected value. The expected length is 530 so it’s > 874 or < 185. Magnetic field strength varies around the world but these wide limits mean it’s more likely the compass calibration has not calculated good offsets and should be repeated.

Compasses inconsistent : the internal and external compasses are pointing in different directions (off by >45 degrees). This is normally caused by the external compasses orientation (i.e. COMPASS_ORIENT parameter) being set incorrectly.

GPS related failures:

GPS Glitch : the GPS is glitching and the vehicle is in a flight mode that requires GPS (i.e. Loiter, PosHold, etc) and/or the circular fence is enabled.

Need 3D Fix : the GPS does not have a 3D fix and the vehicle is in a flight mode that requires the GPS and/or the circular fence is enabled.

Bad Velocity : the vehicle’s velocity (according to inertial navigation system) is above 50cm/s. Issues that could lead to this include the vehicle actually moving or being dropped, bad accelerometer calibration, GPS updating at below the expected 5hz.

High GPS HDOP : the GPS’s HDOP value (a measure of the position accuracy) is above 2.0 and the vehicle is in a flight mode that requires GPS and/or the circular fence is enabled. This may be resolved by simply waiting a few minutes, moving to a location with a better view of the sky or checking sources of GPS interference (i.e. FPV equipment) are moved further from the GPS. Alternatively the check can be relaxed by increasing the GPS_HDOP_GOOD parameter to 2.2 or 2.5. Worst case the pilot may disable the fence and take-off in a mode that does not require the GPS (i.e. Stabilize, AltHold) and switch into Loiter after arming but this is not recommended.

Note: the GPS HDOP can be readily viewed through the Mission Planner’s Quick tab as shown below.

INS checks (i.e. Acclerometer and Gyro checks):

INS not calibrated: some or all of the accelerometer’s offsets are zero. The accelerometers need to be calibrated.

Accels not healthy: one of the accelerometers is reporting it is not healthy which could be a hardware issue. This can also occur immediately after a firmware update before the board has been restarted.

Accels inconsistent: the accelerometers are reporting accelerations which are different by at least 1m/s/s. The accelerometers need to be re-calibrated or there is a hardware issue.

Gyros not healthy: one of the gyroscopes is reporting it is unhealthy which is likely a hardware issue. This can also occur immediately after a firmware update before the board has been restarted.

Gyro cal failed: the gyro calibration failed to capture offsets. This is most often caused by the vehicle being moved during the gyro calibration (when red and blue lights are flashing) in which case unplugging the battery and plugging it in again while being careful not to jostle the vehicle will likely resolve the issue. Sensors hardware failures (i.e. spikes) can also cause this failure.

Gyros inconsistent: two gyroscopes are reporting vehicle rotation rates that differ by more than 20deg/sec. This is likely a hardware failure or caused by a bad gyro calibration.

Board Voltage checks:

Check Board Voltage: the board’s internal voltage is below 4.3 Volts or above 5.8 Volts.

If powered through a USB cable (i.e. while on the bench) this can be caused by the desktop computer being unable to provide sufficient current to the flight controller - try replacing the USB cable.

If powered from a battery this is a serious problem and the power system (i.e. Power Module, battery, etc) should be carefully checked before flying.

Parameter checks:

Ch7&Ch8 Opt cannot be same: Auxiliary Function Switches are set to the same option which is not permitted because it could lead to confusion.

Check FS_THR_VALUE: the radio failsafe pwm value has been set too close to the throttle channels (i.e. ch4) minimum.

Check ANGLE_MAX: the ANGLE_MAX parameter which controls the vehicle’s maximum lean angle has been set below 10 degrees (i.e. 1000) or above 80 degrees (i.e. 8000).

ACRO_BAL_ROLL/PITCH: the ACRO_BAL_ROLL parameter is higher than the Stabilize Roll P and/or ACRO_BAL_PITCH parameter is higher than the Stabilize Pitch P value. This could lead to the pilot being unable to control the lean angle in ACRO mode because the Acro Trainer stabilization would overpower the pilot’s input.

ardupilot.org

High HDOP values when flying IRIS

In the IRIS forums at DIYDronres, Ardupilot, and the IRIS Facebook group I have seen reports from various users who have complained about low HDOP (Horizontal Dilution of precision) reported by their IRIS when trying to arm in Loiter or Auto mode (Both are GPS assisted modes). In these cases the HDOP value determined and reported by Arducopter is higher than 2.0 after powering up IRIS. This value is higher than the default value of 2.0 for the GPS_HDOP_GOOD paramter value. As a result the pre-arm checks fail and IRIS is not able to arm in a GPS-assisted flight mode.

I’m facing this situation in probably 8-9 out of 10 flights. Yet, when arming IRIS and taking off manually in Stabilize mode I’m able to switch into Loiter mode right after takeoff. While the HDOP value reported by IRIS via DroidPlanner2 would still be above 2.0, the vehicle does not show any negative performance with regards to GPS. In fact IRIS would remain in position quite well within a 1m x 1m x 1m or even smaller “box” in the sky. There is no twitching or leaving this very precise location.So what could be the reason between the GPS module on IRIS actually working pretty well and the reported “quality” number being so low?

Finding the underlying bug

I did a lot of digging – and I mean a lot of digging – and even thought about replacing my 3DR GPS module that only supports GPS with a module that also supports GLONASS, BeiDou and Galileo. The added number of satellites – especially from GLONASS – should result in lower HDOP values.

And then I stumbled over the Ardupilot bug #644. It states that the value reported back from the GPS module for HDOP isn’t actually HDOP but PDOP (Position (3D) Dilution of precision). So what? Isn’t that close enough. Turns out, it’s not!

How does HDOP and PDOP differ?

Let’s use the tool http://satpredictor.navcomtech.com/ and determine the expected xDOP values for the location of the 3DR Berkeley office based on a 10 degree elevation mask. This means that satellites below a 10 degree angle are not visible due to trees, building or mountains (See Figure 1). It is the default value for the above tool and a reasonable assumption.

Figure 1: The concept of an elevation mask

Let’s have a look and the predicted xDOP values for the above location on Friday, September 12th 2014 (See Figure 2). Any other date or location will yield similar results.

Figure 2: xDOP values in Berkeley, CA

We can see a very interesting result:You can see the values for HDOP – shown in grey at the bottom. That’s the values that our autopilot in IRIS believes it is receiving from the GPS module and what is being displayed in Droidplanner2 or Mission Planner.  Notice that I highlighted the 2.0 xDOP line in red, which corresponds to the cut-off value based on which IRIS makes the decision to arm or not. Thus we can see that HDOP for this location and date is always below 2.0. That’s great! With that we should be able to always arm IRIS in Loiter or Auto at that location and on that day.

But you can also see the PDOP – shown in green. That’s what the autopilot of IRIS is really receiving  from the GPS module, instead of HDOP. Notice that quite frequently this PDOP value is higher than 2.0, often much higher. During these periods – when the PDOP is higher than 2.0 – IRIS will not arm, even though the corresponding HDOP would be low enough. These are the moments when I’m attempting my 8-9 out of the 10 flights that I mentioned before.

How to fix this?

Ideally the above mentioned Ardupilot bug #644 should be fixed as soon as possible. That way the Autopilot of IRIS would actually make decisions on the correct value. Also we would see the correct HDOP value in DroidPlanner2 or Mission Planner.

In the meantime, I’ll increase the parameter value of GPS_HDOP_GOOD to 2.5 or 3.0. Looking at above graph, a PDOP of 3.0 would correspond to a HDOP of 2.0 for that location and time. From what I can tell, increasing this value should not have a negative effect, but rather allow me to arm IRIS in Loiter or AUto mode much more frequently.

Other that that I would also like to see a module from 3DR that supports GPS, GLONASS, BeiDou and Galileo. If Virtual Robotix in Italy can offer one, 3DR should be able to offer a plug&play replacement of their current module.

www.cloud-surfer.net

Диагностика проблем с помощью журналов ArduPilot в Mission Planner

Диагностика проблем с помощью журналов

Эта страница призвана показать вам , как диагностировать топ-5 наиболее распространненых проблем, влияющих на конфигурация APM:Copter в частности, но в некой стемени на конфигурацию APM:Plane и APM:Rover так же. Если вы еще не знакомы с основами журналов телеметрии и журналов APM то рекомендуется ознакомиться с этими страницами, что бы понять где хранятся эти данные и как можно скачать и посмотреть эту информацию.

Механические повреждения

Общие механические повреждения включают повреждения моторов или регуляторов скорости ESC (включая сбой синхронизации ESC) скольшение пропеллеров (проворачивание пропеллеров в следствии плохой затяжки) и тому подобное. Они появляются в журнале как внезапное расхождение в нужном угле тангажа или крена против фактического угла аппарата (по крену и тангажу / Roll and Pitch). Эти расхождения наиболее ярко видны в журнале из бортовой памяи полетного контроллера APM путем построения графика ATT сообщений: Roll-In против Roll и Pitch-In против Pitch и в меньшей степени NavYaw против Yaw

В приведеном выше примере фактическая Roll внимательно следует за нужным Roll-in для первой половины журнала, но потом расходиться. Полетный контроллер apm хотел удерживать Roll на уровне (нулевой roll) но это было невозможно, скорее всего это означает механическое повреждение. Это очень сильно отличается от программного сбоя в котором полетный контроллер ardupilot качался по Roll и по какой-то причине вдруг упал строго вниз , потому что в таких случаях желаемый Roll будет так же сумащедшим как и текущий Roll и будет следовать за ним на графике.

Дополнительные замечания:

  • Журналы tlog как правило труднее использовать в этом случае потому, что у нас есть nav_roll и nav_pitch, которые удерживают нужный крен и тангаж, они обновляются только тогда , когда используется полетный режим RTL, Loiter или AUTO.
  • В прошивке ArduCopter 3.1 и выше Roll-In и Pitch-In удерживают только нужный крен и тангаж во время стабилизации. А в режиме автопилота вы должны смотреть на NTUN сообщения: DRol и DPit.

Вибрации

Сильная вибрация у конфигурации ArduCopter вызывают у акселерометра, базирующемуся на высоте и горизонтальной позиции , заставляют дрейфовать далеко от реальности, что приводит к проблемам с удержанием высоты (обычно летит в небо) или режиме Loiter (дрейфует)

Вибрации лучше изучаь путем построение графиков из IMU сообщений с бортовой памяти APM по значениям AccX, AccY and AccZ. Значения AccX, AccY (в первую очередь используются для горизонтального управления положением) должны быть между -3 и 3 м/с/с. Значения акселерометра изменятся моментально, когда квадрокоптер движеся вверх или вниз, поэтому лучше достать данные порциями, когда полет квадрокоптера был стационарным, хотя даже в движении можно увидеть уровень вибрации сравнивая разницу между верхней и нижней частью "травы". иногда график прямолинеен, но когда "травинки" скачут, то скорее всего это проблема вибрации.

Ниже на графике указаны допустимые уровни вибрации.

Журналы TLOG RAW_IMU xacc, yacc and zacc можно использоватль, но их обновление происходит значительно медленее (как правило менее 10Гц) чем журнал из полетного контроллера ardupilot (50Гц) из-за этого становиться труднее понять являются ли изменения в акселерометре квадрокоптера перемещением или вибрацией

Если вы используете tlog шкалу в milli-gs то приемлемый диапазон для xacc и yacc от -300 до +300 и для zacc от -500 до -1500. Обратите внимание, что на рисунке значения ниже этого диапазона указывают на проблему вибрации , хотя этот пилот не жаловался на режимы AltHold и Loiter - это более вероятно , что квадрокоптер был не в стабильном наведении и частота обновления была низкой.

Вмешательства в работу компаса

Помехи от распределительной платы PDB, двигаелей, батареи , регуляторов моторов и других электрических устройств рядом с APM могут скинуть направление по компасу, который может привести к кругу ( известно как "туалетный боулинг")

Помехи от распределительной платы, двигателей, батареи, регуляторов скорости ESC и других электрических устройств квадрокоптера рядом с полетным контроллером ArduPilot Mega могут влиять на головное направление компаса, который может привести к "круговым полетам" ( так называемы туалетное смытие) или даже полет в неправильном направлении. Графическое значение mag_field в TLOG (находиться пот "CUSTOM") и дроссель (находиться под VFR_HUD) является самым простым способом, что бы увидеть количество помех. В графе ниже показано приемлимое количество помех. Вы можете увидеть как колеблится mag_field когда дросель газа поднят, но только движение вокруг на 10-20%. Ниже 30% движение является приемлемым. В диапазоне 30-60% находится серая зона, где он может быть в порядке (у некоторых пилотов) и очень плохом диапазоне магнитных помех будет отображаться скачками более 60%, когда дроссель поднят.

Примечания:

  • Длина mag_field может быть от 120 ~ 550 в зависимости от того, где и каком месте находиться квадрокоптер, но обычно оно составляет около 330 .
  • Магнитные помехи в виде процента от общего магнитного поля также отображаются в конце процедуры настройки compassmot.
  • Бортовой журнал полетного контроллера Ardupilot mega содержит "сырые" данные компаса x, y и z осей (называемые MagX, MagY, MagZ), которые эквивалентны RAW_IMU xmag, ymag и zmag полям в TLOG. Длину поля можно вычислить загрузив из бортового журнала данные в Excel фильтруя по сообщениям COMPASS, а затем расчитать магнитное поле по формуле mag_field = SQRT (MagX^2, MagY^2, MagZ^2). Обратите внимание, что журналирование сообщения сомпаса не включены по умолчанию, потому, что он работает на частоте 50Гц и влияет немного на производительность процессора.
  • Еще одни параметры которые нужно проверить, должны быть в пределах между - 150 и +150. Они находятся в TLOG группе SENSOR_OFFSET в качестве mag_ofs_x, mag_ofs_y, mag_ofs_z и в журнале полетного контроллера сообщения COMPASS в качестве OfsX, OfxY, OfxZ. Так же можно увидеть в параметрах как COMPASS_OFS_X, COMPASS_OFS_Y , COMPASS_OFS_Z.
  • Изображение выше показывает короткий пик в начале графика, но это может быть проигнорировано потому, что это перед поднятием дроссельной заслонки. Это вероятно просто подключение других электрических устройств.

GPS глюки

Находясь в режимах автопилота (Loiter, RTL, AUTO) ошибки позиционирования от GPS могут привести ArduCopter к неправильному местоположению и спровоцировать к агресивному полету исправления позиции. Эти "глюки" появляюстся в обоих журналах : TLOG и журнале полетного контроллера ardupilot mega apm как уменьшение числа видимых спутников и увеличение HDOP.

Если с помощью графика TLOGs вы можете сделать это путем построения графика группы "GPS_RAW_IT" значений "eph" и "satellites_visible". Значения HDOP 1,5 (отображаются на экране 150) или ниже - это очень хорошо. Выше 2,0 (т.е. 200) указывает на плохое значение позиции. Количество спутников, ниже 9 так же плохо. Существенное изменение этих двух значений часто сопровождает изменение позиции GPS.

В журнале полетного контроллера ardupilot mega apm сообщений GPS вы найдёте HDOP и столбцы NSats. Примечание! Значения HDOP находятся в правельных единицах измерения в журнале полетного контроллера (т.е. не 100 с лишним , как в tlogs).

В прошивке ArduCopter 3.1 и выже присуствует алгоритм обнаружения "GPS глюков" для их игнорирования.

Проблемы системы питания (Угасание и прочие)

Внедрение модуля питания стало гораздо проще для людей, что бы обеспечить надежное энергоснабжение квадрокоптера на полетном контроллере APM. Это привело к массовому сокращению числа "пониженного" питания, но они все еще имеют место быть. Как правило они могут присуствовать в журналах и внезапно заканчиваться, когда квадрокоптер все еще находиться в воздухе (например барометр или инерциальная навигация высоты по прежнему сообщает о высоте выше нуля).

Используйте графики:
  • Журнал полетного контроллера, CTUN сообщения, значение Baro-Alt
  • Журнал полетного контроллера, GPS сообщения, значения RelAlt (комбинированое значение акселерометра + барометра)
  • Журнал TLOG значение VHR_HUD alt (комбинированое значение акселерометра + барометра)
  • Журнал TLOG значение GLOBAL_POSITION relative_alt

Изменения в напряжении на борту полетного контроллера может быть признаком проблемы питания. Нормальные изменения в пределах от 0.10 до 0.15 вольт. Большие изменения могут быть признаком того, что другие устройства питающиеся на общей фазе APM вызывают "рябь" в блоке питания, что может привезти к "понижению" питания или другому странному поведению. Бортовое напряжение платы полетного контроллера можно отобразить на графиках:

  • Журнале полетного контроллера в сообщениях CURRENT значение VCC
  • Журнале телеметрии (tlog) группы HWSTATUS's значение Vcc

На изображение ниже показано просадка по напряжению на полетном контроллере на 0.15 вольт, когда подается дроссельный газ. Как правило это не очень хорошая вещь, но из-за того, что это только 0.15 вольт это наверное еще хорошо. Второй график ниже (из журнала полетного контроллера другого пилота) показывает более сильное изменение напряжение, но и как характерно пределах 0.15 вольт.

Неожиданные ошибки включая failsafes (защита отказа)

Когда происходит неожиданное поведение у полетного контроллера (особенно, когда пилот жалуется, что квадрокоптер не ответил на команды с радиоаппаратуры) это часто является одной из причины срабатывания failsafe (защита отказа). Есть 5 защит от отказов, которые могут быть активированны: защита газа, gps защита, защита наземной станции, защита отказа батареи и "виртуальный забор".

Самый простой способ найти срабатывание защиты посмотреть журнал полетного контроллера фильтруя по сообщениям ERR первый столбец.

В Subsys (подсистеме) есть область, которая генерирует вызвающую ошибку и ECODE (известная как "код ошибки") - это говорит нам, что ошибка была специальная. Ограниченное количество подсистем и кодов ошибок можно найти в исходных кодах конфигурации ArduCopter файла defines.h.

Sub Systems / Error Codes

  • 1: Main (never used)
  • 2: Radio
    • ECode 1: “Late Frame” which means the APM’s onboard ppm encoder did not provide an update for at least 2 seconds
    • ECode 0: error resolved which means the ppm encoder started providing data again
  • 3: Compass
    • ECode 1: the compass failed to initialise (likely a hardware issue)
    • ECode 2: failure while trying to read a single value from the compass (probably a hardware issue)
    • ECode 0: above errors resolved
  • 4: Optical flow
    • Ecode 1: failed to initialise (likely a hardware issue)
  • 5: Throttle failsafe
    • ECode 1: throttle dropped below FS_THR_VALUE meaning likely loss of contact between RX/TX
    • ECode 0: above error resolve meaning RX/TX contact likely restored
  • 6: Battery failsafe
    • ECode 1: battery voltage dropped below LOW_VOLT or total battery capacity used exceeded BATT_CAPACITY
  • 7: GPS failsafe
    • ECode 1: GPS lock lost for at least 5 seconds
    • ECode 0: GPS lock restored
  • 8: GCS (Ground station) failsafe
    • ECode 1: updates from ground station joystick lost for at least 5 seconds
    • ECode 0: updates from ground station restored
  • 9: Fence
    • ECode 1: altitude fence breached
    • ECode 2: circular fence breached
    • ECode 3: both altitude and circular fences breached
    • ECode 0: vehicle is back within the fences
  • 10: Flight Mode
    • ECode 0 ~ 10: the vehicle was unable to enter the desired flight mode
    • (0=Stabilize, 1=Acro, 2=AltHold, 3=Auto, 4=Guided, 5=Loiter, 6=RTL, 7=Circle, 8=Position, 9=Land, 10=OF_Loiter)
  • 11: GPS
    • ECode 2: GPS Glitch
    • ECode 0: GPS Glitch cleared
  • 12: Crash Check

ardupilot-mega.ru

ardupilot_wiki/prearm_safety_check.rst at master · ArduPilot/ardupilot_wiki · GitHub

Copter includes a suite of Pre-arm Safety Checks which will prevent the vehicle from arming if any of a fairly large number of issues are discovered before take-off including missed calibration, configuration or bad sensor data. These checks help prevent crashes and fly-aways but they can also be disabled if necessary.

.. youtube:: gZ3h3eLmStI :width: 100%

Recognising which Pre-Arm Check has failed using the GCS

The pilot will notice a pre-arm check failure because he/she will be unable to arm the copter and the LED will be flashing yellow. To determine exactly which check has failed:

  1. Connect the Flight Controller to the ground station using a USB cable or :ref:`Telemetry <common-telemetry-landingpage>`.
  2. Ensure the GCS is connected to the vehicle (i.e. on Mission Plannerand push the "Connect" button on the upper right).
  3. Turn on your radio transmitter and attempt to arm the vehicle (regular procedure using throttle down, yaw right)
  4. The first cause of the Pre-Arm Check failure will be displayed in red on the HUD window

Failure messages

RC failures (i.e. transmitter/receiver failures):

RC not calibrated : the :ref:`radio calibration <common-radio-control-calibration>` has not been performed. RC3_MIN and RC3_MAX must have been changed from their default values (1100 and 1900) and for channels 1 to 4, the MIN must be less than 1300 and the MAX greater than 1700.

Barometer failures:

Baro not healthy : the barometer sensor is reporting that it is unhealthy which is normally a sign of a hardware failure.

Alt disparity : the barometer altitude disagrees with the inertial navigation (i.e. Baro + Accelerometer) altitude estimate by more than 2 meters. This message is normally short-lived and can occur when the flight controller is first plugged in or if it receives a hard jolt (i.e. dropped suddenly). If it does not clear the :ref:`accelerometers may need to be calibrated <common-accelerometer-calibration>` or there may be a barometer hardware issue.

Compass failures:

Compass not healthy : the compass sensor is reporting that it is unhealthy which is a sign of a hardware failure.

Compass not calibrated : the :ref:`compass(es) has not been calibrated <common-compass-calibration-in-mission-planner>`. the COMPASS_OFS_X, Y, Z parameters are zero or the number or type of compasses connected has been changed since the last compass calibration was performed.

Compass offsets too high : the primary compass's offsets length (i.e. sqrt(x^2+y^2+z^2)) are larger than 500. This can be caused by metal objects being placed too close to the compass. If only an internal compass is being used (not recommended), it may simply be the metal in the board that is causing the large offsets and this may not actually be a problem in which case you may wish to disable the compass check.

Check mag field : the sensed magnetic field in the area is 35% higher or lower than the expected value. The expected length is 530 so it's > 874 or < 185. Magnetic field strength varies around the world but these wide limits mean it's more likely the :ref:`compass calibration <common-compass-calibration-in-mission-planner>` has not calculated good offsets and should be repeated.

Compasses inconsistent : the internal and external compasses are pointing in different directions (off by >45 degrees). This is normally caused by the external compasses orientation (i.e. COMPASS_ORIENT parameter) being set incorrectly.

GPS related failures:

GPS Glitch : the :ref:`GPS is glitching <gps-failsafe-glitch-protection>` and the vehicle is in a flight mode that requires GPS (i.e. Loiter, PosHold, etc) and/or the :ref:`circular fence <ac2_simple_geofence>` is enabled.

Need 3D Fix : the GPS does not have a 3D fix and the vehicle is in a flight mode that requires the GPS and/or the :ref:`circular fence <ac2_simple_geofence>` is enabled.

Bad Velocity : the vehicle's velocity (according to inertial navigation system) is above 50cm/s. Issues that could lead to this include the vehicle actually moving or being dropped, bad accelerometer calibration, GPS updating at below the expected 5hz.

High GPS HDOP : the GPS's HDOP value (a measure of the position accuracy) is above 2.0 and the vehicle is in a flight mode that requires GPS and/or the :ref:`circular fence <ac2_simple_geofence>` is enabled. This may be resolved by simply waiting a few minutes, moving to a location with a better view of the sky or checking sources of GPS interference (i.e. FPV equipment) are moved further from the GPS. Alternatively the check can be relaxed by increasing the GPS_HDOP_GOOD parameter to 2.2 or 2.5. Worst case the pilot may disable the fence and take-off in a mode that does not require the GPS (i.e. Stabilize, AltHold) and switch into Loiter after arming but this is not recommended.

Note: the GPS HDOP can be readily viewed through the Mission Planner's Quick tab as shown below.

INS checks (i.e. Acclerometer and Gyro checks):

INS not calibrated: some or all of the accelerometer's offsets are zero. The :ref:`accelerometers need to be calibrated <common-accelerometer-calibration>`.

Accels not healthy: one of the accelerometers is reporting it is not healthy which could be a hardware issue. This can also occur immediately after a firmware update before the board has been restarted.

Accels inconsistent: the accelerometers are reporting accelerations which are different by at least 1m/s/s. The :ref:`accelerometers need to be re-calibrated <common-accelerometer-calibration>` or there is a hardware issue.

Gyros not healthy: one of the gyroscopes is reporting it is unhealthy which is likely a hardware issue. This can also occur immediately after a firmware update before the board has been restarted.

Gyro cal failed: the gyro calibration failed to capture offsets. This is most often caused by the vehicle being moved during the gyro calibration (when red and blue lights are flashing) in which case unplugging the battery and plugging it in again while being careful not to jostle the vehicle will likely resolve the issue. Sensors hardware failures (i.e. spikes) can also cause this failure.

Gyros inconsistent: two gyroscopes are reporting vehicle rotation rates that differ by more than 20deg/sec. This is likely a hardware failure or caused by a bad gyro calibration.

Board Voltage checks:

Check Board Voltage: the board's internal voltage is below 4.3 Volts or above 5.8 Volts.

If powered through a USB cable (i.e. while on the bench) this can be caused by the desktop computer being unable to provide sufficient current to the flight controller - try replacing the USB cable.

If powered from a battery this is a serious problem and the power system (i.e. Power Module, battery, etc) should be carefully checked before flying.

Parameter checks:

Ch7&Ch8 Opt cannot be same: :ref:`Auxiliary Function Switches <channel-7-and-8-options>` are set to the same option which is not permitted because it could lead to confusion.

Check FS_THR_VALUE: the :ref:`radio failsafe pwm value <radio-failsafe>` has been set too close to the throttle channels (i.e. ch4) minimum.

Check ANGLE_MAX: the ANGLE_MAX parameter which controls the vehicle's maximum lean angle has been set below 10 degrees (i.e. 1000) or above 80 degrees (i.e. 8000).

ACRO_BAL_ROLL/PITCH: the ACRO_BAL_ROLL parameter is higher than the Stabilize Roll P and/or ACRO_BAL_PITCH parameter is higher than the Stabilize Pitch P value. This could lead to the pilot being unable to control the lean angle in ACRO mode because the :ref:`Acro Trainer stabilization <acro-mode_acro_trainer>` would overpower the pilot's input.

Disabling the Pre-arm Safety Check

If you are confident that the pre-arm check failure is not a real problem you can disable the checks by:

  • Connecting your Flight Controller to the Mission Planner
  • Go to Mission Planner's Config/Tuning >> Standard Params screen
  • set the Arming Check drop-down to "Disabled" or one of the "Skip" options which more effectively skips the item causing the failure.
  • Push the "Write Params" button

Ideally however you should determine the cause of the pre-arm failure and if it can be resolved, return the Arming Check parameter back to "Enabled"

github.com

Loiter mode - режим замри и слоняйся ArduPilot

Режим Loiter

В этом режиме квадрокоптер сохраняет постоянное местоположение: курс и высоту. Эти страницы описывают этот режим и дает советы по настройке.

Обзор

При включении режима Loiter квадрокоптер автоматически пытается сохранить текущее местоположение: курс и высоту над уровнем моря. Хорошая позиция GPS, влияние магнитных помех на компас и низкая вибрация являются важными в достижении высоких результатов режима Loiter.

Управление

Пилот может контролировать местоположение квадрокоптера в горизонтальном и вертикальном положении через аппаратуру.

  • Горизонтальное положение можно регулировать со стика наклона по крену и тангажу (Roll / Pitch) по умоглчанию максимальная горизонтальная скорость 5 метров в секунду. Для того, что бы изменить смотрите раздел Tuning указаный ниже. Когда пилот отпускает стик наклона аппарат останавливается до полной остановки.
  • Высоту над уровнем моря можно регуляровать через стик газа дросселя, как и в режиме AltHold.
  • Направление (курс) так же можно поменять через стик аппаратуры.

В прошивке ArduCopter 3.1 и выше вы можете снять с охраны (arming) в режиме Loiter, но только когда GPS обнаружил и зафиксировал спутники (3D Fix) и значение HDOP снизился до 2.0 и ниже.

На полетном контроллере светодиод на плате должен гореть постоянно синим светом, когда спутники пойманы в режиме 3D fix.

Величина параметра HDOP хорошо видна через Mission Planer установленного на отображение, через заранее выбраный флажек "gpshdop".

Настройка

Режим Loiter включает в себя режим AltHold. Информация по настройке режима AltHold находятся на соответсвующей странице этого режима.

Максимальную горизонтальную скорость полета в режиме Loiter можно регулировать через параметр (WPNAV_LOIT_SPEED) Mission Planeer -> Tuning -> APM ArduCopter PIDS. Значения выражаются в сантиметрах в секунду. 500 единиц равны 5 метров в секунду. Максимальное ускорение в режиме Loiter всегда равно 1\2 от скорости режима Loiter.

Параметр Loiter PID P (в правом верхнем углу на картине выше) используется для конпенсации ошибок горизонтального положения (то есть разница между желаемой и фактической позицией) до желаемой скорости по направлению к целевой позиции. Как правило не требует регулировки. Но с версии 3.х рекомендуется установить в значение 0.2 иначе квадрокоптер будет бешено менять позицию.

Параметры Rate Loiter PID используются для преобразования желаемой скорости к цели до желаемого ускорения. Полученное желаемое ускорение становиться углом наклона, который затем передается в контроллер используя режим стабилизации. Как правило они не требуются в изменении.

Проверка производительности режима Loiter через память журнала полетного контроллера

Просмотр производительности режима Loiter лучше всего сделать скачав данные журнала с вашего полетного контроллера. Затем откройте эти данные в Mission Planner и отобразите графики DesVelX в NTUN строке против VelX и DesVelY против Vely. В хорошем квадрокоптере скорости будут отслеживаться желаемые и действительные графики. Координата X - это широта (положительная - перемещение на север, отрицательная на Юг), Координата Y - это долгота (положительная - это восток, отрицательная - запад).

Проверка высоты производительности удержания такая же как и для режима AltHold.

Общие проблемы

Как упоминалось выше - режим Loiter включает в себя контроль по высоте от режима AltHold. Вопросы по режима AltHold рассмотрены на странице этого режима.

  • Аппарат может делать круги (туалетит) как показано на видео ниже. Обычно это вызванно проблемой компаса как правло от магнитных помех силовых кабелей под полетным контроллером. Запуск процедуры compassmot или приобретение совмещенного модуля GPS+compass решает эту проблему (но лишний раз провести такую процедуру не помешает для практики и опыта). Другие проблемы могут проявиться из-за неправильной живой калибровке ориентации компаса.
  • Аппарат взлетает и двигается в неправильном направлении (уносит) как только переходит в режим Loiter. Причиной может быть так же как и в пункте выше. еще может быть ошибка установки компаса, например больше 90 градусов. Попробуйте выполнить предложенные выше действия указанные выше.
  • Квадрокоптер слоняеться как обычно, а потом вдруг взлетает в непрпавильном направлении. Как правило это вызванно ошибкой GPS. Нет 100% защиты от такого - это означает , что пилот всегда должен быть готов взять ручное управление. Обеспечьте хорошее показание HDOP до взлета, так может помочь уменьшение параметров GPSGLITCH_RADIUS и GPSGLITCH_ACCEL (смотрите вики страницу GPSGlitch).

Режим OF_LOITER

Это специальная версия режима LOITER которая будет использовать оптический датчик для поддержания позиции. Она еще не реализована, но работа продолжается. прежде чем выбрать этот режим убедитесь, что оптический датчик Optical Flow установлен и работает.

ardupilot-mega.ru

Dilution of precision (navigation) - Wikipedia

Dilution of precision (DOP), or geometric dilution of precision (GDOP), is a term used in satellite navigation and geomatics engineering to specify the additional multiplicative effect of navigation satellite geometry on positional measurement precision.

Understanding the Geometric Dilution of Precision (GDOP) with a simple example. In A someone has measured the distance to two landmarks, and plotted their point as the intersection of two circles with the measured radius. In B the measurement has some error bounds, and their true location will lie anywhere in the green area. In C the measurement error is the same, but the error on their position has grown considerably due to the arrangement of the landmarks. Navigation satellites with poor geometry for Geometric Dilution of Precision (GDOP). Navigation satellites with good geometry for Geometric Dilution of Precision (GDOP).

Introduction[edit]

The concept of dilution of precision (DOP) originated with users of the Loran-C navigation system.[1] The idea of Geometric DOP is to state how errors in the measurement will affect the final state estimation. This can be defined as:[2]

GDOP=Δ(Output Location)Δ(Measured Data){\displaystyle GDOP={\frac {\Delta ({\rm {Output\ Location}})}{\Delta ({\rm {Measured\ Data}})}}}

Conceptually you can imagine errors on a measurement resulting in the Δ(Measured Data){\displaystyle \Delta ({\rm {Measured\ Data}})} term changing. Ideally small changes in the measured data will not result in large changes in output location, as such a result would indicate the solution is very sensitive to errors. The interpretation of this formula is shown in the figure to the right, showing two possible scenarios with acceptable and poor GDOP.

More recently, the term has come into much wider usage with the development and adoption of GPS. Neglecting ionospheric [3] and tropospheric[4] effects, the signal from navigation satellites has a fixed precision. Therefore, the relative satellite-receiver geometry plays a major role in determining the precision of estimated positions and times. Due to the relative geometry of any given satellite to a receiver, the precision in the pseudorange of the satellite translates to a corresponding component in each of the four dimensions of position measured by the receiver (i.e., x{\displaystyle x}, y{\displaystyle y}, z{\displaystyle z}, and t{\displaystyle t}). The precision of multiple satellites in view of a receiver combine according to the relative position of the satellites to determine the level of precision in each dimension of the receiver measurement. When visible navigation satellites are close together in the sky, the geometry is said to be weak and the DOP value is high; when far apart, the geometry is strong and the DOP value is low. Consider two overlapping rings, or annuli, of different centres. If they overlap at right angles, the greatest extent of the overlap is much smaller than if they overlap in near parallel. Thus a low DOP value represents a better positional precision due to the wider angular separation between the satellites used to calculate a unit's position. Other factors that can increase the effective DOP are obstructions such as nearby mountains or buildings.

DOP can be expressed as a number of separate measurements:

  • HDOP – horizontal dilution of precision
  • VDOP – vertical dilution of precision
  • PDOP – position (3D) dilution of precision
  • TDOP – time dilution of precision

These values follow mathematically from the positions of the usable satellites. Signal receivers allow the display of these positions (skyplot) as well as the DOP values.

The term can also be applied to other location systems that employ several geographical spaced sites. It can occur in electronic-counter-counter-measures (electronic warfare) when computing the location of enemy emitters (radar jammers and radio communications devices). Using such an interferometry technique can provide certain geometric layout where there are degrees of freedom that cannot be accounted for due to inadequate configurations.

The effect of geometry of the satellites on position error is called geometric dilution of precision and it is roughly interpreted as ratio of position error to the range error. Imagine that a square pyramid is formed by lines joining four satellites with the receiver at the tip of the pyramid. The larger the volume of the pyramid, the better (lower) the value of GDOP; the smaller its volume, the worse (higher) the value of GDOP will be. Similarly, the greater the number of satellites, the better the value of GDOP.

Meaning of DOP Values[edit]

DOP Value Rating Description
< 1 Ideal Highest possible confidence level to be used for applications demanding the highest possible precision at all times.
1-2 Excellent At this confidence level, positional measurements are considered accurate enough to meet all but the most sensitive applications.
2-5 Good Represents a level that marks the minimum appropriate for making business decisions. Positional measurements could be used to make reliable in-route navigation suggestions to the user.
5-10 Moderate Positional measurements could be used for calculations, but the fix quality could still be improved. A more open view of the sky is recommended.
10-20 Fair Represents a low confidence level. Positional measurements should be discarded or used only to indicate a very rough estimate of the current location.
>20 Poor At this level, measurements are inaccurate by as much as 300 meters with a 6-meter accurate device (50 DOP × 6 meters) and should be discarded.

The DOP factors are functions of the diagonal elements of the covariance matrix of the parameters, expressed either in a global or a local geodetic frame.

Computation of DOP Values[edit]

As a first step in computing DOP, consider the unit vectors from the receiver to satellite i: ((xi−x)Ri,(yi−y)Ri,(zi−z)Ri){\displaystyle \left({\frac {(x_{i}-x)}{R_{i}}},{\frac {(y_{i}-y)}{R_{i}}},{\frac {(z_{i}-z)}{R_{i}}}\right)} where Ri=(xi−x)2+(yi−y)2+(zi−z)2{\displaystyle R_{i}={\sqrt {(x_{i}-x)^{2}+(y_{i}-y)^{2}+(z_{i}-z)^{2}}}} and where x,y{\displaystyle x,y} and z{\displaystyle z} denote the position of the receiver and xi,yi{\displaystyle x_{i},y_{i}} and zi{\displaystyle z_{i}} denote the position of satellite i. Formulate the matrix, A, which (for 4 range measurement residual equations) is:

A=[(x1−x)R1(y1−y)R1(z1−z)R1−1(x2−x)R2(y2−y)R2(z2−z)R2−1(x3−x)R3(y3−y)R3(z3−z)R3−1(x4−x)R4(y4−y)R4(z4−z)R4−1]{\displaystyle A={\begin{bmatrix}{\frac {(x_{1}-x)}{R_{1}}}&{\frac {(y_{1}-y)}{R_{1}}}&{\frac {(z_{1}-z)}{R_{1}}}&-1\\{\frac {(x_{2}-x)}{R_{2}}}&{\frac {(y_{2}-y)}{R_{2}}}&{\frac {(z_{2}-z)}{R_{2}}}&-1\\{\frac {(x_{3}-x)}{R_{3}}}&{\frac {(y_{3}-y)}{R_{3}}}&{\frac {(z_{3}-z)}{R_{3}}}&-1\\{\frac {(x_{4}-x)}{R_{4}}}&{\frac {(y_{4}-y)}{R_{4}}}&{\frac {(z_{4}-z)}{R_{4}}}&-1\end{bmatrix}}}

The first three elements of each row of A are the components of a unit vector from the receiver to the indicated satellite. If the elements in the fourth column are c which denotes the speed of light then the σt{\displaystyle \sigma _{t}} factor (time dilution) is always 1. If the elements in the fourth column are -1 then the σt{\displaystyle \sigma _{t}} factor is calculated properly.[5] Formulate the matrix, Q, as:

Q=(ATA)−1{\displaystyle Q=\left(A^{T}A\right)^{-1}}

In general: Q=(JxT(JdCdJdT)−1Jx)−1{\displaystyle Q=(J_{x}^{T}(J_{d}C_{d}J_{d}^{T})^{-1}J_{x})^{-1}} where Jx{\displaystyle J_{x}} is the Jacobian of the sensor measurement residual equations fi(x_,d_)=0{\displaystyle f_{i}({\underline {x}},{\underline {d}})=0}, with respect to the unknowns, x_{\displaystyle {\underline {x}}}; Jd{\displaystyle J_{d}} is the Jacobian of the sensor measurement residual equations with respect to the measured quantities d_{\displaystyle {\underline {d}}}, and Cd{\displaystyle C_{d}} is the correlation matrix for noise in the measured quantities. For the preceding case of 4 range measurement residual equations: x_=(x,y,z,τ)T{\displaystyle {\underline {x}}=(x,y,z,\tau )^{T}}, d_=(τ1,τ2,τ3,τ4)T{\displaystyle {\underline {d}}=(\tau _{1},\tau _{2},\tau _{3},\tau _{4})^{T}}, τ=ct{\displaystyle \tau =ct}, τi=cti{\displaystyle \tau _{i}=ct_{i}}, Ri=|τi−τ|=(τi−τ)2{\displaystyle R_{i}=|\tau _{i}-\tau |={\sqrt {(\tau _{i}-\tau )^{2}}}}, fi(x_,d_)=(xi−x)2+(yi−y)2+(zi−z)2−(τi−τ)2{\displaystyle f_{i}({\underline {x}},{\underline {d}})={\sqrt {(x_{i}-x)^{2}+(y_{i}-y)^{2}+(z_{i}-z)^{2}}}-{\sqrt {(\tau _{i}-\tau )^{2}}}}, Jx=A{\displaystyle J_{x}=A}, Jd=−I{\displaystyle J_{d}=-I} and the measurement noises for the different τi{\displaystyle \tau _{i}} have been assumed to be independent which makes Cd=I{\displaystyle C_{d}=I}. This formula for Q arises from applying Best Linear Unbiased Estimation to a linearized version of the sensor measurement residual equations about the current solution Δx_=−Q∗(Jx(JdCdJdT)−1f){\displaystyle \Delta {\underline {x}}=-Q*(J_{x}(J_{d}C_{d}J_{d}^{T})^{-1}f)}, except in the case of B.L.U.E. Cd{\displaystyle C_{d}} is a noise covariance matrix rather than the noise correlation matrix used in DOP, and the reason DOP makes this substitution is to obtain a relative error. When Cd{\displaystyle C_{d}} is a noise covariance matrix, Q{\displaystyle Q} is an estimate of the matrix of covariance of noise in the unknowns due to the noise in the measured quantities. It is the estimate obtained by the First Order second Moment (F.OR.M.) uncertainty quantification technique which was state of the art in the 1980s. In order for the F.OR.M. theory to be strictly applicable, either the input noise distributions need to be Gaussian or the measurement noise standard deviations need to be small relative to rate of change in the output near the solution. In this context, the second criteria is typically the one that is satisfied.

This (i.e. for the 4 range measurement residual equations) computation is in accordance with [6] where the weighting matrix, P=(JdCdJdT)−1{\displaystyle P=(J_{d}C_{d}J_{d}^{T})^{-1}}, has been set to the identity matrix.

The elements of Q are designated as:

Q=[σx2σxyσxzσxtσxyσy2σyzσytσxzσyzσz2σztσxtσytσztσt2]{\displaystyle Q={\begin{bmatrix}\sigma _{x}^{2}&\sigma _{xy}&\sigma _{xz}&\sigma _{xt}\\\sigma _{xy}&\sigma _{y}^{2}&\sigma _{yz}&\sigma _{yt}\\\sigma _{xz}&\sigma _{yz}&\sigma _{z}^{2}&\sigma _{zt}\\\sigma _{xt}&\sigma _{yt}&\sigma _{zt}&\sigma _{t}^{2}\end{bmatrix}}}

PDOP, TDOP and GDOP are given by:

PDOP=σx2+σy2+σz2TDOP=σt2GDOP=PDOP2+TDOP2{\displaystyle {\begin{aligned}PDOP&={\sqrt {\sigma _{x}^{2}+\sigma _{y}^{2}+\sigma _{z}^{2}}}\\TDOP&={\sqrt {\sigma _{t}^{2}}}\\GDOP&={\sqrt {PDOP^{2}+TDOP^{2}}}\\\end{aligned}}}

in agreement with Section 1.4.9 of Principles of Satellite Positioning. More generally, GDOP is the square root of the trace of the Q{\displaystyle Q} matrix.

The horizontal dilution of precision, HDOP=σx2+σy2{\displaystyle \scriptstyle HDOP={\sqrt {\sigma _{x}^{2}+\sigma _{y}^{2}}}}, and the vertical dilution of precision,  VDOP=σz2{\displaystyle \scriptstyle \ VDOP={\sqrt {\sigma _{z}^{2}}}}, are both dependent on the coordinate system used. To correspond to the local horizon plane and the local vertical, x, y, and z should denote positions in either a north, east, down coordinate system or an east, north, up coordinate system.

References[edit]

Notes[edit]

General[edit]

External links[edit]

en.wikipedia.org


Смотрите также