Exactly, good change but it confused me
1 Like
@tridge Can you install the RTK base station on a mobile ship and send me the code or firmware that supports mobile landing for testing?
Hi Guys,
Having issues with EKF Health
I get the following flags
velocity_horiz off
pos_horiz_abs off
I have attached my params.
Setup is a Matek F765, SAM-M8Q GPS, TBS XF nano, DJI air unit.
Everything else is working I have telemetry on opentx, DJI OSD working.
Cheers,
Will
210617 ardu.param (19.8 KB)
Will
Edit: My friend has the same setup except the GPS he has a B-220 and is having the same issue.
Unable to arm with 4.1.0beta (ekf3) where with 4.0.9 (ekf2) it worked fine.
I am running Omnibus F4 Pro v3 board in traditional 4ch plane (Volantex Ranger 2000). Keep seeing continual EKF3 IMU 0 forced reset messages in my yaapu telemetry screen and unable to arm. I also see “Prearm: EKF3 Yaw inconsistent by 79 deg” messages on trying to arm. I have always used mag on this plane successfully with ekf2 (in previous AP versions). Log attached. Cheers, Paul
Will this feature be included in 4.10. ?
If others have this problem, it is solved using the compass less info here
https://ardupilot.org/copter/docs/common-compassless.html
My understanding is disabling the compass in the arming_check param allows you to arm and launch the wing. Once airborne EKF3 becomes healthy and engages.
Hi,
I’ve upgraded my firmware on my Pixhawk to 4.1.0 Beta which is in an AR wing. I flew in auto tune but I was not happy with the results and want to revert to my old PIDS. But it looks like my PIDS were from the old system because when I try to enter them in mission planner they are out of range. How can I convert the values I have written down to the new system so I can enter them in the Basic tuning screen on mission planner? They are:
Servo Roll.
P = 0.6222168
I = 0.05185141
D = 0.04666626
Servo Pitch.
P = 1.05
I = 0.0875
D = 0.07875
Also QP Extended Tuning screen is un editable? Is this not an option on Arduplane?
I’ve rolled the firmware back then put the old PID’s in then updated to 4.1.0 Beta. The PID’s are now shown as.
Servo Roll.
P = 0.210
I = 0.300
D = 0.015
Servo Pitch.
P = 0.210
I = 0.0875
D = 0.015
Can any one confirm that these are the original PID’s converted or are they the defaults?
Thanks
Ross
not in the first 4.1.0 release, but it could be included in a later update if the PR is accepted
I’ve just released 4.1.0beta2. This is a minor update over the 4.0.1beta1 release. It has a few
important fixes for beta testers:
- Fixed a bug in attitude control during the airbrake phase of quadplane landing approach
- skip POSITION1 stage of landing approach for tailsitters
- fixed handling of corrupted filesystems on arming, where a long delay during log file creation could cause a watchdog reset
- fixed build of VRUBrain-v51 board
- re-enable soaring on MatekF405-Wing
- fixed calculation of battery consumption on a commanded reset
Please report all test results, and happy flying!
After updating from 4.0.9 stable to 4.1.0 beta 2, an autotune was necessary to make the ASW react promptly again.
After that FBWA, AUTO, CRUISE and RTL worked fine.
Thanks a lot for this comprehensive Ardupilot update .
Rolf
1 Like
Did you happen to notice if the update reset your tuning to default or did it convert to the newer PID values?
The update converts to new FF-PID values.
1 Like
Matek F765 Wing
Updated from 4.1 beta1 to 4.1 beta2.
Now DISARMED when I switch from a Q mode to a plane mode the right motor run inexplicably.
This is not a Failsafe and ARMING_REQUIRE = 1
https://drive.google.com/file/d/1rnXFK_CffJY8l5aZ5Rqk9oDUiY1Fwsan/view?usp=sharing
thanks for the report. I had a look at the log, and need to clarify a few things.
The log has the following servo functions assigned:
SERVO1_FUNCTION 73.000000
SERVO2_FUNCTION 74.000000
SERVO3_FUNCTION 77.000000
SERVO4_FUNCTION 78.000000
SERVO5_FUNCTION 73.000000
SERVO6_FUNCTION 74.000000
SERVO7_FUNCTION 73.000000
SERVO8_FUNCTION 74.000000
this means you have 3 channels assigned to left motor (channels 1, 5 and 7) and 3 assigned to right motor (2, 6 and 8). Which one is is the right motor actually connected to? Or do you have 3 left and 3 right motors?
Channels 2 is also marked as reversed as SERVO2_REVERSED is set to 1. My best guess is this is your right motor, and the issue is that it is marked as reversed. The parameter Q_M_PWM_TYPE is 4, so you’re using DShot150. Reversing via SERVOn_REVERSED is not the right way to reverse a DShot ESC. See SERVO_BLH_RVMASK for reversing DShot ESCs.
Can you test changing SERVO2_REVERSED to 0 and see that you get the correct behaviour?
even though this was a misconfiguration we still need to fix it. Here is a PR that should fix it:
Sorry, I tried to test the motors on channels 5/6 and 7/8 and I forgot to reset it to zero.
Yes, the right motor is channel 2. This afternoon I will set SERVO2_REVERSE=0 and SERVO_BLH_RVMASK=6 and I will report it.
One question:
To reverse one motor with DSHOT, is it better to do it also through the SERVO_BLH_RVMASK parameter than even from BLHeliSuite?
Regards from Bilbao
Its more convenient to do it that way if you have SERVO_DSHOT_ESC set correctly, but both have the same effect.
OK, so I will configure it. On BLHeliSuite Motor direction “Normal” and setting SERVOn_BLH_RVMASK.
Thanks
SOLVED:
Setting SERVO2_REVERSED = 0 >>> Now NO run the right motor when switching to plane mode with disarmed.
Mission Planner >>>
SERVO1_REVERSED = 0
SERVO2_REVERSED = 0
SERVO_BLH_RVMASK = 1
BLHeliSUITE >>>
ESC1 Motor direction “Normal”
ESC2 Motor direction “Normal”
X
EDIT >>> with SERVO_BLH_RVMASK = 1 >>> not reversed the left motor (Channel 1)
SERVO_BLH_3DMASK,0
SERVO_BLH_AUTO,1
SERVO_BLH_DEBUG,0
SERVO_BLH_MASK,3
SERVO_BLH_OTYPE,4
Q_M_PWM_TYPE,4
SERVO_BLH_POLES,24
SERVO_BLH_PORT,0
SERVO_BLH_RVMASK,1
SERVO_BLH_TEST,0
SERVO_BLH_TMOUT,0
SERVO_BLH_TRATE,10
SERVO_DSHOT_ESC,1
SERVO_DSHOT_RATE,0
Thanks
That seems like a bug - what version of blheli? You need one that supports dshot commands.