yep, I just replied. It was an interesting test case, but isn’t a bug.
hello @tridge
I had a small crash this morning with my TVBS and beta7.
My tvbs fly very well with plane 4.0.9.
With 4.1 and only from time to time I get large pitch oscillations and have no more control on pitch. The only way to escape is to switch to plane mode. This morning and yesterday I had 3 flights with beta 7 and had no problem. The same phenomena was already there with beta 2 and beta 3.
This is the log of the crash, it happened right after takeoff.
Flew my plane yesterday no problems, then updated to latest master today, now I have no throttle at all. Any ideas? What changed? I was running Beta6 previously.
Running Matek 765 and there doesn’t seem to be any Dshot changes to this board but clearly something has changed to cause an issue. Need to downgrade.
The Nano Goblin with Beta 6 works great after the tune, it flew amazingly well in 30Km/h winds.
I upgraded my S800 wing from 3.9.3 to Beta 6 and reset the tune parameters and it really surprised me how well it flew under the same wind with the defaults.
To the whole Ardupilot community thank you very much !!!
tridge，I found the RST parameter lost in parameter tree ，so i can’t reset flight mode，can you check it? And it can’t be set rally point in latest mission planner，i can’t find out where to set rally point in mission planner。
SIK Radio telemetry on SERIAL1 does not work any more.
Worked again after downgrading to beta6.
It is a Cube Orange board.
Similar problem as in Copter-4.1.0-rc1 released for beta testing
Completed the autotune on the S800 that used to be notoriously prone to have pitch oscillations after autotune in 3.9.x apparently tune ended and there were no oscillations. There was a wind of about 15/20 Km/h. But I am very happy with the result.
I do noticed that in Cruise the throttle behaves well but the Nano Goblin throttle in Cruise or Auto is just crazy, As reported here: Throttle Oscillation - in Auto Mode
I’ve just released 4.1.0beta8 that fixes just this one issue. It is being built by the build servers now, will be ready in a few hours.
i updated to beta7.
the situation is a little better, I also activated the Here2 external compass.
the actual direction is about 238 degrees.
log record on the link
Sensors Problem
I installed pixhawk2 cube and digital airspeed Sensor
and this is the logs
I can’t see what problem is…current sensor is already calibrated
Just updated Omnibus f4 Pro board using QGC (I have a mac) and shows V4.1.0beta8 - but this thread shows latest as beta7
Tridge mentioned here that it was to fix a bug:
1 Like
Hi tridge,I found there may be some issue about estimated airspeed in beta5,i did several flight today,and the estimated airspeed became wrong value when it display message of EKF3 ACTIVE。there have almost no wind,but the FC give a wind of 12m/s or 6m/s.you can see the pitcture below,the estimated airspeed is 21km/h,but the plane does not move.
it offten happen when the plane just take off and the plane become unstable ATT.
it happened many times after I update to firmware4.1 beta5,i record the issue this time so i post here,hope you can analysis it .
Please let me know if you can’t download my log
Plus:this plane was flight about 40 flight hours with firmware4.0.5,but i think the estimate airspeed is quite accurately,does is the EKF3 ISSUE?
log is below
https://drive.google.com/file/d/12VJaGy8HlGOOzTdCVxCcHN0VEzgr9bW-/view?usp=sharing
The Matek F765-WSE was released recently but there is no hex file in the beta firmware directory
https://firmware.ardupilot.org/Plane/beta/MatekF765-SE/
I found one in the latest folder, flashed that one, then ‘downgraded’ to beta using mission planner. ¯_(ツ)_/¯
thanks for the report! It is almost certainly related to the handling of no-compass flight where EKF3 initialises after takeoff.
I haven’t been able to reproduce this in SITL. Would you be able to get a replay log showing this issue?
To get a replay log set the following parameters:
- LOG_DISARMED=1
- LOG_REPLAY=1
- LOG_FILE_BUFSIZE=200
You will end up with a larger log that will allow us to reproduce the problem using the replay tool and hopefully find the cause.
Thanks!
Hi. I am running 4.2.0 Dev version on a Matek F765WING. I have recently upgraded to this version from 4.1.something. I have a breakwire function that changes flight mode using one of the button inputs but it seems to have stopped functioning in the later firmware. I read somewhere that the BRD_PWM_COUNT parameter has been eliminated and the functionality defined through other means in the firmware. I suspect the pullup resistors on these outputs are not being enabled. In my case it is for button2.
ButtonNotWorking.param (20.6 KB)
The button press is monitored by a LUA script to change the flight mode when the input goes high. This was working on the earlier version of the firmware. I have measured the voltage on the relevant pin and it is zero.
Anyone have anything similar or knowledge of what might be wrong here please?
If you can tell me a better place to post for Plane 4.2.0 Dev please feel free to do so.
Thanks 
I will take a another flight and try to get a replay log tomorrow.Then can I change it back to use EKF2 by setting the following parameters:
AHRS_EKF_USE=1
AHRS_EKF_TYPE=2
EK2_ENABLE=1
Do that will make the system more stable?
thanks
that depends on what the problem is. Once I have the replay log I should be able to find the issue
I can’t help but notice that this seems quite similar to the pitch control issue and crash I had back on beta4.
As an aside, I had an odd bug on beta5 today; the aircraft entered RTL and then QRTL immediately after auto takeoff. The same mission/parameters were flown several times before the problem flight and once after it, all today. The logged reason is 39, which (from what I can tell from ModeReason.h) is RTL_COMPLETE_SWITCHING_TO_VTOL_LAND_RTL. I’m not sure how to see the current waypoint in the binary logs, but this was a cold boot, so the mission should have proceeded normally.
Just before the reason 39 happened there was a reason 2, which is GCS_COMMAND.
2021-09-18 03:21:49.479 MODE {TimeUS : 432292263, Mode : 10, ModeNum : 10, Rsn : 2}
2021-09-18 03:21:51.900 MODE {TimeUS : 434712872, Mode : 11, ModeNum : 11, Rsn : 2}
2021-09-18 03:21:51.900 MODE {TimeUS : 434713042, Mode : 21, ModeNum : 21, Rsn : 39}
2021-09-18 03:21:51.900 MODE {TimeUS : 434713227, Mode : 21, ModeNum : 21, Rsn : 39}
2021-09-18 03:21:51.900 MODE {TimeUS : 434713246, Mode : 21, ModeNum : 21, Rsn : 2}
So the sequence was:
- auto takeoff
- GCS command which triggers RTL mode change
- RTL converts to QRTL due to Q_RTL_MODE=1
Do you have the tlog? That would tell us exactly what the GCS command was.