Fixed Wing Dead Reckoning test of the Zealot H743 Aero Applications Edition

I plan to test dead reckoning using intertial navigation on the Qio-Tek Zealot H743 “Aero Applications Edition” which has an IIM-42652, ICM-42688P and an ADIS–16470 IMU.

  • Barometers: DPS3018 *2
  • Compass: QMC5883L

I’ll also install an ASP-5033 Airspeed sensor (using DroneCAN of course).

I know I can “disable” GPS in software, but call me cynical, I want to be 100% sure that while flying with no GPS, there is no chance the GPS is being used. I also don’t want to lose my plane and this very expensive flight controller.

So my plan is to put 2x flight controllers in a single fixed wing plane. One will be a ‘standard’ flight controller, with a GPS. The 2nd will be the Zealot Aero running ArduPlan 4.4.0 beta 2… I’ll connect them via S-Bus (S-Bus out from one to S-Bus in from the other), so that I can flip which one has control by changing modes. I’ve already tested this and it’s fun to watch one FC take its “RC inputs” from a 2nd FC :slight_smile: .

When the Aero is flying the plane, the standard flight controller will be logging the true location as it will have a GPS (M10S), so it will be possible to compare the two logs.

Any thoughts/suggestions appreciated. I’ll post updates as I go. I’m just setting up the electronics now, hoping to have it ready to fly in about a week (so early June 2023).

This is a video of how I’m setting up the 2 flight controllers:

[2023-06-06] The plane is almost ready for test flights to confirm setups etc, then the real testing will follow. Initially I’m planning the following tests:

Each of these tests will be done 1st with the Zealot Industrial Edition using an M10S GPS. Then the same test will be done using the Zealot Aero Applications Edition.

  1. Takeoff manually, fly out to a point about 1km from home with GPS. Disable GPS. RTL
  2. Takeoff manually, switch to AUTO, try to fly out to a waypoint about 1km from home with no GPS even connected.
  3. Auto takeoff with GPS, disable GPS, start a waypoint mission flying a rectangle around home continue flying as long as the battery lasts.
  4. Auto takeoff without GPS, then attempt to fly the same waypoint mission

Tridge tells me test 2 an 4 are not likely to even work. If they fail - the nature of the fail will be interesting too.

Any suggestions for additional test appreciated, but note I can’t fly long distance. To stay legal I’m limited to my largest flying field which is an irregular shape about 1km N/S and 1km E/W at the widest points.

[2023-06-08] I flew this yesterday, simple test flight to make sure the plane will actually fly. The Aero was in the plane, but not active (RC pass through to to the other AP which was actually doing the flying). The Aero had no GPS connected. I set both EKF Origin and Home using Mission Planner by clicking on the map where the plane was physically located and clicking “set Home to here”. Then I flew. These are two logs from these flights. As you can see there appears to be no location information in the logs. Any thoughts/suggestions appreciated.

After doing a bit of digging I think I need to add this:

  • param set EK3_SRC1_POSXY 0
  • param set EK3_SRC1_VELXY 0
  • param set EK3_SRC1_VELZ 0

as documented here Setting Home and/or EKF origin — Dev documentation.

[2023-06-12] So I tried doing this and it didn’t seem to help. The flight controller won’t use the EKF origin or Home set by QGC, Mission Planner or mavproxy as it’s “starting point” for navigation. Here are some logs I got from doing this:


It’s annoying not to have date/time without GPS I’m going to set BRD_RTC_TYPES = 1 (MAVLink time), It’s not clear to me if I need to explicitly send the date/time from MavProxy or it will happen automatically when it connects. I guess I’ll find out.

[2023-06-13] I flew yesterday after connecting a GPS to the Aero and setting up RC12 = Disable GPS. This flight has several examples of flying with GPS then using RTL and disabling GPS. What I think I see is it falls back pretty quickly to DCIM which is very disappointing.

AP switched to DCM after only 7 seconds of dead-reckoning and shows a “dog leg” when this happens. It seems to me the DCM track is wrong.
This video shows the track from a second flight controller that was in the plane with it’s own GPS, it’s not perfectly synchronized, but I think you can see that the EKF track on the Aero seems to be correct and the DCM track when AHRS switches is probably wrong.

Using these logs and to tighten up the compass calibrations on both APs.


[2023-06-16] After reviewing the logs. I’m not happy that I only get 7 seconds of EKF non-GPS flight before AP falls back to DCM. I’ve decided to explicitly set the EKF Source for each lane (I think that’s what the SRC means) explicitly as follows:

After doing a bit of digging I think I need to add this:

  • param set EK3_SRC1_POSXY 3 (GPS)

  • param set EK3_SRC1_POSZ 3 (GPS)

  • param set EK3_SRC1_VELXY 3 (GPS)

  • param set EK3_SRC1_VELZ 3 (GPS)

  • param set EK3_SRC1_YAW 3 (GPS with compass fallback)

  • param set EK3_SRC2_POSXY 0 (IMU)

  • param set EK3_SRC2_POSZ 1 (Baro)

  • param set EK3_SRC2_VELXY 0 (IMU)

  • param set EK3_SRC2_VELZ 0 (IMU)

  • param set EK3_SRC2_YAW 1 (Compass)

  • param set EK3_SRC3_POSXY 3 (GPS)

  • param set EK3_SRC1_POSZ 1 (Baro)

  • param set EK3_SRC3_VELXY 3 (GPS)

  • param set EK3_SRC3_VELZ 3 (GPS)

  • param set EK3_SRC3_YAW 1 (Compass)

But I think I also need to figure out exactly which of the IMU’s (0,1,2) is actually the ADSI-16470

[2023-06-17] I’m not 100% sure how useful it for this test, but @iampete just released his new FFT Filter tool, so I’m planning to enable raw IMU logging and see what the tool can tell me. I’m thinking it might be helpful even if it’s not directly applicable to a fixed wing.

This at very least has confirmed that IMU[0] is in fact the ADIS-16470. It also looks pretty clean.

[2023-06-17] I flew this again after making the changes above and enabling the airspeed sensor. I must say it did much better. I didn’t get a switch to DCM at all, but what I did get in the end was that the plane kept flying after it had reached waypoint 6 of the mission it was flying and I had to “hit the button” to bring it back home (switching back to the other flight controller). It did seem like it was flying in the right direction but misjudged the distance. Here’s the log:

[2023-06-23] This is a video walkthrough of the vehicle showing everything installed and how it is all connected.

[2023-06-25] Yesterday I experienced a Rapid Unscheduled Disassembly. I had installed an RM3100 which seemed to fix the yaw alignment problem, but when I flew it was behaving very strangely. At one point after flying Loiter mode I switched to FBWA and the plane dived vertically directly into the ground. It was quite spectacular (sorry no video). I’m pretty sure it was a mechanical failure - after the crash the elevator servo was dislodged from its mounting. I can’t be sure but I think it might be the cause of the crash rather than a result. Here is the log:

From the Aero Flight controller which started the dive into the ground -

Then I switched to RTL on the Industrial flight controller which appeared from where I was, to simply double down on diving into the ground.

Since both flight controllers are behaving so strangely, and after finding the elevator servo had basically fallen out of its mounting, I think this might have been the cause.

And here is a picture of the end result

You don’t need 2 flight controller. As you said turning off the GPS with a toggle switch works perfectly. We tested several times. Dead Reckoning works.
You either trust the software or you don’t. Can’t have it both ways.
What happens infact is the GPS is not disabled, rather the drone will not use the data from the GPS, if you set it up as such. So the result will be the same as if it was damaged or broken or jammed. Except with this, in the log (after the flight) you will have knowlage of where the drone actually was compared to where it “thought” it was. Which is very useful.
Also of you are so worried about this, just stay in LOS and do it that way. Then you will have peace of mind that you are actually seeing the drone.
If you want it far from you, then the best option for the faint hearted is to add an FPV camera so you see where it is actually going and such. And could even navigate back visualy if you want.
However as I said tested several times. You can switch back the GPS at anytime and it will correct the position imidiately, and continue as if nothing happened.
BTW that is infact one of the cheaper flight controllers that you call expensive :slight_smile:
But again it does not matter. Even a MatekSys is fine, It is the same firmware running on all. For the dead Reckoning the key elements are the airspeed sensor and your compass. All other sensors have little to do with it versus normal (GPS) navigation.
Forget the secondary FC, just adding complexity and failure points. it is a simple experience, you will see.
Error will start building up with time/distance, exponentially. I may be wrong, but was something like 200m side drift (error) per 1 km.


I quite commonly do flights with RC option to disable GPS. Easy to do, and with mavproxy the real GPS pos still shows up on the map.
Drift in fixed wing is usually about 1 meter per second of flight, so 60meters/minute
you can get it down to 0.5m/s with some effort on the sensors. Achieving 1m/s is pretty easy. Even works with just baro and imu (no airspeed, no compass)


Thanks @pompecukor and @tridge for the feedback. Just to be clear - I’m not doing this to test ArduPilot so much as to test the Zealot H743 Aero Applications edition autopilot.

I’ll do one test using the standard flight controller (GPS disabled) and then one with the Aero - no GPS. I’m looking for less drift with the ADIS-16470.

I am sorry, I original missed the part about Aero Applications edition, that indeed is an expensive FC.

Yes it’s comparable to the CUAV X7 Pro.

1 Like

How can I set the home position on the AP which has no GPS? I tried QGC and Mission Planner and neither seem to work. Do I need to use MavProxy and if so what is the command?

Thanks to @david_sastre for adding the “Set Home Position” option to QGC. I’ve tested it on the bench and it does seem to do what I need. It’s not in the official code base yet, you can get the PR version here Master pr/support do set home by Davidsastresas · Pull Request #10701 · mavlink/qgroundcontrol · GitHub

1 Like

Ohh that sounds good, we are waiting for the result.
thank you so much

what do you think that will be survive in fully GPS denied environment?

1 Like

Very interesting! which message is picking mavproxy realtime to show this “disabled GPS” data?

Maybe @tridge can confirm, but I would say it is SET_EKF_ORIGIN problably, if the aircraft is configured with no GPS on the first place.

QGC doesn’t have support for it yet ( There is an opened PR adding it, so should be soon ), but Mission planner has it. I think it was right click->set ekf origin here or something like that.

It has: Right Click → Set Home to Here → (options) Set EKF Origin Here, Set Home Here

I used that command in the past working with no-GPS vehicles and it had the effect you need. I would give it a try.

1 Like

It didn’t seem to work. I’ve added to the original post (above). Any thoughts?

Is it possible to show both of the paths on the map using MAVExplorer? I now have a log where I disabled the GPS (a couple of times) during the flight and trying to get a good perspective on it.

you can view dead-reckoned log a few ways in MAVExplorer.
First, for map do “map GPS POS XKF1”

The green line is GPS, red is XKF1, blue is current nav estimate (where it differs from XKF1 it means we were falling back to DCM based dead-reckoning).
this graph shows distance between POS and GPS on left side, GPS status on right (GPS status goes to 1 when you disable the GPS)

you can see in the first part you disabled for 2 minutes and got an error of about 100m. It got to 800m the 2nd time, so not great.

1 Like

as to why it was so bad, the EKF3 innovations tell you that:

the biggest issue is SVT, which is your airspeed.
We can compare ground speed to pressure altitude corrected airspeed like this:

you can see airspeed is a long way from ground speed.
I also see your ARSPD_RATIO is 4.0. That is a sure sign of an extremely bad airspeed setup. Something is badly wrong with the airspeed install.
If you want good dead-reckoning then your first job is to fix the airspeed setup. Post some pictures of the setup to start with.


I thought the problem might be the pitot tube (which is being reused), so I’ve replaced it just now with a brand new one fresh out of the box. This airspeed sensor (CAN) had ARSPD_RATIO = 1.68 in the previous plane. However after another test/autocal flight with a new pitot tube on 2023-06-21, I still got a ratio of 4.0 so I will replace the AirSpeed sensor itself. After replacing with a brand new CAN airspeed sensor on 2023-06-22 I got the same result. I will try now with an i2c Airspeed Sensor (PX4AirSpeedV1.1).

This is what it looks like now (after replacement). It’s a twin, so the pitot tube is a long way from the props.

BTW @tridge - with LOG_REPLAY = 1 these logs are a bit larger than usual, not really very big, maybe 200-400MB, but they take forever to download over MAVFTP. The same file takes about 10 seconds to copy off the sd card if I insert it into the computer, but 3/4 hour or more to download via MAVFTP. And that’s over USB!!! Is there any way you can do something about this?
[As you know the SD Card slot is often inaccessible without removing the AP from the plane, as it is in this case]

A number of the devs use this type of thing when testing, to make the SD card accessible:

They’re available on Amazon, eBay, Adafruit etc in a variety of lengths.


Thanks James, I have to say this workaround just provides more hard evidence that there is a real problem.

1 Like