I need a concept for drone flight tests without gps in order to test a self developed visual positioning system running on a companion Raspberry Pi
The steps EKF “reporting → position correction” while drifting constantly or momentarily cannot be tested as long as EKF is permanently corrected by GPS.
I want to use ArduPilot EKF in this scenarion, but not GPS. ArduPilot should do positioning solely based on IMU, compass etc. Initial position will be set (HOME, EKF origin). I just want to nudge the EKF with the external positioning source.
Setup
Holybro X500 v2 running Pixhawk 4 with ArduPilot 4.6 and UART/Mavlink connection to Raspberry Pi. The positioning pipeline (camera, gimbal, algorithm) all reside or are controlled by the raspberry and its software, receiving mainly local_position and attitude data from the flight controller and – for some of these envisioned scenarios – possibly feeding back “fake external GPS data” which really comes from visual positioning. The raspberry (Rpi) runs the positioning algorithm (“pipeline”) is based on ROS2, so ROS mechanisms as “ros bag” are available.
Characteristics of the SED Positioning Algorithm
Tests with the algorithm under gps conditions showed already:
-
positioning is heavily terrain dependent – I currently test in well structured terrain and will look for less structured areas, once I get success under favorable conditions
-
positioning frequency in well structured terrain can be assumed in intervals of 3-10 seconds. Higher frequencies are bound by the computational efforts, Lower frequencies are unbound and depend on terrain and the positioning pipeline itself
-
the pipeline has a mechanism to apply corrections piecewise, avoiding sudden jumps
-
the positioning corrections will be slightly outdated, once they are available, due to computation time - I estimate 2-6 seconds. The correction is therefore based on a previous position and calculated as a correction vector which is then re-applied to the most current position. This bears again some small delay (estimated 0.4 s transfer from Pixhawk to pipeline) and is deemed harmless.
-
The overall precision goal of the positioning is “better than 20 m” (so its coarse)
-
focus is, for now, only on lat/lon positioning, not altitude
Flight Conditions
Current flight tests have been executed with MissionPlanner’s flight plans. So the drone is just launched by manual control and then switched to auto mode using the radio controller. The drone flies the pre-programmed path including successful return to launch. This never lead to a crash. Maximum wind conditions were 5-7 m/s during test flights. I can fly a drone manually, due to Velocidrone training and some tests with the real drone, but lack much real-life flying experience. The drone is not per-Se an FPV drone. I installed a wifi based video transmission, but wifi fails already if the drone is somewhat 200 m away. The video signal also has also a strong time lag. Flying the drone visually becomes difficult, the further the drone is away. One can hardly recognize the orientation and movements of the drone. Wind and close-by obstacles are threats, so the terrain has to be chosen carefully. Many terrain restrictions apply due to EASA rules, so picking a suitable location is not easy. The tests will eventually need some wind, maybe 3-5 ms would be good conditions. First flights should be with wind <= 1 m/s. The drone is heavy (~ 2kg) and exhausts the battery in about 5 minutes. The radio controller has pre-programmed switches for “return to launch” (not reliable without gps) and “land” (AGL detection for landing based on barometer assumed to be rather safe, manual fine tuning seems possible).
ArduPilot Specifics
I think I know 2 ways to serve a scenario based on AduPilot without GPS:
- visual odometry, demanding high frequency relative updates. Rather unsuitable for my positioning due to the update frequency.
- external GPS, demanding less frequent updates. This is the currently envisioned method. A while ago I did tests with this method and found following:
-
ArduPilot parameters need to be set correctly for this case, otherwise the drone will not arm
-
feeding external GPS positions in frequencies no less than 10 seconds seemed to keep ArduPilot in working mode. In case no visual position is available in that frequency, a position derived from ArduPilots local_position, converted to global and tagged with high HDOP is sent (unmodified feedback just to keep the EKF happy)
The “no-gps arm” tests were executed with the drone on the ground in the basement. The drone was armed and the props spinning for 20 minutes (testing the absence of any ArduPilot triggering safety mechanism) – with the pipeline feeding back only the EKF output as external GPS. This scenario was a while ago and needs to be achieved again.
Analysis Concept
Assuming any kind of flight without gps and the positioning pipeline issuing corrections, what do I get? I will have flight logs from the RPi, but now I lack true positions and will not be able to judge the algorithm. It seems, I can possibly extract the sd card from the pixhawk, extract the BIN file and somehow be able to correlate messages from pixhawk with messages from the RPI - since both computers have no common timebase, maybe unique message content can be used to sync up? If this can be solved, I might also get the pure GPS (or even gps enriched EKF?) positions (EKF being probably << 1m and raw gps << 8 m)? I don’t know whether ArduPilots EKF maintains and logs these for internal purposes if GPS=off or external – at least the GPS receiver is still connected and working. I have already a visualization tool which can then replay the rosbag from the Rpi. If I can get an approximate true position from the ArduPilot BIN log, one might envision a tool, replaying the flight, showing the true drift position, the false EKF and the corrections applied.
Flight Concepts
The overall goal of the flight concept is to remain crash free. The conditions supporting that seem to be:
-
drone stays in vicinity (flight height 50 meters, horizontal distance max 100m)
-
area without crash obstacles or unsafe landing spots (trees, houses, lakes)
-
2nd person spotter in wind direction indicating that the 100 m boundary is passed
-
backup methods: initiating instant landing maneuver via radio control
Initial Flight – No Feedback Loop
For the initial flight, feeding back positional corrections seem too risky. Therefore the setup would be:
-
configure drone for gps=disabled and no external gps source
-
flight plan will probably not work under those conditions
-
fly drone to altitude 50 m AGL at launch position and switch to AltHold (that should work)
-
let the drone drift
-
after 50 m drift fly back and land or land at location
-
analyze EKF positions, true positions (if available) and reactions of the visual positioning system
More Advanced Flight Plan – Including Positional Corrections
Once I feel comfortable with the positioning system I might do flights including corrections:
configure drone for gps=external source
-
flight plan will probably work under those conditions
-
create a simple flight plan, maybe also just loiter above launch to start with
-
fly drone in Auto mode and observe
-
if exceeding 50 m drift fly back and land or land at location
now I get the complex interaction between ArduPilots EKF and the visual positioning system)
Questions
-
Does the above written sound right
-
Does ArduPilot allow pre-planned flights using external GPS
-
what can be used to sync up Rpi and Ardupilot logs based on messages
-
what options for extracting a close-to-true position from ArduPilots flight log if gps=off (e.g. pure gps, shadow EKF, not available). If such features are not available I might install a secondary GPS receiver directly to the Rpi instead.