Copter-3.6.0-rc12 available for beta testing


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.

All the best

1 Like

We definitely recommend setting compass-learn to 0 on copter so if it’s getting set automatically to something lse by a page in MP we should raise an issue with MP…

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.

Just got round to having another look at this, turns out it works fine just the serial ports are in a funny order.

1 Like

I try to reorder and test them all…but GPS and other serial things dont works…

I have TX3 and RX3 is serial 1 and TX4 and RX4 is serial 2. You will have to do a full power cycle after you change any serial params.

Anyone know if the OSD for omnibus boards has been fixed in this release?
If not, should I assume it will not be implemented for 3.6?

I think rc12 code was not compiled using current correct hwdef file for kakute f7.

1 Like

Randy, what exactly code does now if compass-learn is set to 2 - EKF learning?

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,

1 Like

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 am using MP.1.3.58 and FW 3.6.0-RC12.

Thanks in advance.

Hi all
I upgrade my small 250 quad to 3.6.0-r12 from 3.5.7
I performed autotune but. I notice problem when copter is in loiter mode and I try yaw copter rise and down. ( 2-4 m)
Did anyone notice a similar problem

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.

Hey All,

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?

Many thx
I have INS_ACCEL_FILTER = 20 and PSC_ACCZ_FILT= 20 I will try to set it to 40

Hey all,
The logs for the above question I had

When seeing the logs, i noticed it increases temperature sharply when changing modes, and it is at 80deg Celsius.

If anyone could help.

Logs for Overheating