Debugging the tricopter mini racer

[Andrew]

@David based on your last reply to Jose, I see you know about the ‘kick’ when rapidly changing rudder. That is, how the mass of the motor gets thrown in the direction of yaw turn. And that jolts the rest of the copter in the direction opposite of your intended yaw (conservation of momentum).
I’m feeling like solving this problem with a redesigned tail mech may be important for an optimally performing mini tricopter.
Something like this where the center of mass of the pivoting parts lines up with the servo axis:

This tail mechanism is more complicated though and 3d printing may not be an option for strength reasons…

Thoughts?

Attachments:

1. 

   tiltmech.png
   

[LeoTheHuman]

The biggest problem with this mechanism is that it depends on the motor you’re using. There’s no way you can make this fit all motors, which can all be used on the tricopter, on the same mount. We’ll need different parts for different motors, which will be quite inconvenient to sell.

[underdog]

@LeoTheHuman: Using shims it could rather easily be adapted to accept/fit a rather wide range of motors, not far from the extreme range that fits today.
I like the Idea 🙂

[GAntonjo]

And, even if the balance will not be perfect for all possible motors, any improvement is better than none.

[lauka]

Here’s the first compilation of the Triflight 0.1 (yes I renamed the fork to distinguish it from Cleanflight builds:) ).

I did a flight test on it, I saw no difference to the 1.9.0 based firmware. It’s pretty safe to take it into use.

I also created a branch to the fork where I picked some of the interesting commits from Boris B’s betaflight fork. See list of included commits: https://github.com/lkaino/Triflight/tree/betaflightPick.

Some highlights of the betaflightPick branch:
– ESC 1-wire passthrough, see https://github.com/borisbstyle/cleanflight/blob/betaflight/docs/1wire.md
– Gyro synced looptime, it’s enabled by default.
– Optimized luxFloat controller.

I did a quick LOS flight test with this one also, noticed no big differences on a normal size Tricopter. It felt like I could up my yaw PID gains a bit, though.

The attached archive contains Naze32 HEX file for “official” Triflight firmware and the betaflightPick branch. Please consider taking it into use, as the 1.9.0 based firmware is discontinued as of now. Please do a full chip erase once again when updating, and use the backup and CLI dump feature to restore your settings. Please check that also the TPA related CLI parameters are included in the dump. I did test that they are included in a dump from this version.

@David and anyone else who’s tuning the mini-tri should be aware that this firmware does contain many many changes over the 1.9.0 based, upgrading might bring some new unwanted variables to the picture :).

Attachments:

1. triflight_0.1.zip

[Terje]

Great work @lauka! Could you sum up the CLI parameters that differ from the official Cleanflight 1.9.0 firmware? YAW TPA etc.

Still blowing gale winds (or at least more than is safe for testing) here in Denmark, but hoping the weather will permit test flights this weekend. How much does OneShot play into the flight performance? My current Afro 20A slims don’t seem to support the feature reliably.

[LeoTheHuman]

So many people are not happy about afro slims, that I’d suggest to use BL20A instead. These are 1 to 1 replacement and have good one shot and dampened light support. I’m currently flying four 150-250 sized quads with them and only had desync problem with one ESC out of 12 from 2015.06 batch. My full size tricopter rebuild will definitely feature these and T-Motors.

[LeoTheHuman]

Answering your original question: one shot allows you to use much lower loop times efficiently. I noticed a very big improvement in the stability of the flight when I switched to 1500 looptime instead of the default, mostly on smaller crafts, which are less stable usually.

[lauka]

@LeoTheHuman, the DYS BL20A from 06-15 batch are known to have soldering issues, and manufacturer is replacing those if you have the bags that they came in with the sticker: http://www.rcgroups.com/forums/showpost.php?p=32278081&postcount=27928.

@Terje, Good idea, I ran a diff on the parameters:
1.9.0 vs Triflight 0.1:
tpa_yaw_rate & tpa_yaw_breakpoint

yaw_direction —> yaw_motor_direction
gimbal_flags —> gimbal_mode

dterm_cut_hz
pterm_cut_hz
gyro_cut_hz
magzero_x
magzero_y
magzero_z

Information of these in https://github.com/cleanflight/cleanflight/blob/master/docs/Cli.md.

1.9.0 vs Triflight 0.1 betaflightPick:
sync_gyro_to_loop
rc_smoothing
Information of these in Boris’s post in RCGroups.

[LeoTheHuman]

I know that. Didn’t keep the bags, unfortunately, but having to throw away just one bad ESC is fine with me. Or I can even try to reflow it at some point.

[lauka]

I would like feedback from the I term limit increase, wondering if it is needed now with the yaw TPA. Anyone done a recording on blackbox?

I fear that it might make things worse as if we allow the term to wind up to 500.

I ordered an Openlog for myself, but it will take forever to arrive.

[JediJeremy]

I’m wondering… is there anyone working on a Kalman filter model? I really haven’t been keeping up with the state of cleanflight. But the background math I know says that tricopters would benefit more from the full Kalman than quads would.

If there isn’t anyone currently doing it, then do we want to start? I can do a lot of the work, but I get distracted easily, and would need help with the follow-through and testing.

For background, PID filters are soooo last millennium. They’re reliable, but prone to oscillations and feedback between separately managed elements, especially if there a non-linearities in the interactions between the elements. (cough – tiltmechanism – cough!)

In other words, in PID-only systems, each ‘axis’ has to wait for the effects of other axis PID controllers to ‘go out into the world’ before the effects are sensed and fed into the other PID loops.

Any system which begins to add software feedback between the modules which seeks to prevent or predict the effects of each physical PID axis on the others is, by definition, a Kalman filter. A ‘restricted’ one, anyway.

A ‘full’ kalman filter is basically a complete physical description of the device, in the sense that it ‘filters’ the state vector to the next time-step using an equation that’s supposed to correspond with how reality works. The Kalman filter for a car takes the current car position, speed, and control inputs like steering wheel position and uses it to predict the location/state of the car at the next time step. It models the fact that turning the steering wheel left, makes the car turn left by a proportional amount, so long as nothing’s broken. The more physics you stuff into the model (tyre friction, inertia) the better.

Once you have a Kalman filter description, you can use it for many tricks. Predicting the effects of controllers on each other without waiting for them to loop back through physical sensors is the primary goal, but there are others.

The Kalman filter is self-correcting. Once you’ve got it into a roughly correct description, it ‘fine tunes’ it’s own model to better match the reality it sees. (via simple ‘does this slight adjustment work better!’ gradient descent.)

The kalman filter can deal with uncertainty. GPS that comes and goes, noisy sensors, the filter matrix quickly notes that its model has gone ‘off the rails’ and re-adjusts its ‘trust’ in each sensor input to discard obvious garbage.

The trade-off? Kalman filters require a lot more CPU (especially in ‘learning mode’) than simple PID loops. And the math is scary. Arduino-level boards are not capable of the full algo, but I believe the Naze32 is. Many people are nibbling around the edges of this, seeking practical solutions, without really knowing what they’re chewing on.

If you really want to solve all the Tricopter physics issues in one go, with a proven algorithm that has other applications as well, then we have to go the full Kalman. Sorry, it’s the Math.

[shufty]

Just finished rebuilding my v3 into a mini tri, now starts the laborious task of getting it to fly reasonably!

I can’t say I’m a fan of the whole tuning part, I’ve been trying to keep up with what old mate Boris B has been doing with Betaflight and it hurts my brain a bit…

[LeoTheHuman]

I’ve been considering that and a switch to quaternions for a while, but then quaternion calculations arrived into cleanflight. There might be people doing that exact thing now, so I decided to wait.

[lauka]

@JediJeremy, Utilizing a Kalman filter is a fascinating idea, and as you said, with a good model is a base for many other use cases.

IMO the limitation is computation power of Naze32. Racers want their control loops as fast as possible. The MPU6050 gyro can provide data at 128 us plus Cleanflight running many other features. It can be challenging to create a Kalman model that can compete with PID controllers at these requirements.

Kalman filter or other self-tuning control will be the thing in the future, that’s for sure.

I’m intrigued to help you or anyone with the design should you decide start the work on it. It would help if there was some simulation environment where the model could be implemented and tested..

[Author]

Posts