I've just released ArduPlane 2.65
This is what is known in the free software community as a "brown paper bag" release, because the developer (that's me) thinks he should hide his head in a brown paper bag out of sheer embarrassment.
Steven G noticed that my fix for stick mixing in CIRCLE mode in 2.64 broke STABILISE mode. When I test flew 2.64 I tested FBWA, but not STABILISE mode!
So the only change in 2.65 is to fix that. My apologies for the 2.64 release!
Cheers, Tridge
Replies
I experienced a similar issue like Rana.
In FBW-A mode the plane suddenly push down the nose (approx. -20 degree) and losing alt while the GCS/ArduPlane shows positive pitch.
You can see the event in this video: https://www.youtube.com/watch?v=6O5F5j9uAJg at around 0:35 and my PID settings are:![3692525267?profile=original](https://storage.ning.com/topology/rest/1.0/file/get/3692525267?profile=original)
Do you have any idea what happened? What is wrong with my config?
I'm trying to load 2.65 onto an APM1.4 using Arduino1.0.1, but the sketch is too big: Binary sketch size: 130,702 bytes (of a 126,976 byte maximum)
Interestingly enough, the .hex loads fine using Mission Planner. Any thoughts?
hi...i compiled the 2.65 code for apm 2 and in stabilized mode the ailerons not respond...please any helps
thank you
Andrew,
Thanks for the update and congrats to your win.
I was flying 2.65 (last commit 1fe413e17d4634b2bc120dd76a0349e4d178090f to be precise) on APM 1 1280 a few days ago and noticed some strange startup effects. Before filing an issue I wanted to doublecheck that this is not specific to my setup. I power the APM, GPS and Xbee seperate from a 7805 voltage regulator (like a few other people and it works great) while servos and receiver are powered from the ESC.
In order to use AUTO_TRIM I power up first the receiver via the ESC (which doesn't arm when it doesn't get any input so I think I'm safe:-). Strange thing is if I power up in this order, in FBWA I get a correct control surface reflection which however is very slow (much too slow). If I first power up the APM, let it initialize and then connect the battery to the ESC all is fine (but I guess it does not get the trim values although I haven't checked that yet). So I wonder why this is..
Should maybe look at the code but I wanted to mention it here since I remember reading someone else wondering about slow control surface movement in pre-flight check of FBW.
Cheers, Andre
After your win Andrew me thinks that brown paper bag can be thrown away for good :))
Im new on Arduplane. (tested some Arducopter, but now i will try Arduplane)
I checked the Wiki, but i did not found any answer.
Works the Arduplane on APM1 with 2 seperate aileron servos?
I dont want to use an Y cable.
And when, where to connect them?
Andrew,
ArduPlane 2.65 looses altitude drastically soon after it takes turn toward the waypoint, after the auto take off but after loosing some 20-25 mt of altitude, it recovers altitude.
The situation can be dangerous as If I set say 25mt altitude for auto take off than chances are the plane will hit the ground when it just starts turning to the waypoint, immediate after auto take off. Video clip is for reference.
Why it shuts off throtle for some time when it take turn, soon after auto take off ?
Hi all,
I noticed some strange behaviour since the last update (or maybe it was already a few updates ago as I haven't flown since 2.62 - which worked fine). At first I thought I made a mistake somewhere, but I really can't find anything, so I thought it might be in the code?
Basic problem is that when I tilt/roll the plane, the estimated attitude is ok for a second, and then moves back to 0 (while keeping the plane angled).
I documented it as extensive as possible here.
Thanks for any help!
Hi.
Please fix the short failsafe that uses circle, instead of RTL.
Circle does not even maintain altitude, and increases the risk while near terrain or ground.
It's working *very* well, very accurate and good navigation.
Thank you.