I try to takeoff in FBWA mode but when getting speed in the runway with full Elevator up , the elevator start reduce the pitch up command to level . I think Airspeed sensor is controlling this motion , as I Inflatable air into the Airspeed Sensor pitot the elevator move to correct the pitch up .
How to solve this issue ?
I don’t want to takeoff in stab mode it’s more difficult .
and I don’t want to takeoff in Auto mode .
I want to takeoff in FBWA mode as it is, but with no correction of my command to the elevator.
It is normal for the elevator to deflect less when you have higher airspeed, as the effect of an elevator is increased linearly with airspeed. That is called “speed scaling”, and is required for stable flight.
I suspect that is all your are seeing here, but it isn’t totally clear from your description.
that shouldn’t be the case. I often do steep takeoffs in FBWA. I can get to 100m alt before the first turn.
If you post a flight log (DF log) I can look at why its slow for you.
My first takeoff attempt in FBW-A went long and climbed out agonizingly slowly. I increased the LIM_PITCH_MAX from 20 to 25 degrees to go again…but my second attempt did not make it off the ground.
The log for the second attempt shows that I requested full up elevator when reaching a good takeoff speed (13 meters/second). CTUN Nav Pitch goes to 25 immediately. But the elevators never deflect much and consequently the plane never pitches up. About 4 seconds later, I’m at 20 meters/second…but the mowed section of lawn ends and I abort the attempt.
The log is fairly long and boring since the entire takeoff attempt is about 10 seconds out of an hour. The takeoff attempt occurs close to the end and can easily be found as the last big spike of CTUN.NavPitch.
I’m getting off the ground now. It still takes a long time. Two factors helped.
I was able to make the effective runway longer.
I realized that it takes at least a couple of seconds for up elevator to start impacting servo position.
I’d still like to know how to get the plane to pitch up more rapidly, but I can work around it.
I’ve also considered using a momentary switch as an override to select stability mode for a few seconds. I can’t use those modes for the takeoff role since I need the automated ground steering. But, once the plane is ready to lift off, the loss of the ground steering shouldn’t be an issue.
Is auto takeoff able to climb more rapidly than FBW-A?
I Do search in the full parameter list and I found this :
" FBWA_TDRAG_CHAN: FBWA taildragger channel
This is a RC input channel which when it goes above 1700 enables FBWA taildragger takeoff mode. It should be assigned to a momentary switch. Once this feature is enabled it will stay enabled until the aircraft goes above TKOFF_TDRAG_SPD1 airspeed, changes mode, or the pitch goes above the initial pitch when this is engaged or goes below 0 pitch. When enabled the elevator will be forced to TKOFF_TDRAG_ELEV. This option allows for easier takeoffs on taildraggers in FBWA mode, and also makes it easier to test auto-takeoff steering handling in FBWA. Setting it to 0 disables this option. "
and it’s related parameters such as :
TKOFF_TDRAG_ELEV: Takeoff tail dragger elevator
TKOFF_TDRAG_SPD1: Takeoff tail dragger speed1
When enabled the elevator will be forced to TKOFF_TDRAG_ELEV. This option allows for easier takeoffs on taildraggers in FBWA mode
good sound here , Dose it solution for our issue ?
I try it
but no effect when I do the FBWA_TDRAG_CHAN to more than 1700. the Elevator move as I do but immediately back to close elevator .
maybe I miss any thing .
any info can help in this ?
it looks like your pitch gains are far too small. You have PTCH2SRV_P set to 0.8. I suspect you need a much higher gain. Some aircraft need 2.5 or more.
I can’t tell what values you really need as your log doesn’t have any sustained flight to look at the response on pitch axis.
Cheers, Tridge
I don’t think that is your issue. I did suggest a few weeks ago that you post a log of your takeoff attempts but I haven’t seen a log yet.
Assuming you have the control surfaces moving in the right direction, then the most likely problem is that your PTCH2SRV_P and PTCH2SRV_I tuning values are far too small.
Cheers, Tridge
semo , I have a similar setup on my HK Cloud Surfer but no problems to take off in FBWA mode.
I give elevator full command only when the plane has enough speed.
I will try to gradually adjust the Pitch P parameter to a higher value.
However, I’m positive that any and all previous adjustment of PTCH2SRV_P was solely the result of running autotune during normal flight. Is there a deficit in my flying technique that could lead autotune to end with a low P term value for pitch?
I can provide a different log with more flying. I also have the initial log where I ran the autotune if that would help.
I tried increasing the pitch P term from .8 to 1 at takeoff. And then we tweaked it to 1.1 and then 1.2 in the air.
Looking at ATT.DesPitch and ATT.Pitch still shows a lot of divergence. And I see some minor pitch oscillation in sections where there’s no change in the desired pitch. An example is obvious in the center of this graph:
It also appears that requests for pitching down work better than requests for pitching up. The following graph shows the takeoff at the left side. There’s some pitch oscillation before any command and while still on the ground. The request for pitch (green line) jumps to 20 degrees. The actual pitch (red line) starts to follow at about the same rate…but after about 5 degrees of pitch are achieved, the rate of pitch change declines dramatically and the red line goes from steep to shallow.
About 10 seconds later (27:44 in the graph), there’s a second request for max pitch up that’s immediately preceded by requested pitch dropping sharply. On the downward side, actual pitch follows desired pretty closely, but the upward pitch change is again briefly steep and then shallow.
The plane is balanced about 8mm forward of the manufacturer’s recommendation.That’s 28.2 cm from the nose and they list 29 cm. The plane is more likely to tip stall at 29 cm, so most of the folks at RC groups are around 28.5 cm or so.
If you zoom in on the second picture, you can actually see my CG marks. The forward most one is at 28cm and is directly in line with the plastic ESC cover (under the motor on the white section of the wing). The second mark is at 29 cm, just behind that one. The CG was definitely between the marks for the logged flight… closer to the front mark.
At about t=945, you command a full elevator pull-up and the NavPitch goes to 20 degrees, as it should. You stay there for 1.2s, and in that interval the actual pitch goes from -2 to +14 degrees. I admit that this would feel kind of sluggish, but I don’t see any significant misbehaviour from the controller part.
If you want to make the pitch controller more aggressive, then I would increase the P-gain further.
In case of overshoot+oscillations I would increase the D-gain and in case of oscillations in steady-state, I would increase PTCH2SRV_TCONST.
I don’t see any significant oscillations in the last log you sent. I’ll check the next-to-last in a bit.
I thought you had uploaded two .bin files, but there’s only one. Anyway, regarding the pitch oscillation and failure to track, I agree that there is a less than ideal response of the PID elevator loop. ±2deg error isn’t terrible, but I have seen better.
If I were you, I would assume that this airframe has unusual aerodynamics and I would tune it manually, the “old fashioned” way, without autotune.
I would be interested to hear what more experienced developers think.
I really appreciate your input. Thanks for your help!
It is an XUAV-Clouds. I really like it so far. It has a lot of room for electronics and battery. I’m not good enough to risk flying in manual, but my expert pilot enjoys all sorts of loops/rolls and such (usually when I’m looking down at the ground station ) and states that it flies well.
What software did you use to plot those graphs? They look great. The online log tool in Mission Planner is OK, but for drilling down it’s frustrating not to be able to scale values and fix the x/y labeling/scale in place.
I’m tempted to reduce the D-term a bit. None of the oscillations (from 985 to 1005) appear related to control outputs on the elevators. So the pitch controller looks blameless. But the D term is quite large and oscillating prior to liftoff. And the last downward spike in that sequence for the D term (about t=946) appears responsible for damping the slope of the initial pitch change. There’s no visible overshoot anywhere that I can see in pitch, so I don’t think it’s underdamped.
Hm… if your system was underdamped due to an overly large D-gain, then the contribution of the D-term in normal flight would be comparable to P-gain. This is not the case. The system might still be underdamped due to a small P-gain and the system’s natural damping, so that’s why increasing the P-gain further might work.
Typical signs of underdaping are slow convergence to the setpoint and no overshoot.
The plots are generated from a MATLAB tool me and a friend (@hunt0r) are writing, to parse and work with .bin files easily within MATLAB. Our repo is here , but we haven’t written any documentation yet, because we haven’t released it.
) and states that it flies well.