A-Tail servo and RC reversed settings

[timtuxworth]

I’ve set up my RQ-7 model and it flies nicely, but the yaw stick is working “backwards” for VTX configuration (HD-Zero) and rudder arming. @tridge suggested that I might have the servo reversals (and hence rc reversals) wrong, so I thought, I’d go through the setup in detail to help with my thinking process and document it in case it might help others.

The RQ-7 is an A-Tail. The wiki says this : “With “A-Tail” planes (an inverted V-Tail), the control surface movements referenced above should still be the same directions. It is likely that the servo reversal or function will be opposite from a similar V-Tail setup.” which does make me think I might have gotten it wrong, so let’s see.

Here is a picture of the plane:

The servo’s are set up like this:
SERVO6_REVERSED = 0 (VTailLeft)
SERVO7_REVERSED = 1 (VTailRight)

Corrected to
SERVO6_REVERSED = 0 (VTailRight)
SERVO7_REVERSED = 1 (VTailRight)

The RC setup is standard AETR on channel 1,2,3,4 with
RC1_REVERSED = 0
RC2_REVERSED = 1
RC3_REVERSED = 0
RC4_REVERSED = 0 (corrected from 1 as per the video below)

I followed the setup instructions on the wiki here V-Tail Planes — Plane documentation which gave me the servo and RC settings you see above. The plane flies beautifully, but. this doesn’t comply with the instructions, specifically this:

What I’m getting is - when I roll the plane, left or right, both surfaces move up. But if I pitch the plane the surfaces move correct (Pitch up - surfaces move down, Pitch down - surfaces move up).

Actually if I follow the instructions for resolving this, it doesn’t really do much. Here’s a short video about that:

A-Tail servo/rc setup

As you can see, either way the surfaces are moving incorrectly as per the wiki, just a little bit less incorrectly based on the new configuration.

The good news is that now I can enter the HD-Zero VTX menu using the sticks as I expect and the arm/disarm is working correct, so maybe this is better, but does the wiki need updating @hwurzburg - or do I still have something missing?

I flew this today with VTailLeft on the right ruddervator and TailRight on the left ruddervator and it seemed to fly better subjectively than before. although looking at the log I’m not so sure. Here is a log of a fairly active FBWA flight with this setup on 4.5.2 beta 1.

log_87_2024-5-4-17-38-40.bin

[Allister (Allister Schreiber)]

Have you checked that there isn’t a reversal set up in the radio as well?

[cbf123 (Chris Friesen)]

When you move the sticks the corresponding channel in your third picture should move in the same direction as the stick, except for the pitch channel which should move in the opposite direction from the stick. I would uncheck the “Reverse” boxes and do any needed reversing in the TX itself if possible.

Then work your way through V-Tail Planes — Plane documentation again to fix up anything that got mixed up.

[timtuxworth]

Thanks for the feedback, Chris but I would never reverse the channels in the TX. That is a very bad idea. In my opinion, everything should be done on the autopilot. No rates, expo, mixing, scaling or reversal should be done on the TX.

[Yuri_Rage]

Reversing the TX channel would just result in unticking the reverse parameter for RC4, which would have the identical net effect. I agree with Tim that we should generally leave the radio alone and worry about reversal via parameters (there are a few reasons to stray from that dogma…but they are immaterial to this topic, IMHO).

I’m curious if the FBWA preflight check passes on all axes (particularly yaw).

[timtuxworth]

I’m curious if the FBWA preflight check passes on all axes (particularly yaw).

Great question Yuri! I just ran through everything again and it looks like it might not be right. I’m getting both surfaces going “up” when the plane rolls left/right which is not correct. I’m going to try

Change the function (from 79 to 80; or 80 to 79)

As per the wiki - which didn’t really help. I’ve updated the base article (above) to include this new information.

[hwurzburg (Henry Wurzburg aka ATXHELI)]

1. first, cal the RC. RC input screen and params deal only with RC input and direction independent of anything else.
2. the SERVO reverse determines the direction AP moves the servo and should be determined in FBWA mode, preferably…on the ATail use the VTAIL setup…try the rudder input from TX and FBWA for elevator…you may have to swap the functions left/right as the wiki states depending on mechanical setup of servo arm rotations and the reverse function for servo if you need to swap functions…like you have to do with elevons

should be quick setup if you follow RC cal (and don’t ever change that after) and then get servo assignment and directions setup

[timtuxworth]

I had done this Henry and flew the plane, it flew great. Then I connected my HZ-Zero camera/goggles and found that the VTX menu didn’t work until I realized the yaw stick was working backwards to trigger the VTX menu. Tridge suggested that this might be due to having done the servo/rc reversals incorrectly.

That’s why I’ve gone back to basics here and following the servo setup instructions from the wiki, I’ve now switched my VTailRight/VTailLeft. But even so it doesn’t comply with what the wiki says I should be seeing as you can see in the video above.

[hwurzburg (Henry Wurzburg aka ATXHELI)]

seems to be vtx related if the plane is flying fine…rc/servo reversals to make the plane fly correctly should not impact the effective RC info sent to OSDs or VTX, unless the VTX is monitoring the TRANSMITTED rudder…ie directly from the incoming RC stream…then reversing the rudder on AP to compensate for a reversed transmitted channel wont changer what the vtx sees…in that case reverse rudder in the tx and also change the reverse on the rudder on the AP rc screen (net zero to AP but reverses rudder to VTX)

[timtuxworth]

That’s what I thought, which is why I commented on this PR which seems to make the VTX menu dependent on RC channel reversals if I read the code right.

AP_MSP: Use scaled RC inputs instead of direct RC in

I have not reversed anything in the TX.

The VTX code is now definitely RCn_REVERSED dependant - once I made the changes above, which resulted in RC4_REVERSED = changing from 1 to 0 the VTX menu now comes up correctly.

[cbf123 (Chris Friesen)]

The reason why I suggested to reverse the channel in the TX is that Radio Control Calibration — Plane documentation specifically says:

if one of the green bars moves in the incorrect direction reverse the channel in the transmitter itself. If it is not possible to reverse the channel in the transmitter you may reverse the channel in ArduPilot by checking the “Reversed” checkbox (Plane and Rover only).

I wanted to rule out exactly the sort of thing that turned out to be the case, where code assumed a certain configuration for the transmitter and didn’t properly handle RCn_REVERSED.

I also disagree about never having rates in the TX, because when using MANUAL mode I might want lower rates to make it more controllable. In this case I would set it up to only use rates in MANUAL mode though. (Edited to remove mention of expo since it’s there in MANUAL mode.)

I do generally agree about not mixing in the TX.

[timtuxworth]

ArduPilot has MAN_EXPO options for exactly this reason. There is no need to do this on the transmitter.
https://ardupilot.org/plane/docs/parameters.html#man-expo-roll-manual-control-expo-for-roll

I’m thinking that reference you quoted may be old information, what do you think @hwurzburg ?

The reason why I suggested to reverse the channel in the TX is that Radio Control Calibration — Plane documentation specifically says:

if one of the green bars moves in the incorrect direction reverse the channel in the transmitter itself. If it is not possible to reverse the channel in the transmitter you may reverse the channel in ArduPilot by checking the “Reversed” checkbox (Plane and Rover only).

[cbf123 (Chris Friesen)]

Having a reversed yaw channel on the transmitter is odd…by default in OpenTX/EdgeTX moving the stick to the right or upwards will result in an increased channel value, which is exactly what ArduPilot is expecting for the yaw channel.

On a typical setup, only the pitch channel will need to be reversed, either on the TX itself or via RCn_REVERSED.

[timtuxworth]

I flew this today after switching the VTail functions so that VTailLeft is now on my right ruddervator and VTailRight is now on my left ruddervator. It was pretty windy but felt nice to fly. Here’s my log:

log_87_2024-5-4-17-38-40.bin

[timtuxworth]

I’m curious if the FBWA preflight check passes on all axes (particularly yaw).

Not exactly, yaw is a bit strange, see the video above.