Auto take-off no rudder response

Hello everyone,

I am trying out the autonomous landing mode available within Px4. The documentation states that: " Until RWTO_NAV_ALT is reached the plane is held level and only rudder is used to keep the heading". The Nav Alt was kept at its default value of 5.

The problem is my airplane, a kadet, turns directly right after approximately 1 seconds and there is no rudder correction at all to keep the aircraft aligned with the runway. The log of one of the tests can be found below:
https://logs.px4.io/plot_app?log=e80f7fe3-866a-4fc5-8d59-c9c0274f2101

In the log one can only see that I initialize the take-off phase and directly abort it due to the fact that the aircraft is turning right. Moreover, in the log you can see that there is a small change in yaw response (rudder) but it is relatively small. I can find no parameters in Qgroundcontrol, which can alter the controller response on the ground which keeps the aircraft going straight.

More details about parameters values:

  • I use the runway take-off mode. (RWTO_TKOFF = enabled)
  • The gain of wheel steering and yaw rate is set equal to 1%/rad/s (I thought this would solve it)

Another issue is that I enabled RC stick override of auto modes, however, I was not able to use the rudder to correct for the heading error in the auto take-off mode using the RC.

Can anybody help me solve the above two issues?

Kind regards,
Koen Lucassen

Hi Koen,

Is a parameter FW_W_EN set to “Enabled”?

have you try some “steer” parameter?

Yes I have both tried to enable and disable the FW_W_EN. In fact, when disabling it is actually able to keep the heading (going straight using the rudder/nose wheel which are on the same servo). Even when I max the gain parameters of the wheel steering nothing happens. In the log you still see a small serve command, but I think it is saturated to a very small value. Have had a look in the Px4 source code, but I could not find a limit/saturation line in the nose wheel steering attitude controller code. (there is a line which limits it between -1.0f and 1.0f, but thats the same for the yaw controller).

So I am still wondering which causes the wheel steering to be ineffective/have no controller response. I want to fix this because I want a higher gain on ground compared to air.

I would expect the majority of your takeoff rollout to be handled by the wheel controller but if you have them (yaw and wheel) on the same channel, which one is the output configured for? ie since you have the nose servo plugged into the yaw control output, does the specific mixer for the standard plane model actually treat the yaw output channel as a wheel output on the ground? I don’t know the (I’d have to look at the mixer and output description) but I don’t think so. Generally the wheel is on a separate output. If you want to set the gains to max, I’d start by setting fw_wr_rmax to 0 which would essentially give you unlimited wheel rate control (in deg per sec). That’s probably overkill but I’ve seen scenarios where that was definitely required and then turning the other wheel rate parameters down was needed, even simply giving it unlimited authority but limiting its servo output range relatively small so it can’t over correct.

Another thing to consider, and this is more of an issue only at longer rollouts or when considering min speed is that servo outputs are scaled based on speed. 60% is the magic number. Once your groundspeed exceeds 60% of your min speed, scaling occurs. Runway tracking is then diminished, I’ve definitely seen that in long takeoff scenarios but that is less likely the scenario given how quickly you are aborting but food for thought.

First of al, thank you for your response ryanjAA. This is very helpfull, gives me things to think about.

With respect to the yaw output as wheel output on the ground, I thought I did use the wheel output since I got no rudder response when I enabled the wheel steering. However, as you said it can also be that it only tries to use the wheel (controlling on a output channel which is not there). I have to look into the code myself to give a final answer, but this seems very plausible thanks!

After this airframe we actually move on the a different airframe which has a seperately wheel channel, but to minimize risk I wanted to go to the bottom of this problem first. Also thanks for the second tip, as with the new airframe we probably have a long takeoff. Thus I have to keep this mind.

If I have a more concrete answer to all of the problems I will post it here. :slight_smile:

2 Likes

@klucassen … I had the same problem with 2 separate kadets (trike gear and taildragger). See my post a little older than yours about veering to the right.
I haven’t flown those, or any, px4 planes in quite a while so I don’t know if software updates fixed anything. I did, however, seem to have been able to tweak things just enough to minimize the problem so that it didn’t happen very often. Wish I could recall what those were.
I eventually flew both kadets simultaneously, so I got confident enough to trust the TO direction. But I ALWAYS was haunted about it and had my hands on the manual mode switch just in case.

Good to hear I am not the only one having this problem. I did explore this problem a little bit more and if I look through the source code actually everything seems fine. Both wheel and yaw steering output to the seem control group and channel, namely control group 0 channel 2. So it cant really be a mixing problem. Note that if you have a retracting gear one should disable the wheel servo during flight.

Right now I am actually able to take-off with my airplane and it keeps it pointing towards the take-off point. Only, I achieved this without wheel steering and a relative high gain for the yaw steering. However, this is still not a preferred situation. Now that I did some digging in the source code, I will try again and narrow down the exact problem (probably test it within 2 weeks). I will post the solution if I found it :slight_smile: