Developer

ArduPlane 2.50 released

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:

  • updates to the barometer driver to sample the pressure and temperature much more rapidly, leading to better altitude estimation
  • updates to the AP_AnalogSource driver to be interrupt driven, allowing us to sample all analog sources much more rapidly. For ArduPlane this improves the airspeed sensor on the APM2 a lot.
  • updates to the waypoint completion logic, to use a "finish line" algorithm. This prevents the problem of circling around a waypoint when we miss it by more than the waypoint radius. The waypoint is now considered complete when we pass a line that is perpendicular to the track, and passing through the target waypoint.
  • improvements to the AP_Mount code, allowing for control of roll/pitch/yaw stabilisation via EEPROM variables that can be set over MAVLink. This allows you to setup the mount once, and it will resume operation as soon as you boot. These changes also fix a number of bugs in the AP_Mount code, so it AP_Mount hasn't worked for you, please try again. Many thanks to Greg Fletcher and Amilcar Lucus for the AP_Mount improvements.
  • Lots of improvements to the ArduPlane parameter documentation.  This documentation should be the first place you look when trying to understand ArduPlane configuration parameters. Many thanks to Andreas Antonopoulos for his great work on generating these wiki docs based on the source code markup.
  • New LAND_PITCH_CD parameter to control the landing pitch when not under airspeed control. Thanks to Jeff Taylor for fixing this!
  • New SCALING_SPEED parameter that allows you to set the base speed for scaling PIDs. Previously we assumed a standard speed of 15 m/s, which is too low for fast aircraft. By adjusting SCALING_SPEED you can have the same set of PIDs for both airspeed and non-airspeed flight control.

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.


Happy flying!

Views: 12184

▶ Reply to This

Replies to This Discussion


3D RoboticsPermalink Reply by Chris Anderson on July 25, 2012 at 9:03pm

Congrats, Tridge!

Permalink Reply by Eagle on July 27, 2012 at 7:52pm

+1

Permalink Reply by Gábor Zoltán on July 26, 2012 at 12:21am

Hi Andrew,

I have two questions.

Is FBW_B elevator still reversed in 2.50?

Can i read RSSI information trough MAVlink now?

THX,

Gábor


DeveloperPermalink Reply by Andrew Tridgell on July 26, 2012 at 6:04am

Hi Gábor,

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.

Cheers, Tridge

Permalink Reply by Gábor Zoltán on July 26, 2012 at 6:24am

Hi Andrew,

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.  

Thank you

Gábor


DeveloperPermalink Reply by Andrew Tridgell on July 26, 2012 at 6:07am

Hi Gábor,

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?

Cheers, Tridge

Permalink Reply by Gábor Zoltán on July 26, 2012 at 6:20am

Hi Andrew,

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.

Thx again,

Gábor

Permalink Reply by Dario Lindo Andres on July 26, 2012 at 6:21am

Hi Andrew,

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:

http://code.google.com/p/ardupilot-mega/issues/detail?id=687&so...

 

Thanks for your effort.

 

Regards from Spain,

Dario.

 

Permalink Reply by Burt Green on July 26, 2012 at 8:12am

Andrew

 

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

 

Burt Green

 

 

Permalink Reply by Steven G on July 26, 2012 at 9:48am

Andrew and team, great job. I am migrating from other well known, top notch OSD/Autopilots and I have to say the APM2 is quite magnificent! In not small way, due the the SW/FW.

Wrt RC RSSI, would it be possible to accomodate Analog and digital RSSI? The EZUhf outputs only digital RSSI. With the data radios, I am trying to avoid cost and weight of additional equipment by using the GS for most all OSD functions.

Thank you

Steven

Permalink Reply by Marcin Krawczyk on August 1, 2012 at 6:59am

Hi :-)

I'm implementing MAVLink reading into antenna tracker (Arduino based). Now I can read heartbeat (MAVLINK_MSG_ID_HEARTBEAT) and GPS raw (MAVLINK_MSG_ID_GPS_RAW_INT) packets without any problem, but I can't see any "radio" packet (MAVLINK_MSG_ID_RADIO):

mavlink_message_t msg;
mavlink_status_t status;
while(Serial.available() > 0) {
uint8_t c = Serial.read();
if(mavlink_parse_char(MAVLINK_COMM_0, c, &msg, &status)) {
switch(msg.msgid) {
[...]

case MAVLINK_MSG_ID_RADIO: {
lcd.setCursor(0, 0);
lcd.print(mavlink_msg_radio_get_rssi(&msg));
lcd.setCursor(0, 1);
lcd.print(mavlink_msg_radio_get_remrssi(&msg));

}

What am I doing wrong?


DeveloperPermalink Reply by Andrew Tridgell on August 1, 2012 at 5:41pm

Hi Marcin,

The only device that generates RADIO packets is the 3DR telemetry radio. It will produce one RADIO packet for each HEARTBEAT packet that it sees coming over the serial link. So the radio will send RADIO packets to the APM when the APM send a HEARTBEAT packet to the groundstation, and the ground radio will send a RADIO packet to the ground station when the ground station sends a HEARTBEAT packet to the plane.

Maybe this will help you track it down?

Cheers, Tridge

RSS

Social Networking

Top Content 

1 ArduCopter-3.0 ready for wider use

ArduCopter-3.0 ready for wider use
2 APM Project vs DJI NAZA and WOOKONG

APM Project vs DJI NAZA and WOOKONG
3 APM 2.5 with NEO-6M ublox gps (not 3DR LEA-6)

APM 2.5 with NEO-6M ublox gps (not 3DR LEA-6)
4 Flying 3D Spline Curves between Waypoints with ArduCopter 3.0

Flying 3D Spline Curves between Waypoints with ArduCopter 3.0
5 APM Copter 2.9.1.b has been released

APM Copter 2.9.1.b has been released
6 10k autonomous flight - telemetry guided flight, and other APM tests!

10k autonomous flight - telemetry guided flight, and other APM tests!
7 MAAT final version is being tested

MAAT final version is being tested
8 Getting ready for Arducopter 3.0

Getting ready for Arducopter 3.0
9 Help Tuning Arduplane 2.73 With A Large Slow Airframe

Help Tuning Arduplane 2.73 With A Large Slow Airframe
10 How to succeed without really trying

How to succeed without really trying

Contests

Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.

A list of all T3 contests is here. 

Groups

Advertisement

© 2013   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service