@tridge I flew two of my models on 4.1.2 on Thursday and had a rallpoint set at 70m relative, take off was perfect and the models loitered at 70m. I flew them both for some time and then engaged RTH and they came back and and started orbiting the rally point at 20m (not so ideal)
I also engaged an auto mission on one and it tried to fly it at 20m rather than 70m terrain as programmed. The throttle also dropped dramatically even though the trim throttle is 45%.
Have you seen this behaviour? It was weird to see both models work at 70m for launch but then drop to 20m
I canât load rally points with terrain as a reference it gives me an invalid frame warning.
My understanding is relative is ref to arming height, absolute is height above sea level? And terrain is height above terrain.
Dear Devs
Is there any reason why we should seriously pay attention to use 4.1.x (or above) version of new arduplane with limited boards like F405 wing (use it with one gps no more external sensors)??? I read reports (in ardu discuss topics) and also experienced on my own plane about issues which can be related to EKF3
affinity and lane switching.
Lot of users suggested is more safe to use EKF2 intstead of EKF3 on these limited F4 FC s for plane. I dont know if the reason that ekf2 need less computing power than ekf3 but It seems to me when the FC activate EKF3 (i ve got this message on OSD) the FC can fails (probably try to go back to DCMđ¤ˇââď¸) and cannot handle the plane attitude, starting high oscillation or cause a crash during take offâŚor can this be 4.1.2 bug or issue as till now i didnt experinced it with 4.1.0 running on also with f405 wing Fcđ¤
Reviewed my previous logs from 3 different flights with 4.1.2 and i not received EK3 active/ DCM active message, beside this flight where the oscialltion occured (as shown in the attached log photo)
I really dont want to use custom fw or older versions (older fw s not support dji msp osd which primary for me) if its not necesary and will be confirmed that new version 4.1x are safe to use on older F4 limited board like f405 wing! OR we need to use F7 FC s to prevent these weird midflight behavior.
I think a lot of us No need so much extra feature for a hobbyplane which required ekf3âŚand if it can cause issueâŚi really appreciate if we can use a 4.1x or above fw with default or switchable ekf2 option.
Thanks for advise
Iâve just ordered an Archer RS to test this myself, but could you please try setting the âEnable RC Protocol re-detectionâ bit in RC_OPTIONS. You will probably find that RC_OPTIONS is currently set to 32, so you would change it to 1056 to include the re-detection option.
The reason I suggest this is that the Archer RS specifications list it as both SBUS and FPort. I suspect it is really FPort2 (which is a different protocol to FPort). Possibly what is happening is it false detects as SBUS and canât change to FPort2 due to protocol re-detection being disabled.
Otherwise weâll need to wait a few days for my Archer RS to arrive so I can test.
I had a strange thing happen flying Tri Tilt Nimbus 4.1.2, It was gusty so I set an RC flight mode to Loiter (it gives my head a rest), Took off flying transitioned into FBWA - challenging, so switched to loiter which was fine, except it was closer to the chooks then I wanted so switched back to FBWA and moved about 200-300m further away and switched back into Loiter, It then proceeded to return to the original loiter circle. Iâve done this a few times previously using mission planner to change to loiter mode and controller to move it to a different location and back to loiter but this is the first time I can recall it returning to its original loiter circle.
Hi @tridge ,
In the mean time I have updated the Archer RS and the Taranis X9D receiver both to the latest FW versions. Still can observe the F.Port issue playing in the same conditions as before. Also I pluged the Archer RS in a Pixhawk 2.4.8, the issue is also there. But I notice the Pixhawk was jumping back and foward between decoding the S.BUS and decoding the F.Port. So I mask the RC_PROTOCOLS just to F.PORT and it stop decoding the SBUS. The communication was establish just in the F.PORT but after some seconds AP was in FAILSAFE, meaning the issue is also happening here.
Anyway I will follow up your request and change the RC_OPTIONS bit to 1056 and let you know later this evening CET time for the results.
Going inside the Taranis X9D Open TX, we can select in the Archer RS options the following: S.PORT/ F.PORT/ F.PORT2(FBUS)
Cheers
I have good and bad news!
Bad news:
After trying several times unfortunatly we continue to see the same failure mode in each trial. To note when setting RC_OPTIONS to 1056 (could not find the description you refer âenable protocol re-detectionâ) it represents the âenable multiple receiver supportâ.
I tried selecting the FPORT2 in the Taranis but it also fails after a couple of minutes.
Also tried in the Heli FW4.1.1 RC1 and this F.PORT issue is also there.
Good news:
I remove the SBUS wire and voilĂĄ the issue is gone! I think we are funneling to the root cause.
Seams that this issue is related to both SBUS and FPORT being connected.
my Archer RS hasnât arrived yet, can you explain what you mean by this? Does it mean there are two signal pins out of the archer RS, and you connected both? What pins did they connect to on the flight controller?
Correct, I have both SBUS signal line and SPORT/FPORT line connected to Rx6 and Tx6. When removing phisically the SBUS line and leaving the FPORT alone, the Failsafe doesnt happen, the issue is gone.
Hi @Fasa ,
I remember your questions and it was the triger to remove the SBUS line But its not solved yet !
There is no resolution saying that we cannot have them connected in this way. Remember it was working in last stable release.
I opened Log viewer and it appears I did not switch back into FBWA from loiter after transition but only Nudged Loiter. before it returned to it original loiter circle. So probably not so strange.
Do we have a way to view wind direction? Iâm really concerned about my transition to from q hover to FBWA in Bin 119 - hoping it is just a tail wind transition.
But its not solved yet !