I’m hitting a few walls. Cooked a couple servos… (Elevator servo, AUX servo, and just now the rear tilt servo lost travel in one direction… ) VTOL Yaw and roll controls were responding OK , lately the roll control in VTOL is reversed, I guessed i somehow autotuned it into a bad state as it was maybe working earlier?.. I have no clue what I am doing…
vtol gimbal v1.4 6S PWM.param (25.1 KB)
1st, edit the post and delete the pasted parameter file text and attach the parameter file here so it’s not pages and pages long. Then attach a link to .bin flight log file which will include some other useful information.
Thankyou for the guidance! 
Having some troubles with log file creation… “No logs to download” just yet… working on that…
Managed to get Telemetry log data…
Arduplane Matek405 VTOL Tricopter Tri-Tiltrotor - best test.zip (854.7 KB)
And a new test flight video, the telelmetry log flight…
Is this the correct bin file?
(https://drive.google.com/file/d/1xLDygOMNFZyN1EJT7fUqQCpkzpBHJnWh/view?usp=share_link)
Bin log flight:
https://youtu.be/CVOOwvbPPGY
Qstabilise - All axis seem to respond mostly as expected…
Manual - forward flight the differential tuning is woeful…
Transition from forward to vtol has very enthusaistic prop speeds… somewhat overly eager…
Updates since cooking servos: updated Immersion RC Ghost Tx and Rx to latest firmware, updated arduplane FC firmware, now the radio link is via Ghost RC protocol (it
was only working with sbus before fw updates). Radio latency is much improved and no other servo cooking issues as yet but I have not replaced the tail assembly tilt servo or the aux servo as yet. They’re a few weeks away in the mail…
Ideal state:
1: In Fixed wing (manual): A) Not allow the fwd-wing-servos to pitch change on roll input, and respond on elevator input instead (both servos up or down max +/- 10 degrees from fwd position, total of 20 degree travel) - hoping to eventually attempt fwd thrust from the tail motor, not sure what that will look like (maybe a mechanical relay switch attached to the tail-assembly tilt-servo, that changes the ESC-> motor wiring, and some ardu-magic to enable the motor in forward flight mode… thats my top idea so far… rather not put all trust in a reversible esc config… if all fails I’ll be inclined to try a helicopter rotor head that mechanically changes pitch when the tail-assembly tilt-servo transitions form fwd to vertical position. Yeah I doubt that will fly great… anyway, thanks for listening.
b) Enable/Disable prop speed Yaw-differential in forward flight mode. And tune the differential to be a tunable maximum e.g. 5% of current motor input…
2: In VTOL (Qstabilise): tune tail servo yaw and pitch adjustment PIDs
It needs to be a bit faster
3: Transition Fwd to Vtol - throttle input discrepancy? not sure if I have any control at all on throttle input during transition for the first 5 seconds or so…? It goes wild…
4: Qstabilize Autotune overriding all inputs? throttle bump seems to respond though…
5. Failsafe caused by? I guess too much power draw?
Updated Parameter fiile:
ARDUPLANE MATEK405VTOL Tricopter Tri-Tiltrotor Configuration - Best yet.param (25.1 KB)
There is a dream ahead:
Flight characteristic of being able to pitch the airframe (yes including wings) forward (losing large amounts of lift - to be compensated by the tail prop and tail-assembly tilt-servo, all-while maintaining a constant low-speed in forward flight, utilising the forward tilt / hover position. It will be wild! Fly straight and level, then pitch nose down, maintaining altitude and lower speed, and return to level flight mode powering away… absolutely wild…!
Right. Ghost protocol was not properly working.
After radio and tx FW update and binding, things were working, ghost was the selected and displayed protocol on the Radio Tx module. Adjusted outputs etc, but after some experimental changes I had a runaway:
I thought I put it into RTH but checking the log… it was still in Qstabilise… throttle went to 1900… negative climb rate… is that all it was? I’m not so sure, I reset the tx and rx, and nothing. nada, radio bind ok, but NORC detected from arduplane… Ended up working on sbus again, now set to
sbusfast… Did the gimbal reaching maximum-up position (and the craft stopping suddenly after climbing) fool the FC into ramping up to full throttle? how can I verify that from the logs?
Also had a few tests in which the yaw controls were reversed… intermittently…
Doesn’t mean much of anything tested tied down…
It means it is still in one piece?! Fair point but as a total rookie, im taking some chances, call it insurance for experimental opportunity. When it is stable and flyable and without intermittent control inversion… and runaways… Sure will untie it… appreciate the sentiment but achieving the best tune possible on the gimbal for now seems a reasonable testing ground before sending it to the moon. Made it this far by guessing. Some experienced guidance would really be helpful. And maybe actually succeed. I’ve reached my limit for now. Untying will likely be the end of this project.
Do you mean there are tuning limits due to a gimbal?
Extra weight from the gimbal, the long strings are to prevent rotor strikes on the table top and the un-weighted gimbal tipping over. Gimbal has 8 inches of up-down movement and is spring assisted, totalling maybe an extra 500g weight to the total airframe, equivalent to having some cargo. But within a reasonable range it has completely free movement.
‘Theoretically’ on a gimbal without reaching any of the movement limits - “should” be what to expect off the gimbal? - albeit changes to CG from motors tilting into new positions demand CG adjustment on the gimbal… this is expected.
