VTOL build - mixing guidance.. can it be done?

[jbishop129]

First, thank you to the iNAV team for their continued support of this project, it's excellent. Second, I feel sheepish about posting this here as it feels like a Support Forum type question, but I couldn't find such a thing. If this should be posted elsewhere, please feel free to give me a thump in the right direction.

Long-time model aircraft pilot and builder here, in the process of building a VTOL. It's based on the FT Bronco; I've built my own motor tilt pods for the front, and a upward facing pod for the rear (making it a Tricopter in hover mode). I've read a lot of people eluding to being able to use the logic conditions to build out the two fight modes - forward flight, and multirotor. I cant quite put my finger on this enough to make sense of it. Before I keep digging around and chasing my tail, is this in fact "a thing"? Can this be done with iNAV? I'd love a poke in the right direction if so, and happy to provide as much detail as necessary as I document my build.

Thanks in advance!

[ohitstarik]

Hey! I'm also making a VTOL (tailsitter flying wing) with iNav. I think it's possible - i'll definitely update the forums if i make a breakthrough. Good luck!

[DietmarM]

I also would like to use INAV with a tri engine aircraft for VTOL but without transition and not using the logic to switch between mixers. I'm in process to design the mixer in Excel - and implement it in the mixer.c after passing the testing in Excel. If anyone wants to join the work and support it please send me an PM.

This will not be a tail sitter - one engine in the front for vertikal lift and 2 vektoreed engines behind the wing with -90° for take off and up to +40° tilt engine tilt angel for roll.

[jbishop129]

As a baseline, I’d like some guidance on the tricopter setup part; here’s my setup:

• Two forward-facing props, which are capable of tilting up 90 deg (or slightly more)
• One rear prop, fixed position facing up, for lift only during “tricopter mode”.

Question: Can I configure the model in iNAV to work in this setup? When I select Tricopter model, I only see an option for a L/R servo tilt for the rear motor, but I would like this to be fixed, and use the front motors’ tilt for yaw input. Possible?

[jbishop129]

Well, I’ve decided to take this in a different direction. From what I understand, the rear motor on a tricopter “must” have left/right servo for yaw control. I decided the extra complexity of that mechanism + weight of an additional servo isn’t worth it, from a weight perspective. I got rid of the single rear motor and built two new fixed motor mounts, to result in a more standard quadcopter configuration for the “vertical” mode of this VTOL.

My next challenge, or perhaps back to my original question is, can anyone give some guidance on how to use the logic conditions to convert the “quadcopter” to “fixed wing” flight mode, when I tilt my front rotors forward-facing? Psuedo-code I envision something like this:

• Front motors tilt from 0-deg towards 90-deg at [x] rate/speed
• When: tiltAngle < 10 and airspeed > 10mph(or whatever), rear motors stop
• ModelType == FixedWing

At this point the FC knows it’s a fixed wing, it has alerons and v-tail, and all the other normal airplaney things. Reverse order to transition back to a multirotor.

How might that actually work? I’ve seen people ellude to it, but never seen an actual example of how to make such a configuration in iNAV.

[stale[bot]]

This issue / pull request has been automatically marked as stale because it has not had any activity in 60 days. The resources of the INAV team are limited, and so we are asking for your help.
This issue / pull request will be closed if no further activity occurs within two weeks.

[jbishop129]

@DietmarM Did you make any progress with designing your mixer? I’d be interested in how you made out. How about your tail-sitter @ohitstarik ?

[DietmarM]

[DietmarM]

Yes, first tests look promising. Still working on the thrusters and to improve the code. Hovering horizontal and vertical is woking and I hope I can fly acro like a plane in 2-3 weeks.

[DietmarM]

[stale[bot]]

This issue / pull request has been automatically marked as stale because it has not had any activity in 60 days. The resources of the INAV team are limited, and so we are asking for your help.
This issue / pull request will be closed if no further activity occurs within two weeks.

[conrado]

@DietmarM I'm interested in hearing how your project has come along. btw, there are no PM's in Github. anywhere we can see your progress or get in touch with you?

[DietmarM]

I have finished my software work for the project with successfull tests now.

On piece which might be interesting for more useres of INAV is for VTOL and esp. Tail sitters to enlarge the working angle of the level mode. From my tests it is only precise and relaiable 45°-60° arround z axis. If the nose is up by 90° and some tilt in roll comes on top the numbers get crazy and the aircraft crashes with the current firmware 2.5.2

I was not able to find a solution by math descriptions of the web calculating with the Quaternions or the rotation matrix. Even from knowing now a bit about Quaternions I'm confinced a full arround solution / math should be possible. So basicly I took the FC in the hand and watched through debug the values of the rotation Matrix. By testing I found this formular and may be someone can proof it is correct (at least it works for me).

Additonly I would recomend to release roll from the level PID controller and instead of pitch to level yaw above 45° to get full functionality for tail sitter VTOL's. It is realy nice to do torque rolls with baro and full level stabilisation - I couldn't fly manual that smoth up to know those manovers.

//NoseUp are the values when the aircraft is pitched up over 45° by Dietmar M
int16_t NU_yaw = RADIANS_TO_DECIDEGREES(-acos_approx(rMat[2][1]))+900;
int16_t NU_pitch = RADIANS_TO_DECIDEGREES((0.5f * M_PIf) - acos_approx(rMat[2][2]))-900;

if (attitude.values.pitch < -450) {
	attitude.values.pitch = NU_pitch ;
	smalpitch = false;
}

Videos can be found on my facebook account - Dietmar Metz if you want to see it is working

[DietmarM]

The above addition would go into imu.c

Releasing the roll axis would need to be done in pid.c

	if ((axis == FD_ROLL) && (attitude.values.pitch < -600) && FLIGHT_MODE(ANGLE_MODE)) {
		// Nose up pidState->rateTarget unchanged from level controller
		//Also wie Acromode
	}
	else {
		  //org code
                      pidState->rateTarget = angleRateTarget ;
            }

[gavinlowk]

Hi All,

Recently, I see there is a new LOGIC_CONDITION_OPERAND_TYPE_PID feature on the logic_condition.h .
I think we can also add a logic change condition for mmix on the fly to make a VTOL transition between multirotor quad and airplane.

What I am come up with saving changes on the fly with primaryMotorMixerMutable(currentMotorMixerIndex)

and to do an initialization with the below function call
servosInit();
mixerUpdateStateFlags();
mixerInit();

Is this idea going to work ?

[DzikuVx]

@gavinlowk the idea we were thinking about was to have 2 mixer banks and switch between them in flight by copying mixer ruls and reinitializing whole mixer. Of course, that was only an idea and was never really implemented

[gavinlowk]

@DzikuVx , I see , thanks for your comment. Would you like to share this 2 mixer banks framework ? so that I can modify the code and test it for the moment.

[DzikuVx]

There is nothing to share as it was never implemented

[thehammstr]

It seems like there hasn't been any discussion on this thread in almost a year, but I'm interested in implementing a tilt-rotor concept where you could interpolate between the vertical mode and cruise mode mixes with a slider on the controller. It seems like the trigonometric logic conditions like sin and cos could be useful for something like this, but in servos.c, they would only be evaluated as true/false to determine whether apply the rule. Essentially, what I'd be looking to do is scale the mixer rules by sin/cos of an input so that it's not a pure on/off, but a fuzzy transition between the two control mixes. I am new to this codebase, so my question is "does this seem like a reasonable approach to take?" or should I try something else, like adding a new logic condition that would explicitly apply on a fuzzy scale between 0 and 1, rather than binary on-off, and would this be likely to be accepted in a pull request?

[jbishop129]

@thehammstr this sounds like good approach to explore. I’ve recently dusted off this project in my shop, and thought I’d express my interest in this logic change again, for VTOL support. Did you make any progress in changing from multirotor to fixed-wing model modes on-demand?

[sensei-hacker]

If you ever come back to this, sine and cosine are now available in the programming tab, so you could set a gvar to sin(stabilized roll) ... and then set the output to the gvar value.