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 .
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.
- Takeoff manually, fly out to a point about 1km from home with GPS. Disable GPS. RTL
- Takeoff manually, switch to AUTO, try to fly out to a waypoint about 1km from home with no GPS even connected.
- Auto takeoff with GPS, disable GPS, start a waypoint mission flying a rectangle around home continue flying as long as the battery lasts.
- 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:
LOG_DISARMED = 1 and LOG_REPLAY = 1
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 magfit_WMM.py to tighten up the compass calibrations on both APs.
Mag COMPASS_OFS_X -164 COMPASS_OFS_Y 62 COMPASS_OFS_Z 548 DIA[XYX] = 1 ODI[XYZ] = 0 COMPASS_SCALE 0.6
Mag COMPASS_OFS_X 337 COMPASS_OFS_Y -156 COMPASS_OFS_Z 502 DIA[XYZ] = 1 ODI[XYZ] = 0 COMPASS_SCALE =0,.6
[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 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