There is a problem that I am facing with Firmware 4.4.0 due to the value of max_t (main loop rate). I connected to the Cuav v5+ system via the com port (USP), and I ran the system with version 4.4.0 and set the parameters to default after I activated q_enable, also the value SCHED_LOOP_RATE is 300, which is the default value. I made the system run for a while, switching modes, then I analyzed the .bin record attached below, and I saw that the value of max_t = 5 and 4.5, and the correct value for it is 3.3ms. This problem did not appear to me when I was using version 4.0. 7. What is the solution please?: 00000001.BIN - Google Drive
and This is another log,Together form 4.4.3 It’s the same problem:
and This is another log with the 4.0.7 Firmware and its default parameters, also with the same steps q_enable = 1 and SCHED_LOOP_RATE = 300, it was connected to the system via com (USP), and with the same system used for 4.4.0 Cuavv5+, it is noted that the value of max_t here is at 4.0 .7 equals 3.3ms.
@trag123123 I just tested a CUAVv5 with 4.4.4 and I do not see any scheduling errors when I load the parameters from your log. Please re-test with 4.4.4.
Note that you can see scheduling errors without downloading the log file by setting SCHED_DEBUG=1 and looking in the messages tab. This is what I see:
Hello, I used plane 4.4 to fly the quadplane On the first flight, the route moved at a low frequency in roll. After the flight landed, I modified the ff and p of roll, and modified the ff and p of pitch. When I took off again, the plane hit a tree. Yes, the elevator is invalid. I speculate that the ff of the pitch should be increased to be correct. I would like to ask if the new pid has a greater weight on ff. P only affects the speed of reaching the angle.
Good day everyone. I have had issues since I updated to 4.4.4 quadplane firmware on my MFE striver equipped with Pixhawk 6c and f9p holybro. Before i’ve been updated from 4.3.7, everything was working fine, but now when I’m trying to takeoff in QHOVER manually vehicle starts to spinning by YAW axis and performs unstable hovering causing a crash. Everything was recalibrated and still have no result.
Hello Tridge,
Wondering if you’d have some time to review the dataflash log from my recent quadplane flight that ended up in a crash. I have a video of the crash as well that can further help analyzing what went wrong. Let me know and I will upload both the log file and video for your kind advice.
This was the first post by your user ID on this forum, so I don’t know how to find the log or crash report you are referring to. Where did you post it?
I am having a weird problem with one of my MFE Fighters. It has Cube Orange+ running plane-4.4.4. The aircraft sometimes behaves like the airspeed sensor is defective or there is a pitch control issue. The aircraft exceeds set cruise speed and throttle percent varies rapidly in response to the airspeed when this occurs in AUTO mode. The aircraft then struggles to maintain level flight or reach target altitude of the next waypoint. Usually, switching the flight mode from Auto to loiter and letting the aircraft orbit for 2 minutes at the same altitude resolves the issue and I continue mission thereafter for another 1 hour without any problem. I have replaced airspeed sensor and the elevator servos but the issue comes and goes. Switching to loiter for two minutes just after the trasition phase always clears the problem.
I intentionally did not use the loiter today, just to see performance on a ramp as it flies the mission. The issue took another dimension with the aircraft exceeding a waypoint altitude by 40 meters. Thats a lot.
Please, I need help finding the root cause and fixing it. It has become too risky to operate, so I have grounded the aircraft till I find the root cause.
THR_SLEW_RATE is too low at 10%, use the default of 100. With it set to 10 it means that a change in throttle over full range takes 10 seconds, which is far too long
your mission has extremely speed descents. For example, from WP 36 to 37 you’re asking for a 120m drop over a distance of 350m. That is more than 1:3 glide slope, which is very steep.
The combination of very slow throttle response with a very steep glide slope is what leads to the overspeed
Hey, i had a similar problem with my H750 SPRACINGH7EXTREME board.
The thing must have crashed, as there was no further logging past the freezing.
associated log:
@andypiper said this: “The log just stops, so it certainly crashed, Usually if its a watchdog there is another log after that gives the watch dog reason. You are running Plane - I have not tried that, I am not sure whether the low loop rate of plane is something to worry about, you might do better to run at a standard copter loop rate - e.g. 300 or 400 Hz”
