BorisB
Forum veteraan
Er is veel info te vinden op forums, maar komt erop neer dat je filtering gaat scheiden.
Leuke start waardes:
gyro_lpf = 0
gyro_cut_hz = 100 (of 80 als het veel shakes heeft)
pterm_cut_hz = 50
dterm_cut_hz = 12
CleanFlight Ervaringen
- Topicstarter BorisB
- Startdatum
Leuke start waardes:
gyro_lpf = 0
gyro_cut_hz = 100 (of 80 als het veel shakes heeft)
pterm_cut_hz = 50
dterm_cut_hz = 12
@WaVe
Als je net begint met vliegen zou ik iemand anders zijn pids overnemen
Leuk nieuws voor iedereen. Op naze32 is de acc sensor wat veruit de meeste processing tijd in beslag neemt. Disablen van acc voor acro vliegers geeft een enorme vervbetering in looptimes. Ook al vlieg je in acro mode wordt de accelerometer gelezen. Zie onderstaand artikel. looptime van 300 is dan haalbaar
http://flysherlockair.com/2015/07/how-does-cleanflight-spend-its-time-lets-profile/
Disable van acc doe je zo (let op level en horizon features verdwijnen dan natuurlijk):
set acc_hardware = 0
Zo dat is een dramatisch verschil! Waarom wordt dit niet standaard gedaan wanneer de quad in acro mode zit?
*edit* - ah, waarschijnlijk omdat het artikel van vandaag is. Is dit al gemeld bij Hydra / CleanFlight Github?
BorisB
Forum veteraan
Nee dit is goed zo, want je kan anders niet schakelen naar level of horizon als je acro vliegt. Dus default gedrag klopt.
Als je acro alleen vliegt moet je het in de cli uitzetten dus
Het zou toch mogelijk moeten zijn om het wel of niet uitlezen van de acc waarden af te laten hangen van de huidige flightmode. Ik snap dat acc_hardware een flag is die niet in-flight kan worden bijgewerkt, maar de code kan hier toch voorzieningen voor maken?
Een simpele mode check voor het uitvoeren van de ic2 read kan al voldoende zijn, al wordt de looptime van angle / horizon mode hier wel groter door.
Misschien kortzichtig, C ervaring is beperkt
BorisB
Forum veteraan
Nee want dan kun je geen switch makenHet zou toch mogelijk moeten zijn om het wel of niet uitlezen van de acc waarden af te laten hangen van de huidige flightmode. Ik snap dat acc_hardware een flag is die niet in-flight kan worden bijgewerkt, maar de code kan hier toch voorzieningen voor maken?
Een simpele mode check voor het uitvoeren van de ic2 read kan al voldoende zijn, al wordt de looptime van angle / horizon mode hier wel groter door.
Misschien kortzichtig, C ervaring is beperkt
. Huidig systeem is zo gemaakt dat je ten alle tijden tussen alle vliegmodes kan switchen. Als je geen acc bijhoudt verlies je orientatie van de multirotor .Je moet het zo zien. Default instellingen zijn voor iedereen in meest gunstige scenario en als je performance win wilt moet je verder gaan tweaken.
Het is ook niet zo heel lang echt bekend dat lagere looptimes een enorme verbetering zijn, want toen waren er geen soft filters
BorisB
Forum veteraan
Nee dit zit in de nightly builds oftewel toekomstige 1.9.1.
Acc uitschakelen zat er altijd in natuurlijk. Dat is geen nieuws.
Nee want dan kun je geen switch maken
Och natuurlijk, hij gebruikt zijn init als referentie. Als je mid flight plots de acc wel gaat bijhouden klopt je referentie van geen kant
Duidelijk verhaal, ik volg jullie software filtering discussie op github met interesse
Laatst bewerkt:
long time no see
Ik ben nu ook omgeschakeld naar PID1 (rewrite) in plaats van lux (niet vibratieloos te krijgen) en harakiri (goed, maar niet zo goed) en maaaaaan wat een verschil. Ik begin nu locked feel te krijgen eindelijk!
@BorisB thanx voor de tip! ik ga die set acc_hardware = 0 eens proberen!!
Ik ben nu ook omgeschakeld naar PID1 (rewrite) in plaats van lux (niet vibratieloos te krijgen) en harakiri (goed, maar niet zo goed) en maaaaaan wat een verschil. Ik begin nu locked feel te krijgen eindelijk!
@BorisB thanx voor de tip! ik ga die set acc_hardware = 0 eens proberen!!
Met luxfloat had ik een P van ongeveer 0.6 op de roll en pitch nodig om oscillaties er uit te krijgen. Vloog voor de rest wel goed.long time no see
Ik ben nu ook omgeschakeld naar PID1 (rewrite) in plaats van lux (niet vibratieloos te krijgen) en harakiri (goed, maar niet zo goed) en maaaaaan wat een verschil. Ik begin nu locked feel te krijgen eindelijk!
@BorisB thanx voor de tip! ik ga die set acc_hardware = 0 eens proberen!!
Met:
cobra2300kv
Kiss 18a
5x4x3 hqprops
Nanotech 1300 45-90C
AUW 550gram
Looptime op 1500.
BorisB
Forum veteraan
InderdaadOch natuurlijk, hij gebruikt zijn init als referentie. Als je mid flight plots de acc wel gaat bijhouden klopt je referentie van geen kant
Duidelijk verhaal, ik volg jullie software filtering discussie op github met interesse
long time no see
Ik ben nu ook omgeschakeld naar PID1 (rewrite) in plaats van lux (niet vibratieloos te krijgen) en harakiri (goed, maar niet zo goed) en maaaaaan wat een verschil. Ik begin nu locked feel te krijgen eindelijk!
@BorisB thanx voor de tip! ik ga die set acc_hardware = 0 eens proberen!!
Yes luxfloat picks up any tiny noise and tries to correct itacc_hardware=1 actually. and it flies great with kisses and looptime 800. enjoyed yesterday a lot with @m00st
i also gave up on luxfloat on minis. but b330 loooooooves it! i guess ckean pkate helps and weight also.
. I guess it can work with enormous amount of filtering.PID1 and rate mode is unbeaten yet! Super locked in
Yes luxfloat picks up any tiny noise and tries to correct it
PID1 and rate mode is unbeaten yet! Super locked in
I'm using LuxFloat on a 250 sized quad. Allthough I have had to increase filtering on the acc by a small margin (up to 20 on acc_lpf_factor in stead of the default 4) to get it to fly stable in angle mode, it has been very stable in acro mode without any additional filtering.
P around 3.0.
BorisB
Forum veteraan
Did you ever anayze luxfloat in the blackbox?
The motors get much more noise and produce more heat when the filtering is not set correctly.
@FedorCommander
Well honestly I still like to have my level mode in case somebody knocks my video out. It just helped me saving my rig many times
. Naze32 is really poor with floating point math.