Wish List Item: Cooperative flight controls mode in multicrew.

[Swift.]

A suggestion/request for smoother hand over of control between pilot and CPG, is to have both set of controls combined additively to the aircraft motion. So that handing over controls is a case of the previous pilot flying slowly easing the controls to the neutral position and the next pilot flying taking more and more of the control input that is being removed.

Basically at all times:
Aircraft Pitch = CPG Pitch + PLT Pitch
Aircraft Roll = CPG Roll + PLT Roll
Aircraft Yaw = CPG Yaw + PLT Yaw
Aircraft Collective = CPG Collective + PLT Collective

[Swift.]

Currently in Multicrew, control is handed over very discretely. With either CPG or PLT having control at any one time.

My desire is for an option that allows both pilots to have an equal share influence over the total control position.

Why would we want this?
In short, there have already been several mishaps that happen because the P can't nudge the P* by adding a little cyclic, or a little collective etc. This means that those groups who strive for simulation and use an IP - Student setup can't have the IP shadowing the student on the controls during hazardous manoeuvres.

How would we do it?
I'm sure many have already realised the issue that might occur if both pilots had the ability to control at the same time. Namely that there would be a similar control jitter as seen when an axis is dual bound by mistake in a single seat aircraft.

My suggestion is to have both pilots have an additive contribution to the overall aircraft control. For example:

Aircraft Collective from 0.0 > 1.0 - (This is what the aircraft uses as its 'control')
PLT Collective from 0.0 > 1.0
CPG Collective from 0.0 > 1.0

If the PLT has his collective on the floor at 0.0, and the CPG has his in flight say 0.4. Then the aircraft will be reading 0.4 (0.0+0.4=0.4).
If the PLT needs to add a little collective because the CPG isn't, then PLT collective goes to 0.1, CPG stays at 0.4. Now the aircraft reads 0.5 (0.1+0.4=0.5)

What if both pilots have more than half collective pulled? Well, you would make the aircraft collective hard stop at the limits, so PLT 0.6 + CPG 0.6 = Aircraft 1.2 which would be capped at 1.0

This logic can be applied to all control axis (other than maybe PCL and brakes), with the bidirectional axis being seen as -1.0 > 1.0, but using the same additive control method.

[admiki]

That brings another set of problems, but it is a nice idea

[Swift.]

1 hour ago, admiki said:

That brings another set of problems, but it is a nice idea

Such as? I'd be interested to see if we can think through any potential issues

[admiki]

AFAIK, of all DCS helicopters, only Hinds cyclic is completely disconnected. For the rest,controls are interlinked, so, IRL, me pulling on collective will give you a clue what is going on.

Consider DCS cyclic. You are doing something, I am doing something else, helicopter is responding to compounded inputs as it should, but to you it looks it's going haywire.

 

[Swift.]

21 minutes ago, admiki said:

AFAIK, of all DCS helicopters, only Hinds cyclic is completely disconnected. For the rest,controls are interlinked, so, IRL, me pulling on collective will give you a clue what is going on.

Consider DCS cyclic. You are doing something, I am doing something else, helicopter is responding to compounded inputs as it should, but to you it looks it's going haywire.

 

Are you saying that's how it currently works? Because that has not been my experience at all. Currently in DCS you have a button you press and it transfer complete control to the pilot who pressed the button.

[Frederf]

Unless we have networked force feedback it will never approach a 1:1 simulation of dual controls. But perfection is the enemy of potentially valuable new ideas. Even single player we don't have a 1:1 input device to cockpit control correlation. The hydraulics can fail, aero loads exceeded, limiters in place, etc. which don't prevent our input devices from their complete range.

The motivation is commendable. A more accurate simulation involves the thing more like the thing and a reduction in artificial sim-isms. In almost or in fact all of the simulated modules, both operators are able to provide control input at any time. Additive input is a fine method of simulating this arrangement and I can't think of any better one.

So we ask, why isn't this the case already? Why would DCS be designed the way it is instead of as described? My first thought is netcode. Blending two axis input streams in real time over network might not be the most pleasant experience. If it's sometimes good (LAN/super low latency internet) and sometimes bad then you're obliged to code a way of switching between the two modes. As a non-operating user you can watch the networked stick position and see sometimes it's not that smooth. The second thought is the current method is simpler and more robust.

I'd really like to see a test setup of additive input. It could be very useful and perhaps the primary method of having multi crew going forward. Or it could be terrible. I'd very much like to see a practical example.

[admiki]

3 hours ago, Swift. said:

Are you saying that's how it currently works? Because that has not been my experience at all. Currently in DCS you have a button you press and it transfer complete control to the pilot who pressed the button.

No, I was giving you a potential issue to consider.

While I like your idea, I am not sure how to make sure other crewmember know when, if and how much you are moving your controls. Like I said, you moving controls might look on the other end just like helicopter not responding to inputs as it should

[Swift.]

6 minutes ago, admiki said:

No, I was giving you a potential issue to consider.

While I like your idea, I am not sure how to make sure other crewmember know when, if and how much you are moving your controls. Like I said, you moving controls might look on the other end just like helicopter not responding to inputs as it should

I imagine we can just adopt the same technique they use IRL: voice

'I have control'
'You have control'

The additive-ness is there to smooth the transition from one pilot to the other, or to allow the IP to snatch the controls from the student. 

[Frederf]

First step when encountering an issue in simulation is to ask, "how do people in the real world solve this issue?"

[FalcoGer]

I agree. There should be a way to at least allow the option, set globally for the PIC, to have smooth transitions without awkward button presses, mouse grabbings, clickings and such.

I never fly with people I don't have some sort of voice communication with anyhow, because it's just pointless.

[ShuRugal]

Second attempt to post this, last attempt ended up in mission editor wishlist somehow...  PEBCAK.

Could we get a flight control mode for multicrew modules which allows pilot and copilot controls to be mixed, rather than only one or the other?  Average them out, Airbus style?

Would be a really nice way to bring new pilots into the game, or even to just have a way to smoothly transfer controls without the "jump" caused by the fact that controls will never be aligned when the "give control" button is pushed.

Ideally, I would like to see this set up so that there are 3 ways to control an aircraft, which can be switched between at will by the players:

1. pilot only control (only pilot's inputs are read for aircraft control)
2. dual control (both pilot and copilot controls are averaged)
3. copilot only control (only copilot controls are read)

If "average mode" would not work well due to network latency, perhaps that mode could be replaced with a mode which provides real-time control from one pilot or the other (As selected by the players) while reading the value to average against at one second intervals from the other.  So then we get:

1. pilot only
2. pilot priority, read copilot once per second (or faster, depending on how much load this is) to use for mixing
3. copilot priority, read pilot once per second (or faster, depending on how much load this is) to use for mixing,
4. copilot only

With this model, when operating in "mixed" mode, either pilot should be able to take priority with a single button command without a consent box being required, but a consent box would still be used to enter mixed mode or to give exclusive control to the copilot.

[admiki]

While I agree that would be nice, you would have same problems that Airbus has: both pilots doing some crazy stuff and wondering why helicopter isn't responding as it should.

Sorry to say, but Apache isn't really a suited to teach basic helicopter flight.

One thing to avoid "jump" is to have both control sets displayed in controls indicator (as already done in Huey) so you can match controls before handover.

[Swift.]

I've been wanting this for a while actually. But instead of averaged flight controls, I'm thinking additive would be more suitable.

With average controls, if I give 100% left cyclic input, and the copilot leaves his stick neutral, the aircraft would only output 50% left cyclic.

With additive, if I give 100% left cyclic input, and CP give 0%, the aircraft outputs 100%.

 

To admiki's point, yes in the real world its not suited, but in DCS if its your only module its what you are going to use... And besides, its not like a more 'trainee friendly' helicopter has these cooperative control laws implemented either..

The thing I can envisage this helping more than just the trainee-trainer inputs, is smoother control handover. Instead of:
'You have control'
'I have control'
Pilot releases, CP takes over, aircraft jumps around a bit

It can be:
'You have control'
'I have control'
Pilot slowly starts easing to a neutral position, CP adds his controls as required to stabilise the helicopter, until CP is fully flying and Pilot is fully off the controls.

 

Now, this idea of cooperative control law only really works with those using centre sprung sticks. So I would also agree with admiki that we need the 'preview' indicator, so that in the control indicator we can have an indication of:
Aircraft control position (red diamond)
Pilot control position (eg yellow X)
Copilot control position (eg yellow O)

This would hopefully allow a more smoother transition for all control setups.

ps. as an interesting thought experiment, I wonder if there's any provision for force feedback controls. ie, can the non-flying pilot's controls be 'driven' by the flying pilot.

[admiki]

31 minutes ago, Swift. said:

ps. as an interesting thought experiment, I wonder if there's any provision for force feedback controls. ie, can the non-flying pilot's controls be 'driven' by the flying pilot.

probably could

[kgillers3]

I think this would induce confusion without proper force feedback between the two people with them likely ending up fighting each others control inputs.  Would be a fun experience but probably more frustration than anything.

A possible solution would be selectively giving one or combination of controls to the other pilot. So they aren’t fighting all 3 inputs and the balance between all three. Get comfortable with each of the individual controls, introduce a second and see how they work with each other, then eventually all three.

Idk. 

Edited January 21, 2023 by kgillers3

[Swift.]

2 minutes ago, kgillers3 said:

I think this would induce confusion without proper force feedback between the two people with them likely ending up fighting each others control inputs.  Would be a fun experience but probably more frustration than anything.

Any confusion can be resolved in the way its resolved IRL. Using your voice. Thats why positive control handover exist: 'I have control', 'You have a control'.

[kgillers3]

39 minutes ago, Swift. said:

Any confusion can be resolved in the way its resolved IRL. Using your voice. Thats why positive control handover exist: 'I have control', 'You have a control'.

It’ll be a fun experiment if they include it. I still think it’ll have diminishing returns with both people fighting each other.  maybe it’ll work out.  

Also if both people aren’t flying at the same time why include this, why not transfer the controls and have it set to instructor pilot mode so the other dude can save the aircraft? Seems like the same thing with more possible confusion. 

Just a thought. 

Edited January 21, 2023 by kgillers3

[Swift.]

35 minutes ago, kgillers3 said:

It’ll be a fun experiment if they include it. I still think it’ll have diminishing returns with both people fighting each other.  maybe it’ll work out.  

Also if both people aren’t flying at the same time why include this, why not transfer the controls and have it set to instructor pilot mode so the other dude can save the aircraft? Seems like the same thing with more possible confusion. 

Just a thought. 

 

How would this 'instructor mode work'? Any kind of digital handover of controls will inevitably result in sharp jerks in the flight path, which if you are in a fine motor situation will result in a crash. If you intent is to 'save the aircraft' then being able to nudge the controls is far far far superior to having to jerk the controls via the current means.

[kgillers3]

4 hours ago, Swift. said:

How would this 'instructor mode work'? Any kind of digital handover of controls will inevitably result in sharp jerks in the flight path, which if you are in a fine motor situation will result in a crash. If you intent is to 'save the aircraft' then being able to nudge the controls is far far far superior to having to jerk the controls via the current means.

instructor mode (I don’t remember the name it’s in mission editor) changes how the electronic change of controls works (pilot station can just take them without consent and I believe give them so you can prep the other dude verbally, transfer and if he gets outta whack take them back), while I appreciate the difficulty of the jerk, if you’re allowing it to get that far out of control before taking over with this style of control input you would 100% crash so the end result is the same if not worse. I’m mainly referencing this at the hardest times to control the aircraft which would be at a hover, short final for landing and potentially after take off pending the weight and conditions.  Aircraft enters unusual attitude you recover.  Anyone can fly it at cruise. 

Neat idea, without ffb it’s likely to be ineffective. Potentially a variant where one control surface at a time can be independently transferred so the student isn’t overwhelmed immediately. I think continuous control inputs from two players adds more variables in a sensitive control trying to recover the aircraft. It’d be better to deal with the jerk and place the controls in the proper position imo.  
 

Edited January 21, 2023 by kgillers3
Clarification of control

[Dragon1-1]

Airbuses do mix controls from two sticks without FFB, and if needed, a single stick can command full rate, although conflicting inputs are averaged out. This didn't always work out well, to say the least, but most of the time, there are no problems with it, as long as both crewmembers follow proper procedures.

[Raptor9]

Duplicate AH-64 wishlist threads merged.

I'll leave this in the AH-64 wishlist thread for now, but understand that you all are asking for the entire DCS multicrew system to be re-vamped, not just for the DCS AH-64D. These may seem like preferable ways of implementing such logic to some players in some scenarios, but such drastic changes to the multicrew system would need to be applied to all multicrew-capable DCS aircraft that have flight controls present in more than one crewstation. This would mean re-writing how DCS World handles multicrew logic across multiplayer servers, and there are several 3rd party dev teams with multicrew-capable aircraft that would also be subject to these changes.

This is a wishlist thread after all, and you all are free to brainstorm alternative methods of simulating cooperative flight controls in the multiplayer environment, but I bring this up as an advisory to accordingly temper expectations for such a drastic change to occur in the multiplayer system.

[Dragon1-1]

I wonder, could this be implemented as strictly an FFB feature? From the sim POW, it'd still be controlled with a single stick, but if they were both kept in sync by FFB, then the non-active player could still make input by controlling the active player's joystick position. In case of a conflict, and one of them overpowering the FFB motors, the controlling player's stick would naturally take priority, but it should be otherwise solid.

[ShuRugal]

17 hours ago, Swift. said:

ps. as an interesting thought experiment, I wonder if there's any provision for force feedback controls. ie, can the non-flying pilot's controls be 'driven' by the flying pilot.

the behavior of the control position indicator leads me to believe this is already how it should behave.  I have been helping a friend learn to fly by watching the control indicator while he has it and coaching him on his overcorrections that way.

16 hours ago, kgillers3 said:

I think this would induce confusion without proper force feedback between the two people with them likely ending up fighting each others control inputs.  Would be a fun experience but probably more frustration than anything.

A possible solution would be selectively giving one or combination of controls to the other pilot. So they aren’t fighting all 3 inputs and the balance between all three. Get comfortable with each of the individual controls, introduce a second and see how they work with each other, then eventually all three.

Idk. 

 

it looks like my thread has been merged into this one, even though the method I suggested was different.  My suggestion covers this problem:

 

Ideally, I would like to see this set up so that there are 3 ways to control an aircraft, which can be switched between at will by the players:

1. pilot only control (only pilot's inputs are read for aircraft control)
2. dual control (both pilot and copilot controls are averaged)
3. copilot only control (only copilot controls are read)

If "average mode" would not work well due to network latency, perhaps that mode could be replaced with a mode which provides real-time control from one pilot or the other (As selected by the players) while reading the value to average against at one second intervals from the other.  So then we get:

1. pilot only
2. pilot priority, read copilot once per second (or faster, depending on how much load this is) to use for mixing
3. copilot priority, read pilot once per second (or faster, depending on how much load this is) to use for mixing,
4. copilot only

With this model, when operating in "mixed" mode, either pilot should be able to take priority with a single button command without a consent box being required, but a consent box would still be used to enter mixed mode or to give exclusive control to the copilot.

 

Additive would probably work as well as average, better if both pilots do not have FFB controls.

Edited January 22, 2023 by ShuRugal

[Swift.]

I don't think average would work at all. At least not without losing 50% of your control authority.