ArduPilot / ardupilot

ArduPlane, ArduCopter, ArduRover, ArduSub source
http://ardupilot.org/
GNU General Public License v3.0
10.68k stars 17.15k forks source link

APM::Plane 3.3 does not support flaperons (RC FUNCTION 24 and 25) on pixhawk outputs 1 + 9-14 #2523

Closed marcmerlin closed 8 years ago

marcmerlin commented 9 years ago

Currently, to use flaperons, you are losing 4 servo channels 1) fake aileron input on channel 1 (going nowhere but to apm plane) 2) flap input channel 3) left aileron (output only, computed by apm plane) 4) right aileron

It sucks to be losing 2 RC channels below 8 for this. I'd love to set my ailerons on channel 13 and 14 but apm plane silently does not support that (setting rc funciton 24 and 25 on channels 13 and 14 does absolutely nothing). Is that a hardware limitation on pixhawk? If so, can it be documented?

KIrill-ka commented 9 years ago

2) flap input channel

I agree, you loose channel 1, but you can still use flap input channel for something else. I use it for one of ailerons. You just have to care that MIN and MAX values are shared.

marcmerlin commented 9 years ago

Thanks @KIrill-ka I've tested sharing channel 5 for aileron output and RC flaps input and it works properly as you say.So,I still have one RC channel lost, but it's better than 2 :) I've written full instructions here: http://marc.merlins.org/perso/rc/post_2015-08-04_Using-Flaperons-With-Ardupilot.html

pwbecker commented 9 years ago

Would it not be better to have complete channel mapping, i.e. separate the input from the outputs completely? That way no more lost channels, because PPM inputs above 8 could be mapped to any output, including 1-4.

marcmerlin commented 9 years ago

@pwbecker sure, if that's possible, it's even better.

pwbecker commented 9 years ago

Its puzzled me why channels 1-4 have that special status. It seems that this is just a hangover from past limitations, and there is no need for it given the current hardware. Also, when you do an RC calibration, it can screw things up by changing output min/max/trim.

marcmerlin commented 9 years ago

@pwbecker totally agreed. Note however that channel 8 is apparently special on the old APM hardware, while channel 1-8 are kind of special on the pixhawk due to passthrough mode, but since using flaperons,or ruddervators,or elevons, or any kind of copter, makes passthrough useless, I've now told myself that I should pretend that passthrough doesn't matter, and just treat channels 1-14 as all the same (assuming the software allows it, which right now it doesn't quite).

magicrub commented 9 years ago

I don't understand the limitations well on all the PWM channels on the varying hardware platforms but we should try our best to abstract that out as best as possible and have it "just work".

On Wed, Aug 5, 2015 at 8:32 AM, Marc MERLIN notifications@github.com wrote:

@pwbecker https://github.com/pwbecker totally agreed. Note however that channel 8 is apparently special on the old APM hardware, while channel 1-8 are kind of special on the pixhawk due to passthrough mode, but since using flaperons,or ruddervators,or elevons, or any kind of copter, makes passthrough useless, I've now told myself that I should pretend that passthrough doesn't matter, and just treat channels 1-14 as all the same (assuming the software allows it, which right now it doesn't quite).

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/2523#issuecomment-128041155 .

iskess commented 9 years ago

I thought that the channel mixing was done separately from the Pixhawk CPU, so that pass-through will still work for elevons and such. Is this not correct?

marcmerlin commented 9 years ago

On Wed, Aug 05, 2015 at 11:16:30AM -0700, Iam Bouret wrote:

I thought that the channel mixing was done separately from the Pixhawk CPU, so that pass-through will still work for elevons and such. Is this not correct?

If that's true, that would be great. I found no information on how passthrough really works, and the failure cases where it kicks in.

Marc

"A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/

magicrub commented 9 years ago

It takes a few seconds for the pixhawk to boot. If you can keep power on your RC receiver and power cycle the pixhawk you should see the failsafe pass-through behavior breifly

On Wed, Aug 5, 2015 at 11:21 AM, Marc MERLIN notifications@github.com wrote:

On Wed, Aug 05, 2015 at 11:16:30AM -0700, Iam Bouret wrote:

I thought that the channel mixing was done separately from the Pixhawk CPU, so that pass-through will still work for elevons and such. Is this not correct?

If that's true, that would be great. I found no information on how passthrough really works, and the failure cases where it kicks in.

Marc

"A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/2523#issuecomment-128098535 .

marcmerlin commented 9 years ago

Tom, thanks for pointing that out. So, I just tested that: 1) ruddervators work during in flight reboot (although the servo test on the rudder isn't great for a ruddervator if you're really in flight) 2) the flap part of flaperons do not work but the ailerons work

In other words, passthrough mode is actually much better than what I anticipated.

marcmerlin commented 9 years ago

oops, didn't mean to close the issue, but given what we just said, there is actually a benefit in keeping the ailerons on channels 5-8 since if you move them to 9-14, you'd lose them if you hit pixhawk passthrough.

I could then be fair to close this as "working as intended" if we document that you do want the ailerons on channel 5-8. However, we should be able to assign a function to RC1, and put the 2nd aileron on channel 1 output to avoid losing an output

gmorph commented 9 years ago

Your aileron servo's need to be connected to a physical output channel on the pixhawk. The Pixhawk only has main output channels 1-8. I fail to see how they could ever be connected to 9-14? In "passthrough" you do not "lose them". If for some reason the FMU only dies the IO will still send the aileron input through to the output channels the ailerons are connected to. It won't however mix the flap input in. We could do this but the number of times it would be used or needed is almost zero. Thanks, Grant.

marcmerlin commented 9 years ago

@gmorph please forgive my ignorance, but how are 9-14 not output channels too? Or are you saying they only work as passthrough and the pixhawk cannot synthesize any output on them? But then why do channels 9-14 have RCx_FUNCTION?

And yes, I already verified and confirmed that ailerons keep working on channel 5-8 when the pixhawk reboots, and I also agree that having flaps work during that time is not important, so there is no need to change that.

marcmerlin commented 8 years ago

Ok, I now see that I am confused. @gmorph pointed out that I don't want my ailerons to be on channels above 8 on pixhawk because if the FMU dies, the ailerons would die in manual mode, which is bad (using flaperons, you now rely on the backup flight controller always working for your ailerons to work, as if you had ruddervators or ailevons). Given this, at least on pixhawk, it makes no sense to ever put your ailerons on channel above 8.

gmorph commented 8 years ago

Hi Marc. Tridge has made recent changes to this due to the availability of SBUS output which can give you 16 physically connected output channels (if you use 4 of those sbus to 4 PWM splitters). So "maybe" if your using SBUS you may want this. I'll check with Tridge.

gmorph commented 8 years ago

So the answer is YES if your using those SBUS to PWM splitters. Because its the IO processor handling SBUS if the FMU fails and your ailerons are physically connected to Channel 15 it should work. Nobody has actually tested this yet - but the code compiles so it should be fine ;-) Thanks, Grant.