I have been flying an FPV drone using GPS only, without a compass.
So far, I have mainly used flight modes that do not require position control, such as AltHold and Stabilize. This also allowed me to avoid compass calibration, which I sometimes need to perform when changing locations.
However, in preparation for RTL, I changed the following parameters:
COMPASS_ENABLE = 0
EK3_SRC1_YAW = 8 (GSF)
According to the ‘Compass-less Operation’ documentation, flying in AltHold allows GSF to estimate and correct yaw, after which position-require modes such as Loiter can operate stably.
What I am wondering is:
If I attempt to switch to a position-need mode (such as Loiter or RTL) before GSF has completed yaw estimation, what would happen?
Since I excluded the compass from the arming checks, I assume the drone will still arm even in Loiter mode. However, actual flight behavior may be a different issue.
Would the drone attempt to hold position while failing to maintain heading?
If GSF completes yaw estimation while the drone is already flying in Loiter mode, how would the vehicle respond at that moment?
if a drone is unaware of its heading, it cant really hold position because it wont know the direction of correction.
Others might be able to correct me, but i would recommend you to put some compass. they are small and you can buy in the form of seperate modules. rm3100 is best, ist8310 works but i guess a qmc5883 is better than nothing atleast
I may be misunderstanding this, but as far as I know,
Betaflight’s Position Hold is able to maintain position even without a compass.
I was wondering whether a similar case is possible in ArduPilot as well.
Although I am using a GPS module with a built-in compass, I intentionally set COMPASS_ENABLE = 0 due to frequent check mag field errors.
The magnetic interference from the motors and power system is quite severe.
I know that this can be improved using Compass/Motor Calibration, but in my case the compass is not essential, so I chose to disable it.
after booting, it doesnt know its orientation. so on immideate takeoff without previous althold, it might initially correct wrongly but then should work fine.
You could try magift if it helps.
please correct me if i am wrong, but if you do direct loiter/similar takeoff, it might do 1-2 wrong corrections and then should hopefully work.
I would guess if You switch from alt hold to loiter without heading it will actually stay in alt hold.
Also keep in mind GFS works fine when flying and position changes. Hoovering in single spot, after a while due to gyro drift, will get worse and worse and might result in some increasing toilet bowling. Theoretically after doing some circles gps changes position and should get heading corrected, but I have not tested that.
Personally, I use GSF only to do magfit flight in loiter, and after all that switching to compass. No issues so far doing it this way.
Difference is that I do not disable compass by COMPASS_ENABLEonly by COMPASS_USEto have compass working and data logged for magfit tool.
From my experiences I would strongly advice to use IST8310 instead of qmc5883. IST based seems to behave more stable for my builds.
ist8310 is far more stable, and qmc5883 can give noise. but, most fpv gps (atleast the ones i have seen) use qmc/hmc chips. also finding ist8310 modules is quite rare, and qmc modules are flooded in the market.
you could even move the gps away, as many other users have done.
How is your information evaluated?
For example holybro is using IST8310 on most actual GPS modules.
Also, did you read the information linked by @jindrone
So, compass less GSF mode is in general possible if all conditions are correct. Yonguk Jim don’t asked for takeoff directly in loiter mode.
The most problem is the accuracy of the GPS heading information and the stability of the gyros.
The GPS needs to move than it can calculate a heading. Without movement it is impossible to calculate correct heading information.
I am currently using a GPS module with a QMC5883 compass, which I understand is not very reliable. I will consider using a compass based on the IST8310 instead.
As @Adam_Borowski mentioned, I also expect even when yaw is not yet aligned, it seems that the drone can still fly in Loiter mode using the yaw estimated by the IMU, similarly to AltHold.
However, if the drone hovers in single spot, the toilet-bowling may become more pronounced.
Naturally, once yaw alignment is completed, the compass-based yaw heading would take priority over the IMU-estimated yaw degree; otherwise, there would be a conflict between two.
In situations without telemetry, I thought it might be possible to accidentally switch into Loiter mode before GSF has completed yaw alignment, so I asked this question.
It can not (assuming using GPS for position). For loiter You need heading and IMU yaw gets aligned to that.
If Yaw is not aligned You will get toilet bowling. GSF uses gps to determine heading and as soon heading is estimated IMU yaw gets alignet to that, and then You can switch to loiter.
Imu is used for smoothing data of compass and high frequency correction
To correct in loiter you need to know the heading relative to earth magnetic field to correct, imu gives relative heading with significant drift. Basically your imu can give that on boots its zero, and now after some rotation it is x degrees, but the zero isnt north direction, it can be anyrhing
However, without velocity, GPS course becomes unreliable, and IMU only estimates drift quickly. So a stationary loiter is likely to degrade somewhat quickly.
Betaflight recommends a compass for their newish position based modes for the same reason.
Exactly my point. With GSF you need to fly in some direction to work good. That is what I wrote. First symptom of yaw and heading misalignment seems to be toilet bowling in loiter.
So, in the end, it seems that the vehicle needs to move and allow yaw alignment to complete before switching to position-based modes such as Loiter.
If Loiter mode is selected accidentally before yaw alignment is completed, does ArduPilot prevent this automatically?
For example, similar to how arming in Loiter mode is blocked when GPS HDOP is too high or when a 3D fix has not been achieved.