Thanks @rmackay9. The external compass is one of these - https://store.mrobotics.io/product-p/mro-ugps-samm8q-01.htm - the reason it’s disabled is that the z-offset is over 1000 and so will not calibrate. On this compass the direction arrow points the wrong way so its mounted backwards, hence the orientation. I’ve tried many orientations, but this is the only one where the mag settings move in the right direction. I can try again, but not hopeful - really need to return it. The internal compasses are right above the PDB - no chance of moving them 
For the x-vibe, is it possible this is down to the relative aggressiveness of the props (4x45 bullnose) on such a small frame?
I’ll try again with more time before takeoff - any pre-arm setting I can use to enforce the accuraccy?
I have an issue with external compass (already reported in another thread but still cannot solve that).
My external compass stops working just after a 5-10 seconds after a power on.
The weird thing is when I do a soft-reboot via MP (CTRL+F => Reboot Pixhawk) then after a reboot compass does work flawlessly.
This two cases are 100% reproducible and only on Chibios. Tried with two different TS100 mini compasses.
I suppose it could be an interference problems due to some wiring specifics, but why it does work after a soft reboot? What is the difference?
Could someone please check the logs?
@andyp1per, it is sometimes possible to calibrate/use a compass with larger offsets by setting COMPASS_OFFS_MAX to a larger number (like 1500). I don’t think the current orientation is correct or perhaps it’s just broken. In any case, with recent release candidates the auto discovery of orientation is active so it might figure out the correct orientation if you try again.
I’m not too sure of the cause of the x-vibe… could certainly be the props though…
I think I have found the problem … There are some errors in the hwdef.dat (Matek F405 target)file i try to fix and build a firmware from source.
I have also had this problem the the F405, I couldn’t get any serial ports to work but not but had a chance to have a proper look into it yet. Would be great if you could do a pull request for your fix.
When upgrading from RC-5 to 12 to test the new firmware I received this error on my frog hex. mRo 2.1.
Error: no firmware for this board.
I assume that I can use copter/beta/mRox21 as a downloaded file?
Regarding the mRo v2.1 ok got it to work using the download.
You need the .apj file…
sorry, I’m no expert at this stuff, I cant see anything obvious, what is the exact error? I will compile and see if it fixes it.
Look at USART2 and USART3
they have the same value…
We need to change in Usart2 the usart3 incorrect value…
USART2 is commented out as the RX pin is used for RC in.
Brandon,
Thanks for the report. I think this means that MP isn’t recognising the mRo bootloader so I’ve created this MP issue.
Sergey,
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
@andypiper,
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.