Finally got round to having a quick look at this log, looks to me like a bad wind speed estimate. On the point of transition there is a big jump. Forward flight tune is a little loose, abit of a tune up would probibly help and then running servo auto trim for a bit would probably help also.
Hello Peter,
thanks for the efforts. Best will be to flash a daily version ?
Only for understanding: What role does wind speed estimation play if we have an airspeed sensor ? We use an airspeed sensor just to avoid being dependent on estimates.
(ARSPD_TYPE,6 = SDP33, ARSPD_USE,1 )
The estimate should be more accurate with a airspeed sensor. I’m not sure exactly how this works for VTOL stuff, ie is the estimate updated when hovering, I theory always transitioning into the wind should result in the real airspeed being higher than the estimate. This is much better than the other way round. I think such a jump in airspeed seen here could be due to the sensor suddenly becoming enabled once the transition is complete or something like that but I’m not familiar with how it work in the code.
Was it windy in the test? Was the transition into the wind? Have other transitions in different wind conditions done the same thing? I’m not an expert with this log analysis stuff but the airspeed change did jump out to me.
I am looking to implement this very same configuration of a Reverse Tricopter - VTOL plane on a NAVIO2. The only difference will be that the motor at the front will not tilt to provide forward thrust.
I just had a couple of questions -
I have updated mission planner to the latest and also got the latest 4.1.0Dev binary however in mission planner I can’t see the option for Q_FRAME_TYPE = 6 (for the motor mixing mentioned here -Reverse Tricopter-VTOL Plane). My guess is that this is because this has not been included in the stable version yet and hence Mission Planner has not been updated.
So are the two rear engines responsible for forward-propulsion? Do you have a picture of this plane ?
Arduplane 4.1.0dev has implemented reverse tricopter (even if MP does not yet have the variable description - it doesn’t matter). I know for sure because we flew with this firmware the day before yesterday
We have given Mozart II a completely different electrical system in the past few weeks:
Matek F765 instead of Pixhawk1, BlHeli ESCs with telemetry, 2 batterys and some ohter changes.
The first hover with new FC and actuak dev-firmware ( 4.1.0dev) worked:
Hi @Rolf, thanks for confirming the bit around MP.
Yes, the rear two motors will tilt backwards and provide forward thrust and vectored yaw (if that is supported in this configuration) during cruise (non VTOL operations).
The diagrams I have are all napkin sketches. I’m in the process of getting the foam cut for the UAV. Once that’s done I’ll put everything together and put up a photo (like the one you had put up).
Hello guys, Rolf, Peter, I am interested also with this configuration. However I plan to change a little bit the configuration to be 2 motor at the front and one motor (Pusher) at the back. Please advice what parameter I should change based on your reversed Tricopter firmware.???
Thank you
TA
as Peter says, with 2 motors in front and one rear motor you should actually be able to use a standard tiltrotor firmware.
How do you want to control Yaw?
a) With the rear motor swiveling around 2 axes ?
or
b) Only the rear motor can be tilted fully 90° and both front motors control yaw by tilting back and forth a few degrees in opposite directions ?
Rolf
(The last 2 months we have unfortunately either had rain, storm or no time to test our “Mozart II” with new components . We are still waiting for better weather in Central Europe)
Hi Peter, Rolf, no I can not use standard til-rotor Tricopter, because I only want the rear (one) motor that will tilt 90 degree that will be the pusher motor. While the other two motor at front will only tilt -15 deg. to +15 deg. to control Yaw, same as your firmware. So basically the system similar to your reversed tricopter, (only one motor will tilt 90 deg.), however this tilt motor is installed at the back as Pusher instead of as tractor.
So , my question is what parameter that I have to change based on your firmware??
Rolf, this is same as option b of your reply.
Regards,
TA
Peter, why you said that I can not use your firmware ???
You even have to use the standard tri-tilt firmware.
Set Q_TILT_MASK to 8 (only rear motor no 4 is tiltable)
Set Q_TILT_TYPE to 0 (continous, due to vectored does not work properly if the vectored motors themselves are not tiltable)
Control both tilt servos of the front motors (in opposite directions) with SERVOn_FUNCTION = 39 and the tilt servo of the rear motor with SERVOn_FUNCTION = 41.
Rolf, thank you for your explanation, I will try later. How about configuration of Tilt servo of the Rear (#4) motor?? What parameter value (servo_n) I should use??
I assume the parameter is like this (correct me if I am wrong):
Servo3_ Function = Tilt motor Right
Servo4_Function=Tilt motor Left
But I still don’t know yet the Tilt motor (,motor #4
… parameter value…
Sorry, I made a mistake with the servo functions. Corrected the post now.
SERVOn_FUNCTION 41 is for rear tiltservo
SERVOn_FUNCTION 39 is for both front tiltservos.
Tilt motor right/left is for vectored yaw
In your case:
SERVO3_FUNCTION 39
SERVO4_FUNCTION 39
SERVOx_FUNCTION 41 (rear servo)
Thank you Rolf, I will try this configuration later. But would anybody (Rolf, Peter) advise me how to do SITL simulation of this new configuration ? I never used RF8 (but I have RF7) or Gazebo, so how is the easiest way to do SITL simulation for a new configuration copter or plane??? Thank you.
Yesterday we successfully tested the reverse-tri function with 4.0.6 stable firmware. So the Master-version is no longer required. Thanks to @iampete Peter.
Flightcontroler is now a Matek F765 instead of the Pixhawk, mainly to use OSD and to have the possibility to use LUA scripts.
@Walter and I tested the Reverse Tritilt yesterday and the day before. It runs first class - in calm and windy conditions. Most impressive is the transition at 7 m/s wind speed and 9 m/s transition speed. Thanks to Tridge, Peter and others for developing this awesome firmware.
We have updated the firmware to 4.09 stable. Because of the badly set YAW PID (for hovering) I have to be ashamed. Otherwise, we are very happy and will soon change to a 4.1 beta firmware.