Debugging the tricopter mini racer

[lauka]

Now that I thought about it more the expected error of motor speed change should work well. The drifting can be prevented when there is still some thrust available. The servo needs to be fast in order it to work. Fortunately the motor braking down is slow as well.

The compensation could even be autotuned if user brave enough to do some jumps in tailtune mode.

[billyd]

I have no idea what’s in the code but I find it interesting that we tune the tail with the motor straight up and equal throws in each direction.

I think the tail should be setup with neutral at the point of zero yaw, and then +/- 50 degrees from that point (or 40 degrees I always forget).

This is the way to tune a heli tail. You set the gyro to rate mode, and mechanically adjust the tail rotor such that at stick center in a hover the yaw is zero. Doing this results in more throw in one direction than the other to overcome the main rotor torque.

In my mind we should be doing something similar in the tricopter. In other words, ending up with more throw to one side than the other, to equalize the response of the tail.

[lauka]

There’s talk about that in this thread and others. But shortly: once the FC knows the thrust factor it can calculate the yaw force at any given servo angle. Force x on left side is achieved on different angle than -x on the right side. It also knows where is the 0 position. This is why the angles need to be set up correctly so the FC can command an angle.

[billyd]

Yeah I think it might have been me before too lol. Thick headed.

[CmdrPrompt]

Lauka: You mentioned this when discussing the tail yaw authority on low rpm’s just a few posts back.

When it’s spinning slowly the servo would move lot more. It might help but it’s hard to fix when there’s no authority. Maybe in that case we could allow servo to travel fully left to help with the counteract.

Maybe it’s not the servo that should move further to provide more yaw authority on low motor rpm’s, I’m thinking it’s the other way around. How about spinning up the tail motor while tilting it to the sides and decreasing rpm while decreasing the tilt angle. This should provide more yaw authority while not providing any more tail lift if rpm increase could be matched to the thrust vectoring. Maybe Triflight already does this, I haven’t checked the code for this so I’m just thinking out loud sort of…

Anyhoo, I was just thinking about thrust vectoring which is pretty much what we do here. Consider inputting yaw only. In this case we want to keep the vertical vector the same while adding a horisontal vector. For this to be true, the motor rpm needs to increase along with the tilt angle.

[LeoTheHuman]

Well, what Triflight does, is it calculates the servo angle based on your yaw stick position and then speeds up the motor to keep vertical thrust the same as if it was vertical.

[lauka]

Started improving the yaw authority on throttle drops today, progressed quite well until the USB port gave up and won’t take software anymore :).

Here’s a crappy video I took from the last testing round:

[Terje]

Great work @lauka!

Going for my first flight on 0.5beta2 today with a new 250 sized 1806 motor based F3 target tricopter 🙂

BTW soldering the servo feedback wire into the F3 Tx instead of say RSSI WILL fry your servo (should have worn my glasses…)

The documentation on the awesome features are getting lost in history when you release new versions, any hope of adding feature descriptions to DOCS?

[PlanB]

Take a look here, guys, the same thing I was talking about – different tailtune result on virtual servo and with feedback wire.

@Lauka, if you still need it, here is a video of todays test flight with overlayed log: https://youtu.be/8jTlvLLNi8o
It’s quite shaky because of new PIDs and strong wind gusts, but there are long drops with minimal throttle on 1:49 and 1:32

If I understand correctly, you are implementing another coefficient, for compensating propeller acceleration, or, probably, two different coefficients, because accelerating and braking forces are not equal?
Something like servo_angle += (Thrust_t1 – Thrust_t0) * accel_factor

It’s great, because that damn tail drift ruins my “freestyle” attempts 🙁
Hope you will give us something to try soon.

[lauka]

Yes baaically like that.

There’s too many variables to my liking. It’s challenging to know when the motor is actually braking or accelerating. I used parameters for motor speeds separately for acceleration and deceleration. Plus a gain for the error fed to PID. When I got the numbers right it worked reasonably well. It’s funny how the copter swings the servo left when the throttle is dropped ;).

I haven’t continued the development as I’m too lazy to open the copter and change the board.

But as I said there’s too many variables to tune atm. Could release it as an experimental feature at aome point.

To make it accurate and really usable we would need ESCs with motor speed feedback. I think KISS ESCs provide this but there’s no support for that CF. Would be cool to have that.

[PlanB]

It seems that i should change ESCs and turn off active braking… don’t know what’s worse… but in current state TF is not for acro flying, will wait patiently until you manage to implement new code.

Thank you for your work, if i can help somehow, just tell.

BTW, is LUX still supported in triflight or you fully converted all features to integer calculations and we must use MWREWRITE?

[lauka]

Luxfloat is still the same old usable controller. Mwrewrite is just better for F1 boards.

[Jarno]

Yes, latest beta luxfloat won’t arm my flip32+ but mwrewrite works. But it did arm with 0.4. So like I see then fluxfloat is getting useless for F1 boards when more and more features and cpu heavy stuff is getting merged.
Cleanflight and betaflight are moving to F3 boards and F1 is getting slow for faster looptimes and syncs. F3 tricopter frame will be a must soon 🙁

[swissfreek]

Pretty sure @David already said he was working on an updated controller board, as well as an updated PDB board. So we wait (semi) patiently.

[rue]

I second @lauka – luxfloat is working fine on f1 boards and actually quite some cleanup has been performed in betaflight to remove some unnecessary floating point math. So unless you’re unhappy with 1 kHz PID loop your f1 boards will provide for happy flying for quite a while 😉

BTW – one way to skip some floating point calculation is to avoid using align_board_pitch and use the sensor alignment instead:

set align_gyro = CW0FLIP
set align_acc = CW0FLIP

None the less, I’m also very much looking forward to an F3 based frame 🙂

[Author]

Posts