thanks for your insight.
The problem: For now, we should relocate your Post to the category “Rants and Raves”, because it is not objective at all.
But I really want to hear your full story, because you seem like someone with lots of professional experience in the area.
So be so kind and add some more info like:
Used flight control
Used frame
distances between motor wires and compasses
In addition to that one or two log files can help too…
For example: Flight near big industrial machine.
You are reporting things that are problems for you but not for me or my customers and some of them travel around the world for mapping.
DJI is a close system with a majority of standard products flying while with Arducopter a bad design can affect heavily the performances of the autopilot compass.
With software you can decide to mask compass problems and rely more on the GPS and IMU for heading but that does not means that you do not have a problem with compass in harsh environments.
A lot of problems with Arducopter comes from the fact that there is around low cost and low quality hardware with no quality control at all buy serious hardware , design properly your copter and all compass “problems” will disappear, after 10 years now, dealing with multirotors , that is the lesson I learn.
1: “unproblematic” ?? - it’s most often the cause of warning about GPS/compass, because DJI don’t even tend to know what is wrong, when it is.
2: you must have been drinking. - or are just trolling - DJI stuff tends to fail regulary on Svalbard.
3: ??? this has to be more than drinking, autodec is a simple lookup, never fails.
4: because there is usually no need for calibration, certainly not in “other countries” because magnetic field does not care much for borders. I often fly on destinations more than 2000km apart, not recalibrating.
I think you need to check your build quality and assembly, more than posting such crazy statements.
Anybody who has flown DJI’s equipment is familiar with the DJI Compass Dance.
The usual problem in ArduPilot is hardware that has too many mag chips and they don’t all agree due to mag fields especially around the internal chips in the FC. We don’t know about the setup of the OP, but usually disabling the extra mags is required in electric aircraft due to onboard mag fields. I have only been able to use all mags in piston powered helicopters that don’t have intense mag fields caused by motors, ESC’s, wiring.
You calibrate the mag with the ArduPilot system once, it’s good unless the mag chip fails, even if you switch hemispheres. So posting your parameter files, or a log file that contains a demonstration of the problem will help, as our more experienced users can point out problems in your setup, or the dev team can take a look at it if there is indeed a problem in the code.
Since coming back to ardupilot after a long hiatus the one thing I found really refreshing was how stable the compass after a cal was/is. Calibrate once and leave it alone and this is on my own design gps/mag board. LIS3MDL mag.
I’ve heard the complaints about the compass calibration from other users as well including at the recent Shenzhen drone conference.
My guess is that the issue is normally the internal compass which is often placed very close to power wires and so it gets a lot of interference. This causes problems both for the calibration procedure (the internal compass’s field won’t be spherical) and the pre-arm check (which can fail because the internal and external compass face in different directions).
We could disable the internal compasses by default but I fear then that we will face a wave of crashes soon after takeoff because some users will have their external compasses pointed in the wrong direction.
By the way, we hope to get some funding this year (about 50k USD is required) to improve the EKF’s ability to determine it’s heading quickly even when the compass heading is off. This might allow us to loosen the checks up some more.
As a side note, I don’t generally like to compare vs other systems but I think the ready-to-fly vehicles have the advantage that all the vehicles are all the same and built after many man years of iterative testing so they don’t need to perform as many checks as we do. Our user base has a wide variety of frames of varying build qualities. As we loosen checks, invariably some portion of the community starts crashing.
In my experience it’s internal compasses (plural). Even the internal ones never agree if there’s more than one. One internal mag chip in the controller is sufficient, putting in two or three only creates more problems with calibration and drift. This supposed “redundancy” looks good on paper, in the real world it don’t work.
The majority of users are disabling the internal(s) anyway to get rid of inconsistent compass errors.
Hi, Normally I use internal and external compass but I have very little steel in the crafts i make. once and awhile I need to turn one off to debug and then back on as soon as possible. recently I noticed I could make fine adjustment in MP to get it spot on North within a degree.
I generally agree that community members here have spent countless hours tracking down compass issues. I am one of them. Compasses are on nearly each and every vehicle, and it’s really not that difficult to auto-detect compass orientations if a vehicle can be moved around just 2 axes.
I’ve heard of numerous users with huge vehicles that can’t do full rotational calibrations. I think it’s more of a wizard issue than it is an EKF issue.
Absolutely, it’s not an EKF issue at all. It’s mag fields in the vehicle and the fact those mag fields are dynamic, the hardware has too many mag chips and it’s hard to get them all to agree. We already have a COMPASS_LEARN feature that can apply offsets learned from the EKF state estimator. I’m not sure how well that works as I’ve always left it disabled. So I’m not sure if that can replace a compass calibration in large vehicles where it’s about impossible to calibrate the way the wizard wants.
It appears that the in the fmu v5 designs, they are going back to only one mag chip in the controller. Which makes it much more reliable and easier to identify compass issues during calibration and setup. And less chance of getting the inconsistent compass errors. The most reliable hardware to-date from a compass standpoint was the old APM2.6 that had no internal mag at all. And the further development of those boards from the aftermarket that put the internal mag back in, but have a hardware jumper to enable or disable the internal mag. As the system has gotten more complicated and somebody decided it would be a good idea to bolt in more mags, the compass problems have increased accordingly.
I am new to Ardupilot and Pixhawk Cube. I was truly impressed with all the software and hardware but compass issues damped my joy of the ecosystem. I didn’t know that the internal compasses on the Cube were effectively useless because of all the required wiring and nearby accessories. It also took me some time to realize that I had to reboot the pixhawk before the EKF would take new compass settings (at least that is my experience). Once I turned off onboard compasses and used only a good externally mounted compass and rebooted, everything was good. Unfortunately I wasted a bunch of time mucking around with settings that seemed to work for short periods of time and then would fail without notice.
I have a 150lb rover, so all the community suggestions about recalibrating the compass were useless to me.
Thank you all for this great solution and community…
This is really the correct path to take. I’ll make absolutely no comments for/against the OP’s comments because i have nothing intelligent to add there.
However, in aviation, the Compass is simply a backup instrument, and only barely relied upon these days (I’m not counting civil aviation). Of course it is still important in aviation because runways are based on mag azimuth, not true.
When performing an inertial alignment, the TRUE HEADING is an absolutely requirement…not mag heading. You typically also give it an initial position, but that typically is just for the purpose of more quickly obtaining an alignment. If you don’t, then when your alignment completes, you will have residual accelerations.
The key here is that the heading for an aircraft is providing by the operator manually, every time! (And the initial position provided by GPS, if available, or manually from poshacks)
Once the EKF properly accounts for an initial True Heading, a proper INS will maintain heading way better than the compass, because it won’t be subject to interference from ElectroMag sources.
I would appreciate some help.
My compasses are incosistent too.
I use CUAV v5+.
What I tried:
calibrate the system at least 50 times.
meanwhile changed the placing of CUAV and NEO v2 several times.
cabling:
as far as possible from cuav.
read and black cables are lead parallel. Other cables are twisted.
if possilbes cables are perpendicular to cuav an not parallel.
If I calibrate the internal compass is usually in the red (or upper part of yellow) with Qground control - which shows the calibration quality. Next day I can see incosistent compasses prearm message.
I tried to check the logs:
I can see the ATT.YAW, but can’t see the MAG.heading, nor MAG2.heading info (just Mag(2)X, Mag(2)Y, Mag(2)Z)
How can I check the heading info of the compasses compare to GPS heading or IMU heading?
so is there any possiblity to visualize the compass real life quality?
What to do (I know disable the internal compass - but before this would like to see the real performance)
Thanks
Szabolcs
Are you already using copter 4.0.4-rc3? If the compass order changes you most probably get inconsistent compass prearm messages. That is fixes in 4.0.4-rc3
Have you got a .bin log file? Make sure you’re on AC 4.0.3 (latest stable).
You can disable the internal compass, then let the craft get a good solid 3D fix and calibrate using just the external compass. Try relaxing the fitness too.
Even with the internal compass disabled (not used for flight) its data is still recorded, so we can look at it in a log file.
Edit: I’ve got a CUAV V5 Nano and Neo V2 and they’re working great.
Soon I can upload the logs to a public place and publish the log. Yes I have the 4.0.3 (- although don’t know if which version is perfect for CUAV v5+. The fmuv, or the CUAV v5.)
The CUAV v5 firmware will be best, it’s essentially the same as FMU v5 but has some slightly different defaults in the hwdef file.
Disable the internal compass - go outside and wait for a good 3D fix then calibrate the compass.
But compasses are not your worst problem - there’s stability and vibration issues to look into first. I suggest you open a new thread just for getting this craft going properly. Need a lot more details about the aircraft, and probably a couple of photos.
For example the second flight in that log, the vibrations are already higher than in the first flight - something changed between flights.