AP_MSP: Use scaled RC inputs instead of direct RC in #26304
Conversation
|
I'm not sure about reversing pitch just here. We don't do that in other places (e.g. CRSF) and people generally then setup the channel as reversed in AP. Does that not work here? (I like the change BTW!) |
|
@andyp1per It depends on which one they did (OpenTX or AP parameters)... If they did it in AP's parameters, then this PR should actually result in no change in behaviour for them. I don't know what CRSF does with RC input, but if it's using RC input directly instead of the "scaled" one, then it will also be this situation. |
|
Great! |
|
I seem to have HD Zero goggles running fine without this. What problem is it solving exactly? |
Independent of R/C input, actually. Currently, if for example your roll is reversed in your transmitter and you use the _REVERSED parameter to correct it, then MSP will still get the roll directly from the transmitter. With this PR, MSP will get the corrected roll - i.e. the same roll that ArduPilot uses for flight control.
I'm also using HDZero Goggles and yes, they do work fine, just with a few caveats. If some of your RC channels are coming in reversed and you're using the _REVERSED parameters to fix it, then stick commands for the VTX menu, camera menu etc will be the wrong way around. Except for pitch, where the problem comes if you don't have _REVERSED = 1. If you use OpenTX's default directions, then it'll work fine, and of course, if you don't use the stick commands then you won't notice it either. |
|
@tridge Not quite sure if this needs |
|
@MichelleRos as far as I'm concerned nobody but VTX vendors use MSP RC telemetry frames so impact would probably be minimal, what I mean is that I received "complaints" about the inversion only from VTX users :-) |
|
This causes the sticks to work differently on different vehicles. On one plane I hold the sticks / \ to get to the menu, on a different plane, with yaw reversed I have to use / / (I fly mode 3). |
|
@timtuxworth I'm not sure what you mean. If yaw is coming in reversed from scaled input, then AFAIK that means it has to be going in reversed into your PIDs... |
Yes it's reversed into the control loop because that's what this plane needs, but this method is to send the stick values to the VTX. My comment was about using the sticks to get to the VTX menu on the HD-Zero googles, which currently works "backwards" on this one plane to how it works on my other plane and both drones, which do not have RC Yaw reversed. I'm going to see if I can get it working how I want, if I can, I'll do a PR. |
it sounds like you have the RCn_REVERSED set incorrectly on this aircraft for rudder. The "that's what this plane needs" makes no sense. |
I say "needs" because it's a pretty mechanical process following the Wiki "4 Channel Plane" setup https://ardupilot.org/plane/docs/guide-four-channel-plane.html#servo-function-reversal - following these instructions you could technically have both/either SERVOn_REVERSED and/or RCn_REVERSED for a particular surface. That said this is an A Tail, so it is possible I've gotten it wrong, although it does fly! I'll re-check the V-Tail/A-Tail instructions https://ardupilot.org/plane/docs/guide-vtail-plane.html#servo-function-reversal and report back. |
|
@timtuxworth i'm really quite sure your plane is setup incorrectly. Rudder will work with R/C input, but the automatic rudder mixing will be backwards. It means your plane will sideslip in auto flight modes. |
Thanks Tridge - yes I think you are right, the A-Tail setup needed to be reversed. I hope to test fly this soon. I did a detailed write up and video because I thought it might also help others. Posted on discuss here: https://discuss.ardupilot.org/t/a-tail-servo-and-rc-reversed-settings/117059/9 I'll be updating this post when I fly it. |
Yes this is correct on this setup, my golden rule is "never change the RC on the TX - let AP do it", so with my TX16S, my PWM values are always as you described. I think you are also correct that my plane wasn't set up correctly. I followed the wiki and ended up reversing my ATailLeft and ATailRight functions on the servos so that "Right" is actually on my left ruddervator and "Left" is actually on my right ruddervator. It felt ok to fly it, but looking at the log I'm not so sure. Here is the log I just flew with 4.5.2 beta 1. |
This makes the MSP RC output scaled RC inputs instead of just passing through the received RC input.
This is especially useful if you have RC reversals, so that ArduPilot's _REVERSED parameters still apply.
Tested with a copter with an HDZero VTX which uses stick commands.
I've also reversed pitch because ArduPilot's pitch is inverted relative to other flight controllers (eg Betaflight) and OpenTX and thus how devices like the HDZero VTX expect it to be.
@yaapu Re our previous discussion - not sure if this would affect other (non-VTX/OSD) MSP devices that wouldn't expect pitch to be reversed? At the moment, if people using MSP devices used ArduPilot's _REVERSED parameter to reverse pitch instead of reversing it on their transmitter, then how I've currently done it should result in no change of behaviour, whereas if they've done it on their transmitter then this should result in pitch being the opposite way around...
Not sure if we need a parameter to decide which of the two doesn't get a change in behaviour?