Thanks for looking at this @tridge, one thing that still confuses me (I’ve been watching your Log Analysis video), is why the Euler Pitch State values are so consistently different for the two lanes. Does this mean anything? (and if so …)
There is a small accelerometer bias difference on the X axis that will explain some of this, but I suspect the main cause is the bad compass calibration.
One thing a lot of people don’t realise is that the compass can impact attitude. Your 2nd compass (which is the only one enabled with COMPASS_USE2) is a long way off. That will impact pitch accuracy.
The compass is clearly affected by motor current. You should either move the compass to be further from the wires, or use the COMPASS_MOT parameters to compensate. The MagFit tool in MAVExplorer can do that.
Here is a MagFit run for your log:
- COMPASS_OFS2_X 27
- COMPASS_OFS2_Y -29
- COMPASS_OFS2_Z 838
- COMPASS_DIA2_X 0.990
- COMPASS_DIA2_Y 1.008
- COMPASS_DIA2_Z 0.937
- COMPASS_ODI2_X -0.007
- COMPASS_ODI2_Y -0.117
- COMPASS_ODI2_Z 0.065
- COMPASS_MOT2_X -0.247
- COMPASS_MOT2_Y -12.425
- COMPASS_MOT2_Z 7.533
- COMPASS_SCALE2 1.00
- COMPASS_MOTCT 2
Notice the large values for COMPASS_MOT2 indicating a lot of interference with the motor.
1 Like
Thanks mate. As an aside, I tried running the MagFit tool, but it wouldn’t run - this is what I get. Notice the buttons for “Processing” are outside the MagFit dialog and it’s not resizable or scrollable, so I can’t actually “Run” it.
I’m running Ubuntu 22.04 in Parallels on my Mac, so the Python is 3.10.6
Aha! So a big problem here is my compass(es). I had wondered about that. I really don’t understand how it can be the motor because it’s a twin with both motors and ESC’s out in the wings - ah the wires, that might be it.
I’ll take another look at that. Ta!
1 Like
4.3.3beta1 flights with 2 airplanes (QUAD VTOL, Mateksys F765 and fixed wing, Mateksys H743) in QHOVER, FBWA, AUTO, QLOITER, CRUISE, MANU and scriptgenerated Waypoints no problems at all.
Thanks to Tridge and other developers.
Rolf
2 Likes
Here’s another screen shot of the MagFit screen from Ubuntu 22.04 running on a new install on bare metal. I’m running MAVExplorer.py 1.8.59 from a clone I took direct from GitHub on the weekend. Also python 3.10.6
thanks Rolf! much appreciated
I’ve just released plane 4.3.3 stable. This is a minor release, and likely the last of the 4.3.x releases unless a serious issue is found.
Changes from 4.3.2 are:
- AIRLink LTE module enable pin added
- CUAV Nora/Nora+ bdshot firmware (allows Bi-directional DShot)
- CubeOrange, CubeYellow gets fast reset of ICM20602
- PixPilot-V6 support
- Attitude and Navigation controllers use real-time dt (better handles variable or slow main loop)
- Analog rangefinder GPIO pin arming check fixed
- Arming check of AHRS/EKF vs GPS location disabled if GPS disabled
- Position Controller limit handling improved to avoid overshooting and hard landings
- PSC_ANGLE_MAX param reduction causing WPNAV_ACCEL to be set too low fixed
- Servo gimbal yaw jump to opposite side fixed
- Siyi A8 gimbal driver’s record video feature fixed
- SToRM32 serial gimbal driver actual angle reporting fixed (pitch and yaw angle signs were reversed)
- Takeoff in Auto, Guided fixed when target altitude is current altitude
- Takeoff in Auto handles baro drift before takeoff
- Takeoff twitch due to velocity integrator init bug fixed
- moved FTP MAVLink transfers to FTP thread and better control bandwidth
- switch to QRTL if indide RTL radius when using Q_RTL_MODE=3 (approach)
- check for 3 good frames for CRSF
- allow for ELRS at 420kbaud
- support MambaH743-v2
- support MambaF405-2022B
- fixed nullptr checks on new
- fixed a bug in terrain handling for ship landing lua script checks on new
Many thanks to the following people for contributing to code, documentation and testing of this release:
- @andyp1per
- Siddharth Purohit
- @hwurzburg
- @iampete
- Kirill Shilov
- @Leonardthall
- Moe Bataineh
- @peterbarker
- @rmackay9
- @xiao
- @timtuxworth
- @Rolf
- AraceUAS
- @Quadzilla
- @xfacta
- @ThePara
- @Luke_Ionno
- @Alberto_Ds
Happy flying!
6 Likes
So finally if a qplane has a failsafe inside RTL radius will not perform transition and will remain in quad mode isn’t it?
yes, I know this has been wanted for a while, sorry for the delay
More than wanted, was a safety concern. Thanks again for the fix 
Will it do that even if Q_RTL_MODE is not 3 (approach)?
If not, I don’t think the feature request/safety concern is addressed.
When returing from the AUTO mission we are not using QRTL, only manual flying in FBWA and QSTABILIZE mode.
Battery failsafes have caused seriously dangerous situations in past. I will be disappointed if that is still the case. Have not tested yet.
I tested the 4.3.3 firmware on the Pixhawk V6 platform and everything works fine.
I tested the 4.3.3 firmware on the FMU V3 platform, and there was a problem in the automatic landing stage.
It is normal before it is automatically lowered to Q_RTL_ALT. It started to oscillate back and forth around 15 meters, and I don’t know why. I’ve flown a few times with the same problem.
I don’t think it’s a PID problem, I use q_loiter to test the attitude is very stable.
00000003.BIN.param (21.5 KB)
Below is my flight log:https://drive.google.com/file/d/1KB90fNi6mlNRACoefA1HIBeAKGm8SGoG/view?usp=share_link
Tested firmware version 4.2.3 on the same platform today and landed smoothly.
In the 4.3.3 version firmware, the problem of shaking during the automatic landing stage did not appear.
Today I was visited by the Guardian Angel of Radio Control.
https://drive.google.com/file/d/1xqcluucTIJvGcW6Q_NLZ1Qt3op1htz-H/view?usp=sharing
I had been flying for about 10 minutes without any problems. At some point I switched to cruise (all fine) and shortly after I decided to push the throttle to full throttle.
At 14:10 I started to lose altitude: red (barometer) and blue (TECS). The system (TECS) is aware of the desired altitude (green).
The TECS detects the negative vertical speed (red) resulting from the loss of altitude and therefore the demand (purple) is positive.
Despite having the elevator control down (yellow) I have hardly any authority… it continues to descend.
The roll control (red) does have authority (blue).
Despite fully down throttle (yellow) the engine is still at 100% (red)… and going down.
According to the barometer I escaped the disaster by 1.02m and according to TECS by 2.85m.
Here the crash was avoided (14:25) but this is still going on.
20’’ later I was still with the throttle control at zero and the engine at full throttle. To scare me, right?
I decided to switch it to RTL without any appreciable result and at the end I switched it to FBWA; everything was back to normal.
I would be very grateful if you could tell me what could be happening.
I have made a TREMENDOUS MISTAKE:
TECS_PTCH_FF_FF_K=-0.6
when it should have been TECS_PTCH_FF_K,0=-0.06
To devs attention, please review my issue, it could be a very bad tecs malfunction:
