@Hinkel: Hi, dude! You are known to me as someone with very good ideas over the years aside the mainstream copterfunctions.
I just want to repeat your idea here if i understood it right. You do a "normal" flight (with your new function) and when you idle on the throttlestick for 2 seconds althold is automatically engaged. When movement on the throttlestick re-appears althold is disengaged and the real throttlestick throttle is used again. Besides triggering autolanding and deadpilot failsafe stuff there might be some other problems with this procedure. During althold the althold controller will rise the virtualthrottle so that when re-engaging real throttlestick throttle (esp. with a deadband) you might see a rapid hightloss you will have to compensate for on the sticks quickly. To avoid that the althold should be able to rescale the real throttlestick input (= un-linearize it) for that flight session based on the averaged altholdthrottle and the real stickinput. I bit my teeth on that before, perhaps I was wrong with that idea and therfor just ran into the same wall over and over again. The althold should only be possible then in between a certain throttlestickrange like "copterflying = true" (or some other lower limit, perhaps a new number) and a upper limit (like you suggested) otherwise there might be trouble on the limits of the rc throttlerange. I have a hard time finding your github repo with google please can you post the link again, because it seems you already have tested code at hand (as I know you
) so just if you like to share it you are welcome.
@ Mr-Fiero: I have nothing new to present, because I was a) *lazy* (TM) and b) had to organize a birthdayparty as well...
I read across the vrbrain guys post on 3DR concerning that hybrid mode as they posted it. From what I read there it seems to be a similar idea harakiri already had at play: Oversteer PH with the sticks, but I guess they got the re-engagement of PH smooth and slick (without flyback to some previous gathered GPS position, like observed with my stuff). I can not flight test arducopter code anymore since I put my apm out of business after having much damage and after having a tree stopping a flyaway - I washed my underwear from brown stains (i think they call it "brownout") and shelfed the apm.
@ e_lm_70: Thank you for the flowers but baseflight has much improved and is definitely better structured and organized than my stuff. Harakiri was just started because there was no movement in the BF trunc that has dramatically changed and I am really happy about that! There were several lowlevel driver changes that BF made for good reason I didn't take over because a)I didn't want to change stuff that I knew worked very solidly b)I don't know that lowlevel interrupt stuff. Concerning your acc calibration question. Yes there is accelerometer and gps velocity fusion going on as well to improve fast reactions on sudden x/y changes. The acc calibration. Well that is a field that is beyond my limited mathematical understanding but I farted around with that a lot (even fusion of MPU6050 acc and adxl and mma). At the end of the day it seems to be sufficient to me to use the invense supplied 1G value (at the set scaling) and calibrate it like multiwii suggests with a flightcontrol that is eyeballed, maybe better, horizontal. That
http://imaginaryz.blogspot.de/2011/04/l ... -data.html algo gets better mag offsets but I couldn't get it to work better on acc or gyro offsets. The 3DR (since the opensource dev is completely company driven, that's why I mention that company here) acc calibration routine was lifted/copied/whatever people may call it from a project that used uncalibrated adxl (analog?) sensors, it adds hassle to the calibration but is (just from my findings) of limited use of already precalibrated digital parts like mpu, mma etc. Besides the supplied 1G value calibration method you can extend it by using pythagoras term to get the total sensor value of the resting sensor for 1G reference to cancle out slight mounting tilting. I once did it but not right of what I found out later when putting the copter upside down - I might revisit that procedure but don't expect miracles from it. However, everybody expects temperature drifts on the gyro part but they are more severe on the acc (especially z) values from what I've seen. So having a practical temperature compensation that really has impact on real life performance seems to me the first thing to engage concerning the calibration aspect of gyro AND acc. Ending up with explanting a flightcontrol putting it with lipo into a fridge/radiator is no practical option - or flinging around a big model around for acc calibration in a tight timeframe - I would sacrifice precision over practical and hasslefree operation any day. But that is a question of philosophy. There are probably some intelligent mathematical tricks available but they are beyond me.
P.s.: Sorry for slow going..
Cheers
Rob
EDIT: I just send this text because I was afraid the froumsoft would eat it, that's why I respond to your latest post here.
Thank you very much for putting your code on display, dude, I will definitely have a look at your work and I think many others will appreciate your work and effort as well..!
"
... instead of 6 position calibration like APM people .. just throw the control board from the 10th floor