CleanFlight Ervaringen

I dont bother anymore. All configs are in git ;) copy paste is a good habbit.
Not all of us are programmers [emoji12]

But indeed, copy your configuration (for each profile, if you do use profiles) and paste them in the upgraded version works for me. In most cases that is, as I've noticed I have to paste the aux settings independently sometimes. Almost as if the data gets lost during pasting.
 
Probleem is weg, maar ik had de indruk dat het compass nu soms afwijkingen vertoont. Had het wel niet gecalibreerd na de laatste FW flash, dus dat kan nog een probleem zijn. Ik ga snel nog even verder testen na calibratie.
 
I know, but my hair is turning grey... ;-)

@boris: it seems to work fine now, I almost see no difference between with or without compass. Is this modification done on 1.9.0 release or did you mod your fork with the Pt1 stuff for the D factor? Maybe a good pull request?
 
I know, but my hair is turning grey... ;-)

@boris: it seems to work fine now, I almost see no difference between with or without compass. Is this modification done on 1.9.0 release or did you mod your fork with the Pt1 stuff for the D factor? Maybe a good pull request?
I only narrowed down the deadband.
If I understand correctly you were testing on 1.8.1?
It would be nice if you first try 1.9.0 stable perhaps to make sure behaviour is the same.

This version has no dterm filtering, but harakiri had always one.

You can create an issue for this and see what everybody else will say :). I have no idea of the background for the one who designed this behaviour and why they chose rccommand of 70? But that probably is multiwii legacy :)
 
No, initial I was testing on 1.7.2, but I also tried 1.9.0 public release to no avail.

My guess is that the value of "70" used to be a good value to filter out jitter on the YAW Rc output, but became too much in later versions of the FW. Also YAW_Deadband seems to do the very same thing, doesn't it? Or is YAW_Deadband really filtering out +x to -x so you won't see any YAW movement between these limits, so IF 1500-x<RCin<1500+x THEN RCout=1500?

In my case the movement was visible, but after centering the sticks the heading returned to the initial value as magHold wasn't updated. But I don't see any reason why magHold shouldn't be updated as it will not allow small YAW movements at all. Strange that it used to work fine in Harakiri 2.5 SG, I'm still flying that version on a Rachel frame with UltraESC ESCs without any issues, but as you told before a lot has been changed regarding YAW in the latest CleanFlight versions.

Thanks again for helping me out, and also FedorCommander for thinking with us!

When I have a spare moment I will create an issue for this in the GitHub.

EDIT: Opened issue https://github.com/cleanflight/cleanflight/issues/1019
 
Laatst bewerkt:
Hm... NAZE has 3 leds... Blue (always on), red and green... Yellow???? Are you sure naze finished all calibrations before you arming it???

Thanks, good point. I guess it is green then :). Next to the bright red and blue leds, it's hard to see its real colour. Anyway, I'm talking about led L1. When powering up, the leds flash a couple of times. After 2 seconds or so, I'm able to arm using the stick-method.

I tried powering the quad first, powering it at an angle, powering after having unplugged one ESC. But the error condition cannot be replicated any more. I'm just wondering what the blinking led means. It blinked about once per second after arm-attempt, during about 5 seconds. Perhaps have a peek in the code. To be continued.

Martin
 
Ik lees op RC Groups dat er aardig wat mensen zijn met SN20A ESC's en BlHeli erop draaiend met Cleanflight 1.9.0, dat de motors en/of ESC's heet worden. Ze gooien Cleanflight vaak terug naar 1.8.1.

Meer mensen last van??
 
Ik lees op RC Groups dat er aardig wat mensen zijn met SN20A ESC's en BlHeli erop draaiend met Cleanflight 1.9.0, dat de motors en/of ESC's heet worden. Ze gooien Cleanflight vaak terug naar 1.8.1.

Meer mensen last van??
Ik vlieg al lang met dat setup en totaal geen last van.
Sterker nog er is niets gewijzigd wat dat zou kunnen beinvloeden in 1.9.0.

Hete motoren zijn altijd resultaat van (over)tuning of teveel vibraties.
Ik tune ook mijn quads op basis van voelen hoe warm de motoren zijn :)

Teveel microvibraties wat je vaak wel hebt op een mini zorgen ervoor dat D gain op hol slaat omdat deze al deze snelle bewegingen wil dempen wat vervolgens in snel pulserende motoren resulteert.
In sommige gevallen hover je al met motoren die heel snel naar full power oscilleren :)
Dit kun je tegengaan door een Dterm filter in de flight controller in te bouwen.
 
Some flying yesterday with Boris TP1 element fix on CF 1.9.0 ;)


Enjoy.

PS motors and kisses were stone cold, gopro hard mounted without any dampeners...
 
Laatst bewerkt:
You need go to use Boris PR firmware. It uses dterm filter with turned off or set to 188hz low pass filter of gyro. I think it works very very well!!!. :)))
 
En de dterm filter hoe zet je die aan?

You need go to use Boris PR firmware. It uses dterm filter with turned off or set to 188hz low pass filter of gyro. I think it works very very well!!!. :)))

MPU6050 delay overview :)
28c4a6b4-15fc-11e5-8f0d-97f7220d2e04.jpg
 
Back
Top