Hi @Allister,
OK, thanks. I’ve added it to the 4.7 issues list. I think we’re falling a little behind in some of the investigations but hopefully we can catch up soon-ish
But the issue was the same, regardless of the axis. Thanks.
Following- strange behaviour with the coordinated turns in loiter mode.
Great news. BTW, MichaelO has said here that he’s planning an official release of MP within a month.
Okay. Thank you very much.
When you are flying you are naturally coordinating your turns manually so the additional roll is getting a double dose.
When this feature is enabled the turn acceleration will be present as long as the aircraft heading is changing and the aircraft is moving. When you let go of the sticks both of these things are still present so you expect the roll to also be present if this feature is enabled.
Yes, there are turns in the log that are manually coordinated (old habits..) but there’s also some that are not. I can accept if I’m adding the roll into the turn then that’s going to mess with outcome, but for the turns without the manual roll input I’m not sure the result is right.
I’ll trust you that this is the expected behaviour. I don’t think it’s the desired behaviour, at least for me. My choice for the coordinated turn would be that upon release of the sticks that any coordinated correction is stopped right away, and the previous directional movement is stopped per the loiter braking params. I appreciate it’s probably not that easy, especially when somebody keeps adding in his own corrections.
I think for the time being I’ll be leaving this feature off on the “daily driver”, but I do have a plan to dust off an old cruise control script that would take advantage of this new turn for a very nice one-handed FPV experience.
MAVx counts the serial ports that use MAVLink, not the SERIALx number: if only SERIAL0 (USB) and SERIAL1 use MAVLink, SERIAL1 is MAV2_OPTIONS.
MAV1_OPTIONS, 2 is wrong, right?
I am confused. So, in my case, I should use MAV3_OPTIONS, correct?
MAV_OPTIONS,0
MAV1_OPTIONS,0
MAV2_OPTIONS,0
MAV3_OPTIONS,2 # for MTF-02P, correct?
MAV4_OPTIONS,0
SERIAL0_PROTOCOL,2 #Mavlink 2
SERIAL1_PROTOCOL,2 #Mavlink 2
SERIAL2_PROTOCOL,8 #Gimbal
SERIAL3_PROTOCOL,5 #GPS
SERIAL4_PROTOCOL,1 #Mavlink1, MTF-02P
SERIAL5_PROTOCOL,-1 #None
SERIAL6_PROTOCOL,23 #RCIN
SERIAL7_PROTOCOL,16 #ESC Telemetry
SERIAL8_PROTOCOL,2 #Mavlink 2
Hi @Jai.GAY,
Yes, it looks from the comments like the optical flow sensor is connected to Serial4 and this is the 3rd serial port using mavlink so it would be MAV3_OPTIONS. If you want to be completely sure you could load 4.8.0-dev onto the board and then check the MAVx_DEVID with beta mission planner and it will show you which serial port it affects
Oh, then it did migrate correctly to another field.
I think we need to check that this new mode can be disabled, in Realfight i not seeing the change back to expected behaviour…
Agreed.
This is the same for Realflight excessive counter roll…
This option can be disabled. When I’ve disabled it then loiter returns to normal. In 4.7.1 it’s on by default, but I noticed in the notes for the dev call that that will change in the future to default off, and I’m good with that.
Great so when disabling loiter coordinated turns returns to normal. rock solid yaw.
This means that there is stupid bug in realflight using loitor on a quad and tailsitter bi motor introduced in the last 5 months with excessive counter roll angle regardless if I turn coordinated turns in loiter mode off.
Hi @Quadzilla,
The other item that is causing problems is the scaling change to ATC_INPUT_TC.
ATC_INPUT_TC should be reduced by 33% (e.g. multiplied by 0.66) to match 4.6
Most people never change this parameter so it’s less of a problem than the coordinated turns but it’s the other gotcha. I plan to make this more visible on all the 4.7.x releases from now on
I experienced something weird when using EK3 source 2 (optical flow) during loiter mode. It stopped climbing when the throttle was still at 100%; I estimate the height is 6m (coincidentally the rangefinder’s max height). I cannot reproduce it the second time. I think I started in Alt-hold mode in EK3 source 2, then I switched to Loiter mode. Then I started to climb the drone and started to notice it stopped climbing even with the throttle stick above 75%. I descended and switched to EK3 source 1 (GPS); I was able to climb to a higher height. After that, I tried to reproduce it under EK3 source 2 (optical flow), but I could not reproduce it.
ArduCopter 4.7.1
optical flow = Micoair MTF-02P
MicoAir743v2-AIO-45A
Flight log.
EK3_OPTIONS,4 #Optflow may use terrain alt
EK3_SRC_OPTIONS,0
EK3_SRC1_POSXY,3
EK3_SRC1_POSZ,1
EK3_SRC1_VELXY,3
EK3_SRC1_VELZ,3
EK3_SRC1_YAW,1
EK3_SRC2_POSXY,0
EK3_SRC2_POSZ,1
EK3_SRC2_VELXY,5
EK3_SRC2_VELZ,0
EK3_SRC2_YAW,1
FENCE_ALT_MAX,10
FENCE_ENABLE,0
RC6_OPTION,90
Separately, I notice that when migrating from 4.6.x to 4.7.x, there is “somewhat” inconsistency.
optical flow = Micoair MTF-02P
MicoAir743v2-AIO-45A
# 2nd board
ARMING_CHECK,1041910 #4.6.x
ARMING_SKIPCHK,1055240 #4.7.x
SERIAL4_OPTIONS,0 # optical flow use serial 4
# 1st board
ARMING_CHECK,1041910 #4.6.x
ARMING_SKIPCHK,4104 #4.7.x
SERIAL4_OPTIONS,1024 # optical flow use serial 4
Hi @Jai.GAY,
The inability to climb sounds like the built in safety feature when using optical flow. It limits the altitude to 70% of rangefinder distance. We’re adding support for flying beyond the limits of the rangefinder though. It’s enabled by setting EK3_OPTIONS = 4 and it is documented on the BlueOS optical flow page
I’ve tested it works with BlueOS’s optical flow extension but we haven’t tested it much with other optical flow sensors
But how does it explain I can climb beyond 70% on the second attempt with optical flow?