Hello!
I am convinced Navio2 is a superb product. I even bought 2!
BUTā¦
I used and tested my 2 boards in flight for several hours on 3 different configurations (F450 frame, AQ600 carbon frame, full 3D printed frame, RPi 2/RPi 3, w or w/o telemetry by 433Mhz, AP Wifi 2,4 and 5 Ghz, Joystick and RC control, w or w/o servos and relays, w or w/o EPM grabberā¦)
And I ALWAYS had difficulties with internal compasses issues (slightly improved from Arducopter 3.3 nevertheless). Even when this is well calibrated, it sometimes come to unpredictacle behaviors in flightā¦ most āshittyā one being EKF issues while in autonomous missions far from Launch base.
And I had sometimes limited GPS performance esp. in cloudy weather (HDOP rarely below 1 and glitches due to MCX connector on one of my boards)
I solved my compass and GPS issues by de-activating internal compasses and using an external GPS+Compass connected trough UART+I2C, which is a bit hacky consdering I am obliged to use USB port for 433 telemetry and cannot use any other I2C device anymoreā¦
What about having a āNavioMiniā board having one additional pair of I2C+UART ports, and leaving away internal GPS and compasses for external ones (assumed to be more reliable due to less interferences)? I am pretty sure this could help decrease manufacturing costs significantly and make the Navio boards more robust.
Just an idea like thatā¦ I am today very happy with Navio2 and will continue to be !
Second thatā¦ sitting on top of a hot processor and big pieces of various metals is probably the main challenge of any autopilot HAT. Still, you could always use a ribbon cable of limited length to get more space between the two. Especially with 3D printer access, you could probably mash-up a case with a good gap.
You could even add some sort of ground plane/isolation on top of the mainboard (heat and interference source) to even-out the compass calibration, or go for the extreme and make it a heat sink like my wacky idea for the Pi Zero here: New Raspberry Pi Zero... Will It Work? - #26 by CodeChief
I will start by connecting 2 header pins in a row to give my navio 2 board an additional 10mm of space with my RPi board. Iāll let you know if I can get my internal compasses in the mission planner āgreen zoneā
in the log called 2017-01-17 10-56-16, my 3rd take off is done in PosHold (take off at 11:07 if looking at Altitude parameter, just before the EKF-CHECK-2 error). This is the one where I have had a fly away.
By the way the aircraft did not detect its crash and was continously attempting to fly even on its back on the ground. (same situation on both fly aways I have had after PosHold take off)
Here is my interpretation:
-Take Off in PosHold
-EKF CHECK error due to high magnetic interference with compasses (high current)
-Automatic switch to Alt Hold (I changed the default value since LAND can be dangerous in remote autonomous missions)
Loss of heading (quad turning clockwise around himself) ā as I use āsimpleā mode commands are not properly interpretated
Wind pushes the drone away while I cannot attempt to recover control
ā¦but RTL should in this theory have worked? Shouldnāt it?
first of all:
you can use an i2c distribution board (i2c hub ) to use multiple i2c devices and you can use usb to serial converters ( like this ) to use multiple UART ports;
RTL shouldnāt be triggered when EKF gives an error; RTL relies on GPS, Magnetometer and IMU - it could worsen the situation;
looking at your logs:
it seems that your copter is very very misbalanced; while motor channel 3 and 4 are on the upper limit motor 1 and 2 are very low; (channel 1 even reaches itās lower limit from the autopilot - if i interprete the logs correctly)
i believe that fact leads to unpredictable behaviour - such as unwanted yaw movements and other stuff;
so first of all i would take care of that issue! (i donāt believe your compass is involved in your problems at all) it could be weight misbalance - or loose props or bad motors or maybe uncalibrated ESCs !
afterwards calibrate your PIDs and if still necessary do motor-compass calibration!
Very interesting feedback, @panky thanks for taking the time to analyse
I did look for motor data in the flashlog but was apparently too noob to find it (I also checked in mission plannerās doc). Could you please let me know what parameter name to look at?
You are right the prototype I used for this flight is unbalanced with a gimbal positionned rather in the front instead of a central position in the bottom of the quad. This is for test purposes.
Up to now the quad was still flying well in other situations therefore I am a bit surprised this can lead to unstable yaw or GPS hold. By the way I only had this issue when taking off in PosHold (no other issues if take off in AltHold or Stabilize and switch to Loiter or PosHold afterwards)
I will use Autotune to calibrate the PIDs but it seems it is not selectable in flight as a āconventionalā flight mode. Everytime I ask for autotune from the GCS the quad doesnāt change its flight mode. I will probably try using CH7 option in MP.
I will do motor-compass calibration afterwards if this doesnāt solve my issue, thanks
RCOU is the parameter for PWM channelās output from Navio;
you need to be in Alt hold and then switch on autotune (in my case it only works with GCS - channel switch never worked); your copter will drift away - you can fly back to the middle of your flying field (choose a wide area) and when you release sticks autotune will resume;
Just to report : using 2 header pins instead of 1 was effectless on my compass calibration results.
With or without, compasses offsets remain roughly the same after mag calibration in mission planner
I did this calibration RPi + Navio board only, without any metallic or power cable around it (not mounted on the quad)
I therefore doubt increasing again the distance between the navio board and RPi is a potential killer for further magnetic disturbances. The compass performance of navio boards (as least for the 2 boards I have bought) seem to be inherent to the boards and not really to their environnment
