Thanks for the report. So looking at the logs it seems like in the BAD log it is detecting a QMC5883L compass on second (which i think is the external i2c port). Looking at the mRo product page, I don’t see this compass there so perhaps there really is no QMC compass and so the driver fails and we get a compass error.
A temporary solution is to set COMPASS_TYPEMASK to 4096 to disable that particular driver. I’ve add this to our list of issues.
Thanks @rmackay9! Setting COMPASS_OFFS_MAX to 1500 allowed me to calibrate the external. I also tried autolearn of the orientation and it works - but came up with the orientation I already had - yaw180. Not sure how it will fly but the EKF monitor stays green while I swing the copter about, so fingers crossed.
A couple of things I noted while doing this - COMPASS_LEARN, which I set got set to 0 when I calibrated - is that expected? Also it seems setting this option in the calibration page sets it to 1 which apparently is not recommended for copters? Maybe a MP bug?
I’m a bit late, I know, but in response to the comment in the rc11 post, that
I’d really appreciate it if people could remind me of issues they have seen in recent release candidates that they have not received satisfactory explanations for
I’d like to remind that there are plenty of bugs/issues in the Mount section, many of which are existing for years. Satisfactory explanations are known, but no action was taken yet. From scratch I recall:
Nonsense gimbal orientations sent out at startup if no receiver connected. There must be several issues and at least one PR, with several working solutions proposed.
Update rate slows down to 1sec for certain situations relevant in practice. A solution had be proposed somewhere.
Mount Mavlink messages handled incorrectly. Issue was raised. Introduced in 3.6, I think. A solution had be proposed somewhere.
AP sends inconsistent pitch&yaw angles under certain conditions. AFAIK no solution yet proposed.
Sorry I wasn’t clear @rmackay9 . If you tick the box (which I did) it gets set to 1 (mag learn), but the docs indicate only 2 (EKF learn) is valid for copter - but it sounds like you are saying neither is valid? In which case the docs are wrong. Maybe MP should disable this setting for copter.
Hi Randy, thanks for the looking at the log. Yes it is an external compass (Radiolink TS 100 mini that has QMC5883L chip). So the driver was detected correctly I think.
Unfortunately I have no idea of what I could check further, I have two TS100 units, both not working on Chibios. And works not very good on NuttX, having strange peaks I’ve described in Compass stop working but remains healthy
I’ve disabled all the peripheral devices to avoid interferences but that did not solved the issue.
I will also check on v3.5.
@rmackay9 here’s a new log with the compass calibrated, I was just hovering. The EKF Mag innovations are all zero as I reported in another thread. Could this be to do with using the compass with the large offsets? It seemed to go away when I excluded the external compass.
Cannot get Mavlink telemetry to work on any of the serial ports. Using the Matek 405CTR Tried UART3 (Serial1) and UART1 (Serial3) neither work selecting protocol 1 and Baud 57. If I flash with Arduplane using same serial parameters it works fine and the crossfire picks up all the telemtrey. Is this a bug? Thanks,
BATT FAILSAFE - I could not find the options for BATT_FS anymore. The parameters are available on the full parameters list (MP), but it´s blank at the tab Mandatory Hardware - Fail Safe configuration. I am still able to define the voltage and mA limits, but not the ACTION. The Radio_FS is OK.
PHLD_BRAKE_ANGLE & PHLD_BRAKE_RATE seems to be ignored. I have tried high values, but the behavior did not change at all. The drone brakes very slowly after release the sticks (in PosHold). It drift about 3 to 4 meters before stop. DZ and TRIM were checked and are accordingly.
I had problems similar to this, setting INS_ACCEL_FILTER and PSC_ACCELZ_FILTER to higher values fixed it for me (I am using 40). It could also be a baro problen, but I guess if 3.5.7 works fine then maybe not.
I noticed this weird interaction in my Pixhack v3 running 3.6.0-rc12, where it seems to be overheating, or something cause after a flight, i touched it and it was so hot, it almost burned my finger. Is that normal? Or am i just being weird?