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

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

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.

Tagged with: ,
8 comments on “High HDOP values when flying IRIS
  1. Paul Dinardi says:

    Hey Christian,

    Great write up, In your research have you come up with an other contributing factors as to what could specifically hinder the GPS signal from seeing the Satellites all together, I have 3, Pixhawk based copters, Iris+, X8 and a FPV Dead cat frame, Iris and the Dead cat see 2.0 or below within a minute of power up, but recently the 8X has had some extended lock times with regard to getting a low enough HDOP to arm, Increasing the “Good Satellite” parameter would fix my issue, as I’ve never seen it above 3.0 for HDOP or PDOP as you point out, but what troubles me is why on 1 copter and not my other 2. I’ve read that FPV equipment can inhibit the signal so I’ve moved everything around and don’t see much change, just curious if you may have seen or hear of any other contributing factors in receiving a GPS HDOP/PDOP signal. I’m already on a mast on that copter, so I really can’t imagine why it’s so critical.

    Thanks in advance, Paul

  2. Christian Elsen says:

    The GPS module from 3DR has a small battery in it. This allows the GPS to perform a warm start vs. a cold start. It means that the GPS module already has the almanac data available (cached) and can therefore quicker perform the math for locking on to the GPS signals.
    This will only work if there isn’t too much time in between using the GPS (usually less than 2 weeks is OK). You should be flying within the same region for this to work and also don’t run the GPS indoors.

    It’s possible that this battery is drained on your X8. What happens if you are outside with a lock, then power down everything, wait 10 minutes and power up stuff again. Will it get a lock fast or slow?

    • Paul Dinardi says:

      Wow Christian, Thanks for the reply and lol sorry, I must have missed it, This has never actually been resolved for me, the wait times on this copter are longer than the other two that I run, but I see no real detriment once locked. As you can see, this original post was from December, so as the weather warms I’ll better be able to tell, I’m aware about the battery, but I don’t think thats my issue, there is something either structural or physical in the X8 that I believe either reflects or somehow blocks the signal, oddly enough it’s on a mast, away from other antenna. I did however just learn that the RTF X8+ Params are looking for an HDOP of 200, rather than like IRIS that looks for 2.5 and for me, thats huge as I Rarely see below 2.1 to 1.9. This could have been a contributing factor back when I first wrote this. I cannot recall what the HDOP was then. But thanks for your time.

  3. Chris bantli says:

    I fixed it!
    connect via USB to mission planner. disable geofence then re-enable again .that will reset the buggy hdop variable.

    • Christian Elsen says:

      That’s rather doubtful. The Arducopter code is wrong. It interprets the wrong value of the incoming data stream from the GPS module. Fiddling around with the Arducopter parameters isn’t gonna fix that.

      • Chris bantli says:

        This is how I arrived at that conclusion..
        I have an Iris+, worked fine until today. This morning I turned it on, and get the red/blue lights while it initialized. then flashing yellow. wouldn’t arm no matter what.
        So i connect to mission planner HDOP value was 99 ( i have no idea what that means but apparently that is greater than it’s supposed to be) .

        so after some googling I looked to disable geofence..and yellow light stopped blinking. but i want geofence on, so I turned it back on. yellow light did not come back on!

        I still have to take it out to the field to test..hoping it works and the hdop value doesn’t mess up again..but from your reply it sounds like it might happen again.. in that case i’d disable geofence

        • Christian Elsen says:

          If the displayed HDOP value is 99, that usually means that the GPS module is defective or the cable is disconnected.

          When you disable the geofence you basically disable a pre-flight check. Without geofence IRIS will not validate that you have a valid GPS position before arming and will thereby let you take off without it. But you will most likely crash if you switch into an GPS-assisted mode (RTL, Loiter, …) without proper GPS prior to take off.

  4. Judd Chastain says:

    Has this issue in the software been fixed yet? As of now the only time I get the High HDOP error is when I try to take off from my backyard ( which is really big and open)! In a very large open field it’s not a problem. But as we all know….this will not always be the ideal situation for taking off. The only way I can do it from my yard is to change the values from 250 to 300.