I'm delighted to announce the release of ArduPlane 2.50 for your flying pleasure. This release has a lot of advances to some of the core ArduPlane code, and should be a big improvement for many people.
Perhaps the most important change in this release is the new DCM code that does acceleration correction based on the GPS. This improvement is based on work by Bill Premerlani which really advances the state of the art for attitude estimation on small microcontroller based autopilots. The improvement in attitude estimation is very noticable in flight, resulting in significantly more accurate control. Many thanks to Bill for his patience in working with Jon Challinger and myself to bring this improvement to ArduPlane.
Other significant improvements include:
There is one change in this release which may require some re-tuning. We were using the wrong value for time delta when using the PID controller for navigation roll. This has been fixed by making the PID library calculate the delta time internally, but it means that existing HDG2RLL_I and HDG2RLL_D values will be incorrect. I have fixed the defaults, but if you have your own settings for these, you will need to drop HDG2RLL_I by a factor of 5, and raise HDG2RLL_D by a factor of 5 to get the same result as for the previous release.
Thanks to everyone who has contributed to this release!
For the next release the plan is to concentrate on improved stabilisation and navigation controllers, based on the great work being done by Jon Challinger.
I have two questions.
Is FBW_B elevator still reversed in 2.50?
Can i read RSSI information trough MAVlink now?
WOW thx a lot.
Hmm strange can't compile it with the arduino-0100-relax with the 2.4 there wasn't any problem.
Has something changed do I need to take the "real" arduino IDE?
EIDT: OOOPS my fault didn't copy the whole zip into the sketch folder :)
Is there a way to have altitude hold flight if I do not have an airspeed sensor? I would like to be able to just fly around at a constant altitude.
The FBW_B behaviour hasn't changed. Maybe I should add a parameter to control what direction people want the elevator to go for FBW_B ? Some people want it one way and some want it the other.
Altitude hold works fine both with and without an airspeed sensor. The only time when an airspeed sensor is really critical is when you are flying close to the stall speed, which usually only happens when you are landing.
I forgot to answer your 2nd question. If you have a 3DR radio you get RSSI for that radio through MAVLink, but otherwise we don't yet have it. It's not a big change to add it as long as your receiver/radio gives RSSI in an analog voltage of no more than 5V. Did you submit an issue so I remember for next time?
First of all, thank you for your attention!
I did not submit this as someone already did: Link
And here is my topic where we are trying to make MinimOsd better: Link
To have RSSI would be great! :)
Also got another question; witch port should i use for RSSI on APM1?
On APM2 there is a sign.
I submit an enhancement request about RSSI readings. For example, my RX gives 0.5V for minimum signal and about 1.0 V for maximum. The analog read is linear.
This is the request in the arduplane page:
Thanks for your effort.
Regards from Spain,
That would be great!
What made me confused is that i take off in manual mode, than flying a little in stab mode than switching to FBW_B. Suddenly the elevator starts to work reversed. I was like, ughhhh What is this? :D
As FBW_B is very "automatic", it is not a huge problem, but does not feels comfortable.
The reason that I am confused is because I don’t know what mode to use. I don’t see an Altitude Hold Mode. FBW-B looks like the mode I want but it says that it won’t work without an airspeed sensor and reverts back to FWB-A, which is NOT Altitude Hold. So you see why I am confused?
The RSSI that you are talking about here is not the one we would like.
On the receivers in our planes we have a RSSI output that can be feed to the APM. It can vary greatly from receivers to receivers. I own two from the same company, one goes .5 volts for a bad signal, to 1 volt for a good. The other .5 volts is poor, 3.3 is good.
We can however decode it on the MiniOSD if the raw voltage would be transmitted on the Mavlink message "MAVLINK_MSG_ID_RC_CHANNELS_RAW". Right now it is locked to a 1.
A few lines of code is all it would take, one maybe in the sensor.pde, two in the MAVLink.pde.
Myself, I have tried to modify the APM code, but as you know, a simple change could cause other things to fail, and would rather let the experts handle the APM. As for the MINIOsd, if it fails in flight due to a software bug, I don't lose a plane.
Thanks for reading