Is this what you are referring to?
Yellow arrow points front
And this arrow points to 9 o’clock or 270 degrees (not sure is this is the magnetometers)
Yes, I was referring to the thing in your second picture. The large white block in your first picture is the GPS unit. I was also a bit confused, because the thing of your second picture is right underneath the holes in the cover where I suspected the buzzer. But it is the only thing I can find that looks like a magnetometer and since it’s pointing to 9 o’clock, it would explain our problems with the 270-degree offset. Maybe Chris can tell us if we’re right…?
I have that same gps chip on some of my smaller 5" inav quads, so I knew the white block was the GPS.
I should check my neo v2 pro can GPS as well
@Felix, you are correct. That’s why the auto compass orientation wants to set it to that. It’s not a problem. As long as the software “knows” what the orientation of that chip is it will do the rest in the software.
You could try to “force it” to the orientation of the marking on the case, but the offsets will be very large. So just leave it at 270 like the software wants, it has the least offsets there. It will work fine.
After calibration make sure your x and y components of the mag output agree with what hemisphere you are in. Northern hemisphere z should be positive value. Pitch the heli nose down, x should increase. Roll it right y should increase.
Southern hemisphere, z is negative. and x and y should decrease (opposite of the northern hemisphere) with pitch down and roll right.
If that all looks good and agrees after calibration of the unit, you are good to go.
1 Like
Felix,
look at the bottom of the photo where the Heli is hovering. You can clearly see that the CUAV NEO V2 is mounted on the tail with the front arrow to 3 a clock and you see the green lights at 9 a clock.
The cable entry is confusing. Or even the opposite. Surely not front arrow to the front.
This should be in the manual that the magnetometer is fitted not in the flight direction, IMO, (but yaw270).
Yes, you are right. Interesting observation. The compass is definitely not mounted with the arrow to the front there. But we don’t know, how the COMPASS_ORIENT parameter is adjusted there. He could have mounted it any way he liked… And yes, you’re right. The manufacturer should have added a little note, that the orientation is yaw 270. That would have prevented a lot of confusion. By the way: I received such a note with the Here GNSS that came with my first Pixhawk 2.1 Cube. The funny thing about it: The Here GNSS doesn’t have an offset. It’s working perfectly with the arrow to the front and compass orientation set to “none”.
1 Like
Doesn’t make any difference who made it. I had a HERE one in Sept '18 that it took me 2 hours of fiddling around with it to get it to calibrate. It was Yaw 270. That was before the auto compass orient thing was implemented.
Again, it does not make any difference what the orientation of the chip is in relation to the arrow on the case. That setting is basically obsolete after the auto orientation feature was implemented. Just let it do what it does and it will work fine.
All those mag chips calibrate with offsets. Even if it agrees with the arrow on the case. Never seen one with calibration offsets of zero.
I have mine doing the yaw 270 as well did the rot to 0 calibrated and its till doin the yaw 270, is there something i should change or is the yaw at 270 just fine for flying(still building the hex)
1 Like
Just thinking out loud:
Power up the UAV NOT pointing north, connect to GCS and see if the HUD shows the true direction. Move the UAV around and see if the HUD follows correctly.
i only have mp conected to the pix and on mp map if its not pointed to zero it wont even show on the map
if i go to the tab as if i was gona do a mission everything moves so its just odd
Hi Aaron, it’s just fine, if you let MP automatically choose the orientation it thinks matches your compass the best. So 270 would be fine. I checked it with my setup too. Seems to work perfectly. You can check that by simply pointing your aircraft towards a large distant tree or in parallel to a building etc. Then check if the aircraft symbol on the map shows the same orientation. Try that for different orientations (not only one). If that is working fine, you should be good to go.
ok thanks still going through pages of stuff trying to get this new setup ready to fly
You’re welcome. Ask me, if you have any problems.
I have been flying with the CUAV FC and the Neo GPS. I have never looked at this setting before, and never ever had an issue. So arducopter is clearly dealing with the 270degree offset quite well
I just wonder if CUAV dumps FC like my V5 nano who not match quality control onto other sellers like http://www.thanksbuyer.com where I got my CUAV V5 nano incl. the GPS NEO V2 very cheaply from.
Be aware of this website. If you google they have a not very good reputation. http://www.thanksbuyer.com
But PayPal is still supporting them. I had to wait a long time for the delivery. ( hassle because of the virus and poor communication of the seller)
But now to the product:
The GPS has the compass not in the flight direction mounted. Not a problem because AC 4.0.3 is finding that out during compass calibration.
But the internal compass is also wrongly mounted. The internal compass is not possible it relates to the FC mounting direction.
So my internal compass redundancy is useless because of the wrong internal mounting.
I did over come this by mounting a second external GPS unit incl compass.
My calibration is now 2 GPS and 2 external compass units and it is working perfectly.
But extra weight to the aircraft.
Now I repeat my first question. Is CUAV dumping rejected FC cheaply like to http://www.thanksbuyer.com? Or are there bad clones on the market?
I don’t know about thanksbuyer.[com]. I order all my CUAV products directly from them. I am in the USA and it takes 3-4 for them to get delivered using DHL. I have have zero issues with any of their flight controllers and I have about 9 of them.
That is what I would recommend. My first CUAV FC was a Pixhack v3x with GPS direct from CUAV. That FC is flying my TREX 600 with camera gear. No problems with the Heli setup and compasses.
I stumbled onto that website above and was seeing that very low price. After ordering I started getting to nowhere.Than I found a hint on the Internet that I should go onto ebay and find the same sellers name as above but with the word hobby behind. I did that and they at ebay answered my question immediately and the parcel arrived 2 weeks later. But the FC has those compasses wrongly mounted. I do not want to go on with this any further. Just to say now go and find the sellers for CUAV FC at Ardupilot.org and do not do what I did.
It will calibrate with excessively high offsets if the internal mag chip is oriented wrong. There is no real redundancy from the internal mag chip anyway. They are unusable in most cases due to local magnetic interference. We do not fly a single helicopter with the internal chips enabled - you will invariably get compass errors
CUAV only has two official stores - their own and their store on AliExpress.
We have used the V3x on our helicopters until this year when we switched to the Drotek Pixhawk 3 Pro, which is made in France. I am also using a custom-built linux-based autopilot running on a 64-bit A72 quad-core processor for one project. I require an I/O so have never even looked at the Nano.
My development focus will be on linux-based systems for the future, as ChibiOS is not suitable for our use and the market has been flooded with low-end STM32-based microcontrollers with no I/O. These are ok for hobby, but not suitable for commercial use. Since the divergence from the PX4 hardware specs I do not agree with ArduPilot’s focus of being able to run on any low-end unit that hits the market - it is bound to cause issues with quality and reliability. The specs on these low-end hobby-grade controls change with the wind. They are here today, gone tomorrow as everybody jumps on the next fad from STM32F4 to F7 to H7, yadda yadda.
I have found that running the code on a linux-based system where you have a real shell to interact with and diagnose problems in the subsystems is a much better long-term solution than microcontrollers. Linux can be ported to run on like STM32F7 with full-blown linux kernel with RT patches. But the F7 is woefully underpowered to do some of the things we are going to do on 64-bit multi-core A-series processors running at clock speeds in the GHz range and with memory in the GB range.
So I would say to expect “issues” with the fad-driven hardware development going on with STM32-based microcontrollers.