Where would I change vectored thrust mixing in the source code?

On the Convergence in MR mode the elevator stick tilts both motors fore and aft, in the same direction, to move the plane forward or backwards. Ardupilot does not do that. The motors move in opposite directions for yaw control.

So is that what you meant by “elevator control”, the “stock” controller’s MR mode?
I’ve been playing with adding similar capabilities to the quadplane code, but without giving up pitch control on the elevator stick:

So far, I prefer using an extra channel for “forward throttle”, as in the first PR.
It would be great if you could test some of these changes and suggest improvements.

I will test as soon as I figure out why I am getting the message Motorstri: unable to set up yaw channel.

I keep checking the parameters, and they seem right. I have a Matek F405-wing, and servo 7 is set to motor4.

In MotorsTri.cpp k_motor7 function should return 11, but it is getting 0. Q_FRAME is set to Tri, Q_TILT_TYPE is VectoredYaw, Q_TILT_MASK = 3. I must be missing something but can not find it.

Can you post you full param file

I figured it out. Yaw min and max pwm were both zero. I will review your changes and try to test today. If I don’t kill yet another F404-wing. The USB port is too fragile, and the metal shield wiggles until the solder breaks, the the shield falls off. You can resolder if you are careful, but it will be even weaker. I have had three boards do this .

hey folks i’m thinking about building a tricopter VTOL with the tilting tail rotor as the cruise motor because it’s too inefficient to run the other two in cruise (optimized for hover not cruise). the tail rotor might as well be binary because pitch control would probably be done more conveniently through just RPM control in hover mode, without any tail tilt. I think the difference between this idea and the OP is that i don’t use the two front rotors in cruise at all. I plan to use collapsible CF rotors that hopefully will fair into the nacelle by drag.

Just read this post but not sure if i’m following the conversation, so: is there any functioning version of the code that will allow my configuration? I read the VTOL documentation two three times over and then this post and got the impression that my configuration isn’t supported in any way. thanks.

I’m new to Github, if there’s a ‘branch’ or test code that sorta works I will perhaps try to build a foam prototype with my small spare motors just to test the water so to speak. I checked out kd0aij posted above but not really following what that is for or how to customize it for my configuration.

Should work with the stock code, have you seen this?

You would just have the yaw servo on the single motor rather than one for each side.

1 Like

I was interested to read this post - Foxtech uses Kris’s code for the Nimbus. Which is incompatible with latest stable version of Arduplane - Sure this is nothing new to all following this thread. I know that by using foxtech Nimbus PG20 Parameters in Plane 4.0.6. It causes (at least) a couple of errors 1) reverses the battery used for FW and VTOL modes, disables vectored yaw. I was checking off each of my parameters for foxtech code against 4.0.6 and found a number of parameters values that appear to be outside the range or function for 4.0.6.
INS_FAST_SAMPLE,5
GPS_BLEND_MASK,5
EK3_IMU_MASK,7
DSPOILER_OPTS,3
I’m not familiar enough to know how or why they would be written like this.

As people may or may not be aware, Kris is in breach of the of the ArduPilot’s GPL3 licence because he supply firmware builds but not source code.

I did not realize that Foxtech were shipping his code, anyone who has purchased a vehicle that runs this code has the right to ask for the source. We can then look to bring any improvements he has made in the main code base to benefit all users.

It also makes it hard for us to provide support here, because we have no idea what changes there might be in Kris’s code, yet users come here to ask for support not realizing the difference.

1 Like

Hi Steven, Kris’s main acheivement (what Ive been trying to copy with no luck) was using the 3 rotors to vector thrust in unison for AoA and Yaw control. the 3 rotors can also tilt for forward flight. As far as I know the Nimbus does not do this.
Itsa a major improvement in hover stability and efficiency in hover.

That may explain why the code looks wrong. Im not at all any good at coding.

Hi Peter, I have tried asking Kris for his source (through people in WeChat) as well as the online store they have and have never had 1 response despite them updating the FW on their site.

thanks for the heads up… Ill keep a lookout for something again.

AND AGAIN IF ANYONE WANTS TO TACKLE THE CODING FOR THIS PLEASE LET ME KNOW (sorry for caps)

I think the main achievement has been costing users and developers time and money. By not doing what he and the companies he supplies are obligated to do. He is obviously clever but…when companies cannot meet their obligations to customers under GPLv3. This becomes a real problem and the code or any parameters cannot be safely changed or verified. I see alot of really clever developers through here and github doing amazing stuff to enhance the UAV industry, yet 1 guy can potentially ruin this reputation. Kinda sucks.

1 Like

I know this is a bit of an old topic, but I am looking for a way to turn off the front motors in a triPlane tilt-rotor aircraft when it is in horizontal flight mode (with the rotors in fully horizontal setting).

The reason is that the front motors will be mounted with folding propellers to avoid interference and I expect a single motor propulsion to be more efficient in horizontal flight.

So the TILT_MASK=11 will remain which means all rotors will tilt, but only the rear motor4 will provide the forward thrust.

A shortcut could have been to set the tilt mask to 8, but then the front motors would not tilt forward as desired and create interfecence.

I played a little with the code above, injected below lines in various points.

SRV_Channels::set_output_scaled(SRV_Channel::k_throttleLeft, 0.0);
SRV_Channels::set_output_scaled(SRV_Channel::k_throttleRight, 0.0);

I also played with overriding the tilt mask in the below lines and setting its value to 4 to cheat the controller to think that only the rear motor is tiltable only when the rotors are fully in horizontal position…

    if (!motor_test.running) {
        // the motors are all the way forward, start using them for fwd thrust
       uint8_t mask = is_zero(tilt.current_throttle)?0:(uint8_t)tilt.tilt_mask.get(); // tried overriding the value of this 
        motors->output_motor_mask(tilt.current_throttle, mask, plane.rudder_dt); 

So far, no success in shutting down any motor. Any insights would be appreciated.

Thank you.

Should certainly be possible, I suspect you need to used the standard tricopter motor 1 and 2 outputs rather than throttle left and right.

You are right, the correct motors for the tricopter are indeed motor1 and motor2. I am using a V22 Osprey model on Xplane 9 to do my development work for various reasons, and for that case the the controls for the motors are ThrottleLeft and ThrottleRight. Perhaps this is causing the problem. I will try directly on the tricopter case. However, what is the right approach: to modify the tiltrotor mask temporarily or to send overdrive commands to turn off the motors?

Scripting is a great way to do such things as this, you can use a servo override with a short time out and run the script at 10hz or something.

See:

you could set it up on a RC switch, speed threshold, throttle threshold, whatever.

1 Like

Thank you Peter. I have used scriptiing before and yes your suggestion should work. I will use it as an interim solution,

However, as a general feature it would be interesting for ArduPlane to accept a mask for which motors should remain active or shut down in horizonal mode. There could be interest in this… I will see if I can figure it out and share it with the community.

Best regards

This is what the TILT_MASK should be, I think the issue you have is you would prefer the stowed position to be forwards not up?

Yes, I guess this is a way to think about it, but it may lead to confusion.

Tô calrify my thoughts, I am thinking about having a separate mask from TILT_MASK. We may call it FW_PROPULSION_MASK which communicates which rotors will be active during Fixed Wing flight after they take their forwards positions.

Thanks Peter,

Just implemented the script which triggers the motors shut off when the tilt servo PWM value are within the desired threshold.

Best

Cem