Septentrio AsteRX-m2 and other SBF GPSs output data at up-to 100Hz
The device driver configures the GPS to 10Hz.
Should the EK2_GPS_DELAY parameter be changed to 110ms ?
How can I measure it ?
Can I change the device driver to ask for 20Hz, or are there side effects that I need to take into consideration ?
The device can do 20Hz, why was that not selected in the first place ?
Hey @amilcarlucas ! Sorry to revive such an old thread, but were you able to configure Ardupilot to use a GPS at 20 Hz or more? I am also interested in Septentrio’s and Novatel’s receivers for an application that requires precise position during long-duration 4-6g accelerations.
I’m really curious if 20 Hz or more is possible with Ardupilot. Also, new Ublox X20P modules will be releasing probably within the next year, offering 4-band 4-constellation RTK at 25 Hz.
I haven’t got it to work over 10Hz yet.
Not only is 10Hz the limit, I’m fairly certain that 5Hz is the limit for RTK GPS due to bandwidth and processing limitations. I do not find that to be particularly detrimental. AFAIK, you’d have to be traveling quite fast before the EKF would suffer much even at 5Hz.
From what I understand, Mosaic-X5 receivers can process RTK at 100 Hz. I’m not sure if it’s using only 1 constellation or all 4 though.
Or do you mean that Ardupilot can’t process that much data (more than 5 or 10 Hz)? I think I read something similar a while back. I don’t know if that is confirmed or not, but would that be a driver issue (as in, too much data to parse) or would it be due to the correction algorithm of the EKF having to run at the same frequency as the received GPS data?
This is for an application where a fixed-wind drone will perform a constant 3-6g turn for over 10 minutes. The accelerometer will be unlikely to be able to provide the gravity’s direction, hence why we are looking at RTK GPS for providing good position and velocity measurements, as well as heading, roll, and possibly pitch if we use 3 GPS receivers. Septentrio’s and Novatel’s receivers seem interesting for high-g applications, and high frequency position/velocity data can only help in high acceleration situations.
Yes, it’s an ArduPilot limitation.
Have you modeled the problem at all? I find it hard to believe that anyone needs 3-DOF RTK GPS to handle sustained G turns.
I see.
Another plan is to look into offboarding the state estimation to a separate board with an onboard IMU, using the GPS receivers at high frequency, and programming our own Kalman filter to take into account the nature of the UAV’s movement (constant turning at a known radius).
How have you proven that existing solutions are inadequate? Your problem is not a novel one.
It’s still not yet confirmed, but it is anticipated. The problem was modelled (outside of SITL), but from what I’m told, Ardupilot’s SITL takes the model outputs as truth and bypasses the EKF. So we still don’t know for sure what the EKF will do.
I’m not fully involved in this project, I was just tasked to find potentially suitable GPS receivers and to determine if Ardupilot can deal with high GPS data rates. From what I hear, the others involved will soon test how Ardupilot’s EKF reacts to a sustained 3-6g turn over 5 or 10 minutes (as well as a F9P receiver), in a controlled environment (not on a UAV, known position and attitude ground truths).
The foreseeable issue is that, without any moments of constant motion (non-accelerating motion), the gravity’s direction estimation will drift over time. The EKF requires moments of 1g to reset the estimated gravity direction. But, we’ll have a better idea if that really happens after the planned trials.
I’m curious. Do you have sources for projects that had similar problems? I’d like to see the solutions they used.
I don’t have shareable source but have operated platforms that have similar capability, and they aren’t using anything exotic. The core was still IMU based measurement, and non-RTK GPS updates were not particularly fast.
Hi @bobzwik,
I think AP will be fine performing a constant high-G turn. I also think that higher rate GPSs should also work but in general there’s no real advantage because the GPS is only used for longer term corrections.
Re SITL’s EKF, the AHRS_TYPE allows choosing whether EKF3 runs or not in SITL but I think by default it does use EKF3