I’ve been looking at your log and I think you have too much going on at once to get the speed dialled in. It’s also hard to see what’s going on because the only auto throttle mode in that log (after tuning) was loiter. In the loiter turn the throttle will be higher to help maintain speed to prevent stall and altitude loss. The portion of the flight in Cruise (before tuning) is showing a lot of oscillations in pitch and throttle to maintain altitude. It seems to be holding altitude well, but it looks like it’s working hard to do it.
My suggestions:
Get the tune sorted out. The roll looks good but the pitch needs some work. Your elevator servo seems to have a lot of trim in it so I would investigate the position of the elevator linkage, and confirm your C of G. Work on getting the plane flying as true as possible mechanically first, and then get the PID tune sorted out.
After tuning, to see your cruise speed you’ll need to fly the plane in FBWB or Cruise, and try to do it straight and level for as long as possible to see what it’s doing. Don’t get caught up about the increased speed in a turn.
Consider what is realistic for the plane for a slower speed? From what I’ve seen here is that when your throttle is at the lower settings (less that 35%) the plane is generally losing altitude or the pitch is hunting to maintain altitude. It seems to hold altitude better above 35%. If you can get the plane to fly stable with a slightly higher throttle setting (and better tuning) you may actually get a more efficient/longer flight than by simply lowering the throttle. If you really want to get serious about increasing the endurance beyond this then get a subscription to eCalc and figure out a new motor/prop/battery combination that will give you the performance you’re looking for. Don’t assume the manufacture of the model has given you the best hardware.
Hi Allister,
Thank you for spending time on my log. I appreciate that.
The cg of sonic model binary It’s right under beneath of the carbon rod. But I’m not really sure about that. I set auto_servo_trim on to compensate the cg. And elevator is a little up.
can you take a look of the message on the bin file that autotune rollP was finished at 0.16 and stored as 0.46. which one is right to go？
I will do Cruise mode again. as I remember, the plane is always fly little bit off course to the right side.
it is good to know a such interesting eCalc. I will look into it. yes you are right. I need efficiency flying which doesn’t matter faster or slow. The power setup are sunnysky 2212 kv1250 with 8X6 APC Propeller.
I had another flight today. the cruise speed is OK now. here is the bin file. by the way. There is disarm voice warning sometimes when the plane is in the air. but it is nothing happen actually. do you know what is it about?
Don’t over estimate the ability of the auto trim. It’s for fine tuning. You should get the C of G sorted out. The best flight controller in the world can not compensate for a plane that is out of balance.
That is probably suggesting the same about your roll set up. The aileron servos are trimmed to about 1420, so there’s a lot of roll trim in there. Either they need to be mechanically adjusted or there is an imbalance in the plane. Since you have a twin you may consider playing with the RUDD_DT_GAIN to see if that can help the aileron issue. Go in small steps and watch the trim .
Hope your plane is still flying, could you please share your PID values along with ARSPD_FBW_Min and Max. Screen shot is ok.
I have the same stock plane, and flies very well in manual mode, but in FBWA mode its sluggish or too twitchy and has a tendency of diving once in a while during turns like Boeing 737 Max.
AutoTuning didn’t produce any good results either.
@Allister, I am having a hard time autotunning the SonicModelBinary plane. As soon as I switch to FBWA mode and make turns it has a tendency of nose-diving besides being too sluggish. I have adjusted the ARSPD_FBW_Min/Max without any success.
I am uploading two bin files one during autotune and the other with normal flight.
I admit that I should not have changed the ARSPD_FBW after tunning as I just read in the document, but based on the flight data, what would you suggest these two values before I retune the PIDs?
In FBWA the throttle is totally on you, so therefor the speed. ARSPD_FBW_Min/Max is only for autothrottle modes. (FBWB, Auto, RTL, etc)
The Roll tune looks workable. There’s room for improvement but not right now. The pitch is where the problems are. I don’t think it’s just a PID issue. The plane is generally unresponsive in pitch. Even in manual mode the pitch seemed to do whatever it wanted. Especially at slow speed. (I think in this configuration 7m/s is too slow for this plane)
My suggestions:
Double check the C of G is correct.
Check the pitch servo is working correctly and that maybe there isn’t a stripped gear. If it’s the stock servos those often have cheap plastic gears and you’ll blow out one tooth creating all kinds of havoc.
I can double-confirm that the CG is correct because in manual mode plane flies hands-free.
Manual inspection of Servo, link, horns, are rock solid, but I will check connectors as well.
As far as Trim_ …parameters are set as default except for AHRS_Trim_X and Y
It may need more trim on the AHRS. Do you have a flight in manual mode that it’s just straight and level? That would be a good comparison to see how much nose up/down it needs.
After reviewing the log, I increased ARSPD_FBW_MIN to 12m/s.
I flew the plane again and this time I switched to FBWA mode after taking off in manual mode. The pitch seems to behave better, so I decided to try flying in cruise mode, and the plane to took a 60-70 degree dive. Since I had switched my mode switch to a 6-position switch, I was too slow to react, and the plane crashed (Repairable landed in the bush). Here is the log file of the crash.
Please review the log files and let me know if something sticks out as an obvious error. I suspecting bad barometer and temperature sensors. Specially the temperature sensor seems to keep rising up.
Nearly from the moment the plane went into cruise it was trying to maintain it’s maximum nose up pitch of 15 degrees. TECS_PITCH_MAX 15 The motors were at max. The pitch stick was commanding maximum pitch. And the plane spent a lot of time at high (+/-40) bank angles.
I don’t see the dive you mentioned. But the log shows the plane maintaining the nose up pitch for the entire descent. Given the bank angles and the steady descent my first inclination is to say the plane was in incipient stall, and was unable to maintain altitude in that configuration. But that just doesn’t seem right or complete if you say the plane was diving.
The voltage and current logging is really strange as well. So it’s hard to tell if there’s a clue there. Or maybe that is a clue, and the motors weren’t making full power. Did it sound okay?
What about temperature data. I know that temperature and humidity can greatly influence barometric pressure, but why would the temperature continue to rise? The average temperature during flight time was 56 to 59 Farenhite according to the forecast. I believe the graph below is in Celcius?
Most flight control boards will heat up as they are used. How much depends on the board and the cooling air they get. You can check this out. Connect the board when it’s cold to MP and check the stats for the IMU temp. Leave the board alone and watch the temp increase.
There is a process for IMU temperature calibration. I didn’t see what kind of board this is, but if it’s an F7 it should be possible with your firmware. IMU Temperature Calibration — Plane documentation
Its a Matek-F765-wing.
One more thing, the INS_TCALs were disabled “0” Could this be an issue? It has been raining on and off in California and temperature humidity swings a lot during the day.
Then you’ll be able to do the IMU Temp calibration.
That’s only a few degrees of temperature rise over the duration. I would have expected to see it flat-line in flight as it was getting more cooling air, so that might be something to consider, but 30-32C isn’t an issue for board temp.
If you’re curious, maybe compare the shape of the baro-alt and the GPS-alt. The won’t be exact, but should follow each other reasonably if everything is working well.
I can’t explain that. [see below, maybe I can] That GPS.VS looks completely backwards to what the plane is doing. The fact the GPS.Alt is tracking the BARO.Alt suggests to me that overall the GPS is working.
…
Thinking out loud here so if anyone else can correct me please jump in.
This is the GPS.VS plotted against the IMU EKF3 Velocity Down (VD). This is a bit awkward, but the IMU VD is referenced to down, so if I’m reading this correctly a positive number is a descent. When I looked at the take-off this held, in so much that the take-off had negative values for both GPS and IMU. So yeah… it’s correct. I think.
I can confirm vertical speed being incorrectly reported both in the log file as well as on the OSD. Here is a clip of another plane (Reptile Dragon with Speedybee FC running 4.4.3 firmware). You can see as the plane is ascending the Vetrical speed indicator is pointing down.
