MC/FW Blending during transition idea

Hey folks, I’ve been working on a tilting VTOL vehicle that is fairly aerodynamically sensitive during the transition, particularly when the switch from MC to FW control occurs. One of the ideas we have been toying around with to clean up our transition is to do something along the lines of allowing both the MC and FW controllers to run fully independently throughout the transition and to actually blend the attitude setpoints from each as the transition progresses (ramp down MC, ramp up FW) as an attempt to have less of an abrupt change when going from MC to FW. I think this would require a couple mods to have the MC/FW attitude controllers operate on the virtual_attitude_setpoints always and the addition of mc/fw virtual_rate_setpoints to do the same with the blending occuring in the VTOL controller during the transition. I’m no pro on control theory and am wondering if there is a fundamental flaw to attempting a scheme like this that I’m not thinking of? Thanks for any thoughts!

Hi. The current high level VTOL control architecture is depicted here.
As you can see there is always one attitude controller running at a time but the resulting rate setpoint is routed to both MC and FW rate controllers. Those rate controllers map directly to either motors for MC and control surface for FW. So currently it is possible to have both rate controllers running during the transition.

I think if you want to improve your transitions you need to look at implementing a dynamic mixer for the motors. currently the mixer matrix is constant and does not take into account the tilting of the motors.
As a result we need to do some tricks in vtol_att_control in order to avoid coupling during the transition, e.g. disable yaw control as soon as motors tilt forward.

In the PX4 slack control channel we are currently discussing a new architecture which should make the implementation of such a dynamic mixer much easier. In fact, we are trying to move towards control allocation rather than simple, static mixing.
There is also a first draft of the control architecture shared in that channel if you are interested.
This link is here

Very interesting. I joined the slack channel and somewhat caught up on the conversation. I’ll have to keep an eye on how this progresses. The dynamic mixing would be a game-changer for us, as we have a slightly unique design - we have a quad rotor with 2 pairs of static wings, instead of control surfaces on the wings, each of our rotors tilts independently, so in MC we control Yaw with tilting, and in FW we control Roll and Pitch with tilting. Eventually we will be running coaxial with potentially different motor speeds/props between the pairs based on flight mode, perhaps use the rears as pushers, etc, so our mixing could be quite dynamic,

I didn’t even contemplate implementing a dynamic mixer, seemed like a pretty tall task with my current PX4 skills. What I am attempting is not only having both rate controllers running during transition, but also the attitude controllers and actually blending the attitudes during transition and feeding those back to the controllers.

Thanks for the info, is there any discussion yet of when the new control scheme being discussed might be fit into the timeline? I didn’t see anything about timing in the discussion I was able to see.

@nickatflugauto If you are interested you can check out my script I created for prototyping tiltrotor mixers.

I haven’t added any description yet but tried to write the code in a way such that one might guess what’s happening.
I wrote this example for the convergence VTOL but it could serve any other tiltrotor.

Main ideas:
-A tilting motor is represented as two actuators, each actuator produces thrust on one axis -> writing down torque and thrust in terms of actuators becomes a linear problem.

  • The mixing problem is then solved by first only looking at the problem as if the vehicle just had motors pointing straight up, like a quadcopter. From that solution actuator constraints are derived and as a second step the forward component of thrust is mixed in as well.
    Sorry, might be a bit hard to understand but I’m sure if you look at the script and are interested you’ll get the idea.

Awesome, thanks for sharing. If I understand this correctly, it is taking the requested thrust in the Z and X directions and effectively mixing out the tilt angle for motors 1 and 2 and the thrust for all 3 motors?

The math is a bit beyond where I am at this point, but I took a stab at modifying the test script to run with our 4-motor setup but got lost around the mix_forward_thrust_and_yaw input.

Otherwise, I was able to get our transition working quite smoothly with some higher level code/parameter tweaks using the existing mixing.