Forum Replies Created
29 October, 2019 at 23:02 in reply to: Impossible Tilt Tail Mech vs. RC Explorer- Who you got? #64083
FWIW everyone of my TriCopters has some variant of the 3d printed impossible tilt. My BiCopter has 2 of them. I print them in PLA+, never had one fail……yet.
They help reduce tail swing my lowering the rotating center of mass. Made a very noticeable improvement on my Tri LR.
There’s also less friction due to the shorter pivot screw, so I typically see a few more degrees per second servo speed with these too.
“I notice my artificial horizon after a few moments after takeoff shows that the Tri is banking ro the Right.. while it is not. Very wierd.. looks like the kind of drift you are describing.
Since I only fly acro I do not notice anythong in flight.”
That’s good information, verifies my theory that’s it’s the accels incorrectly biasing the attitude solution.
I don’t recall, what board are you flying Peter? I’d like to know which imu chip it is.
In the mean time I’ll take a look to see if we’re setting the imu on chip filters correctly.
I’m going to guess that this drift is in the level mode, and not in the acro mode.
I think this has become an issue with dRonin and the “newer” ICM20xxx imu chips. They seem to be much more sensitive to noise on the accel side then the “older” MPU6000. dRonin hasn’t added the extra filtering I believe is present in other flight firmwares. I’ve not seen this issue/complaint on MPU6000 based boards, at least that I’m aware of.
There’s one thing you can experiment with. Under the AttitudeSettings object, there is a setting called AccelCutoff, which defaults to 0.25. You can slowly raise that to see if it improves things. I started with it 0.1 and worked up to 0.25, seeing some improvement, so this might help. I’d guess at increasing it no more than 0.05 at a time. Just be prepared to switch back to acro mode if it does anything funny.
You have the correct firmware loaded, as evidenced by what is shown on the device. The pane next to it shows what the GCS has loaded for a firmware update. You’re not in firmware update mode so it’s blank.
It seems doubtful the iNav guys will include the patch I made for the KakuteF4V2 at this point. The updated target file, and the files for including triflight 0p5 and 0p7 are in my git repo for those interested.
I simply use nylock nuts. Never had a problem with them coming loose. I also print the parts from PLA+.
The above has worked fine on V4, Mini, Baby, and BiCopter vehicles.
Without a lot more experimenting, I can’t say for sure, but with 12 minutes of flight after tuning it sure seems better.
My yaw P/I gains are 110/408, directly from the autotune performed with the impossible tilt, and I observed no oscillations or sloppy heading control. I believe this ratio is backwards from what most are flying, which is an I term significantly smaller than the P term.
I could not use the autotuned gains computed with the standard yaw tilt mechanism, I had to play with them manually to get something flyable, but I was never happy with the results.
Hope someone else eventually tries this too and reports on there results/observations.
Well FWIW, adding the impossible tilt was a great change. I went back to the dRonin firmware (the latest version), and reset everything up from scratch. Used the stick cmds to set the servo angles, worked like a champ. Servo speed ~250 DPS.
But the the better news is the autotune worked very well. I did the autotune, came back inside and applied the new gains, zeroing the yaw D gain as I typically do. Back outside, it flew nicely. No odd tail drift behavior or oscillations that I could tell. This was all LOS flying.
Completed the in flight servo cal on the first attempt (further proof the yaw is behaving correctly). Motor thrust factor in my configuration computed to be 12.9.
Continued flying around the backyard in hover and slow forward flight. Acro, level, and horizon flew as expected. Altitude hold needs some tuning (and some closed cell foam over the BMP280). Did not try position hold. I suspect that after tuning alt hold and pos hold, RTH just might work correctly.
After 12 or so minutes of flight, landed to check motor and ESC temps. All good, not really much above ambient, so I was happy with that.
The impossible tilt is a worthwhile mod in my opinion.
New installers with one fix and one enhancement.
Fix – Home direction arrow should function correctly.
Enhancement – You can now setup the tail servo limits using the TX stick commands like in the original *Flight versions. Setting up the servo limits via the GCS output panes still works too.
After download navigate to your download directory and just install the package on your system
with the command: “sudo apt install ./dronin_1.d-20190810-5356a217-1_amd64.deb”
You will need a compass for these modules to be happy and permit arming. Note that the nav solution must also be valid to arm.
“jihlein any chance you can get a good working rth firmware for the L/R completed before this site evaporates once and for all?”
My opinion on this issue is, yes I will try, but only to the extent of looking into tuning the altitude hold mode and position hold modes, and seeing of that fixes the RTH problem. If it requires re-write of the code then probably no.
My reasoning behind this is mainstream dRonin development has stopped, and it’s hard being a one man development team. There’s many parts of dRonin I still have not dug into, and in some ways I think effort would better put into something like iNav, which is significantly more active.
There’s simply too many bells and whistles missing from dRonin that users want, and since the autotune feature does not work too well on the Tri LR, the point of using dRonin is somewhat diminished.
Not a good answer I know……
dRonin is not the issue.
The issue is the on ground part of the servo calibration has either not been run, or been run incorrectly (servo endpoints and neutral point not set correctly is the typical problem). The triflight algorithms (whether in dRonin or BetaFlight or …. ) use the servo angle to calculate thrust corrections for the tail motor. If this angle is incorrect, the tail motor is going to act incorrectly. So yes, the servo does indirectly affect the tail motor.
One the on ground portion has been completed, you can then start flight testing and do the airborne part of the servo calibration.
No, the oscillation I was referring to was at low throttle settings, primarily on the ground before takeoff. At mid and higher throttle settings it was fine.
I’m going to re-baseline this branch on the latest iNAV release 2.2.1 tonight. Might even have a chance to get it loaded and setup on my Tri LR this weekend to see what’s going on.
If I recall correctly, there’s no s5 output pin on the KakuteF4V2. There’s definitely not one defined in iNav.
So the change isn’t specific to the Tri LR, it’s tricopters in general.
The tricopter target I created (KAUTEF4V2TRI) places the servo output on the LED pad, and the LED output on the M4 pad. Without going into the gory details, this was necessary to be able to define the 3 motors as one output type, and the servo as another (dshot300 and 370 Hz pwm for example). Looking at the STM32 docs, I found another way to do this that would be cleaner, but that ship has sailed and I don’t want to confuse things anymore than they already are.
iNav does not have the triflight routines in it, so the feedback wire is not used. I’m working on getting this workin in iNav. I’ve got untested branches at the moment that are based off an older version of iNav, they need some updating.
See if triflight shows up as a feature, and if so, enable it.
I seem to recall making triflight a feature so flight performance could be evaluated with triflight turned on or off. This is different from the betaflight version where if you enable the trimixer, you automatically get triflight.
If it yawed a lot on takeoff, that’s the oscillation I’ve seen with the 0p7 version. I did push a few changes to the 0p7 branch last night that I had outstanding, that “may” fix the oscillation.
Like I said – it’s been a while since I looked at this in any detail…….