Follow along with the video below to see how to install our site as a web app on your home screen.
Nota: This feature may not be available in some browsers.
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.
ACC calibration required it seems. Stick commands are helping in this case.![]()
/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();
}
Als je dat volgende keer hebt. Linker stick links boven en rechter stick naar benedenI 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 nameNo 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
Telkens als ik dat probeerde ging de gele (correctie: groene) (middelste) led op de naze32 een fractie van een seconde aan.
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.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
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).
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.
It has been posted by sskaug on rcg a few timeswhen it will be released?