CleanFlight Ervaringen

dat flippen herken ik... bij mij bleek de bec niet in orde van de esc... nadat ik dus 1 van de andere drie ''goede'' becs heb aangesloten was toen het probleem weg. het kan ook slecht kontakt zijn of een motor die zwaarder loopt.
 
Is de cleanflight hex die hier gepost werd ook geschikt voor een cc3d? Ik vermoed dat het voor een naze is. Ik zou de versie van Borisb nl met de filter ook graag es proberen op mijn cc3d.
 
Mensen... Ik heb er nu ztw 20a esc's opzitten. Loopt als een zonnetje, geen rare tikken. Morgen op het veld testen. Vrijwel zeker dus dat mijn rctimer mini opto regelaars gewoon niet goed zijn. Ik hoop dat als ik er blheli opzet ze wel werken. Maar erg jammer dat ze zo nieuw verkocht worden.
 
Mensen... Ik heb er nu ztw 20a esc's opzitten. Loopt als een zonnetje, geen rare tikken. Morgen op het veld testen. Vrijwel zeker dus dat mijn rctimer mini opto regelaars gewoon niet goed zijn. Ik hoop dat als ik er blheli opzet ze wel werken. Maar erg jammer dat ze zo nieuw verkocht worden.

Finally!!! Good luck!
 
ACC calibration required it seems. Stick commands are helping in this case. ;)

I doubt that. The strange thing is, this problem was just temporarily at home. At the field one of the motors didn't work, but I could still arm/disarm without any trouble. At home, it refused to arm but after a while everything worked normally again. Anyway, I've studied the code a bit and this is how far I got:
- The code looks very clean; what's in a name ;) No coincidence I guess.
- At first I thought the blinking led L1 is triggered by "failureMode(3)", which is used a couple of times in the code. But this call is used during init only while my problem occurred at each arm-attempt.
- Led L1 on the board is actually LED0 in the code (the green middle led).
- Given this code, I think somehow OK_TO_ARM must be false. The effect is like !STATE(SMALL_ANGLE), so when tilting the the quad before arming, which causes blinking LED0. But it blinks for about 5 seconds when trying to arm while the quad if perfectly horizontal. I don't think the quad is calibrating, because that's not triggered by arming through the sticks.
/src/main/mw.c zei:
if (ARMING_FLAG(ARMED)) {
LED0_ON;
} else {
if (IS_RC_MODE_ACTIVE(BOXARM) == 0) {
ENABLE_ARMING_FLAG(OK_TO_ARM);
}
if (!STATE(SMALL_ANGLE)) {
DISABLE_ARMING_FLAG(OK_TO_ARM);
}
if (IS_RC_MODE_ACTIVE(BOXAUTOTUNE)) {
DISABLE_ARMING_FLAG(OK_TO_ARM);
}
if (isCalibrating()) {
warningLedFlash();
DISABLE_ARMING_FLAG(OK_TO_ARM);
} else {
if (ARMING_FLAG(OK_TO_ARM)) {
warningLedDisable();
} else {
warningLedFlash();
}
}
warningLedUpdate();
}

To be continued. This is a nice way to get the hang of CF code :)
Martin
 
I doubt that. The strange thing is, this problem was just temporarily at home. At the field one of the motors didn't work, but I could still arm/disarm without any trouble. At home, it refused to arm but after a while everything worked normally again. Anyway, I've studied the code a bit and this is how far I got:
- The code looks very clean; what's in a name ;) No coincidence I guess.
- At first I thought the blinking led L1 is triggered by "failureMode(3)", which is used a couple of times in the code. But this call is used during init only while my problem occurred at each arm-attempt.
- Led L1 on the board is actually LED0 in the code (the green middle led).
- Given this code, I think somehow OK_TO_ARM must be false. The effect is like !STATE(SMALL_ANGLE), so when tilting the the quad before arming, which causes blinking LED0. But it blinks for about 5 seconds when trying to arm while the quad if perfectly horizontal. I don't think the quad is calibrating, because that's not triggered by arming through the sticks.


To be continued. This is a nice way to get the hang of CF code :)
Martin
Als je dat volgende keer hebt. Linker stick links boven en rechter stick naar beneden ;). Acc zal dan gecalibreerd worden en kun je weer vliegen.

Dat het thuis niet werkte kan nou net zijn dat je quad onder een andere hoek op de grond stond ;)
 
Bedankt BorisB & FedorCommander, er is dus toch acc calibatie nodig. Dan begrijp ik de code nog niet helemaal :). Ik zat trouwens te neuzen in de trunk i.p.v. v1.8.1. Ik kan al wel deze waarneming verklaren:

Telkens als ik dat probeerde ging de gele (correctie: groene) (middelste) led op de naze32 een fractie van een seconde aan.

Dit wordt veroorzaakt door deze code in mwArm():

if (!ARMING_FLAG(ARMED)) {
blinkLedAndSoundBeeper(2, 255, 1);
}

Dit zit alleen in v1.8.1, In hogere versies zit deze code:

if (!ARMING_FLAG(ARMED)) {
beeperConfirmationBeeps(1);
}

Dit geeft dus geen visuele indicatie meer.

Martin

 
Goedemorgen,

Een maatje van mij heeft een raar probleem met z'n quad:

Flip 260, deed het prima met 1.8.1. Geupdate naar 1.9.0, instellingen hersteld, esc's gecalibreerd. Vanuit de gui (motors tab) werken de motoren perfect, ze starten tegelijkertijd, helemaal mooi. Via de zender starten de motoren niet allemaal tegelijkertijd, alleen als je in 1 keer lomp gas geeft wil het wel en kan je daarna ook prima vliegen... Rustig gas geven en de flip flipt...

Mijn flip draait al langer op 1.9, en dat gaat allemaal goed. Ik heb alleen esc's met BLheli, hij met SimonK. Iemand een tip waar dit aan kan liggen?

Bedankt alvast!

Dirk
 
Klink toch als ESC's niet goed ingesteld?

Bedankt BorisB & FedorCommander, er is dus toch acc calibatie nodig. Dan begrijp ik de code nog niet helemaal :). Ik zat trouwens te neuzen in de trunk i.p.v. v1.8.1. Ik kan al wel deze waarneming verklaren:



Dit wordt veroorzaakt door deze code in mwArm():

if (!ARMING_FLAG(ARMED)) {
blinkLedAndSoundBeeper(2, 255, 1);
}

Dit zit alleen in v1.8.1, In hogere versies zit deze code:

if (!ARMING_FLAG(ARMED)) {
beeperConfirmationBeeps(1);
}

Dit geeft dus geen visuele indicatie meer.

Martin
Ik weet niet exact waarom dat weg is, maar een beep sound en draainde motoren zijn voor mijn persoonlijk een goede indicatie dat armen gelukt is.
Wellicht zijn de led statusen ergens anders voor gebruikt?
 
Well... If it starts at same time in motor tab - should be fine?

May be pid_at_min_throttle and may be yaw_direction (this one seems was not set correctly after update and reimport, can make quad flip).
 
Die zijn toch netjes gecalibreerd, zoals ik al zovaak heb gedaan. En via de motors tab functioneert het prima, dat zou dan toch ook niet zo moeten zijn?
 
Well... If it starts at same time in motor tab - should be fine?

May be pid_at_min_throttle and may be yaw_direction (this one seems was not set correctly after update and reimport, can make quad flip).

Well, that's something to look al. I'll have a look at the manual to see what these exactly do. Thanks
 
Ik ervaar hetzelfde probleem;

Naze32 Acro Mode;
BLheli PPM min throttle 1,000 ms en max PPM max throttle 2,000ms. Gecontroleerd bij alle ESC's

Vanuit de motor tab starten de motors gelijk. Echter wanneer ik Throttle geef draaien motor 2 en 3 duidelijk harder. (gecontroleerd in de motor tab).

in de naze heb ik:
Min throttle; 1000
Max throttle 2000
Min command; 965

Problemen zijn onstaan na veranderen van zender / ontvanger. En gelijktijdig het flashen van BLheli.

Ik heb even contact gehad met Dirk77, echter zijn oplossing werkt bij mij niet.
 
Ik ervaar hetzelfde probleem;

Naze32 Acro Mode;
BLheli PPM min throttle 1,000 ms en max PPM max throttle 2,000ms. Gecontroleerd bij alle ESC's

Vanuit de motor tab starten de motors gelijk. Echter wanneer ik Throttle geef draaien motor 2 en 3 duidelijk harder. (gecontroleerd in de motor tab).

in de naze heb ik:
Min throttle; 1000
Max throttle 2000
Min command; 965

Problemen zijn onstaan na veranderen van zender / ontvanger. En gelijktijdig het flashen van BLheli.

Ik heb even contact gehad met Dirk77, echter zijn oplossing werkt bij mij niet.

blheli 14.0 erop
 
Back
Top