Developer

ArduPlane 2.30 released!

The ArduPilot development team is delighted to announce the release of ArduPlane 2.30. This release replaces the current stable release (version 2.28) and is a recommended upgrade for all ArduPlane users.

DCM updates

The main focus of this release is increased stability in the AHRS system. Using simulations and flight logs the dev team found a number of ways to improve the DCM code at the core of ArduPlane to make it much more resistant to sensor noise and to improve its accuracy during tight turns. The most important result is the noise resistance, with simulations showing that the new AHRS code can resist noise levels several times higher than the previous code.

The new code also copes better with linear acceleration. Several ArduPlane users had noted the tendency of ArduPlane to pitch its nose down immediately after a hand launch. While there are several possible reasons why this can happen, one common one was that the linear acceleration of the launch was being interpreted by the attitude code as an upward pitch, which led to ArduPlane compensating incorrectly by pitching down the nose. The same thing would happen in any manoeuvre which involved significant linear acceleration. Simulations show that the new system produces much better pitch accuracy as a result.

The new DCM code is also a lot faster, which means we now have more CPU free for additional features in future releases.

EEPROM Config update

This release is the first to include the new 'AP_Param' configuration system, which replaces AP_Var for saving parameters to EEPROM. The new system uses a lot less memory than the old one (saving about 2.2k of RAM out of a total of 8k on the board). That extra memory will give us the opportunity to expand the feature set of ArduPlane in future releases.

The new system also makes it easier to expose some previously hidden internal parameters to users setting parameters via MAVLink. In particular, it is now possible to set the compass offsets over MAVLink, a feature which is discussed more below.

Compass setup

This release includes a lot more control on how the compass is used in flight. It is now possible to use the APM Mission Planner to find good compass offsets based on a telemetry flight log and then to lock in those offsets for future flights, disabling the automatic offset updating system by setting COMPASS_LEARN to 0. The planner will update the new COMPASS_OFS_X, COMPASS_OFS_Y and COMPASS_OFS_Z parameters to ones chosen based on optimising the offsets against a flight log.

By using the new COMPASS_USE parameter it is also possible to setup ArduPlane to log compass data while not using the compass for yaw control (instead using the GPS). This is useful for gathering good initial data for compass calibration. You can also use COMPASS_USE to enable/disable the use of the compass for heading correction while in a flight, which allows much easier testing of GPS vs compass based navigation.

Hold course on landing

The auto landing code has been updated to avoid a problem where the course hold in the final stages of the landing could produce a significant roll due to cross-track errors. The previous code locked the heading onto the cross-track heading, whereas the new code locks the heading onto the current heading in the final meters of the landing. The two headings are usually close, but in a cross wind there can be enough discrepancy for the old code to tip a wing into the runway.

Rudder in elevon mode

Thanks to a patch from Phil Cole, ArduPlane now supports use of a rudder on an elevon based plane. All the usual rudder controls are possible, which will allow elevon planes with rudders to improve their flight considerably.

Saving airspeed in mission

A minor change was made in the handling of airspeed/groundspeed changes during missions. Previously if you used a mission command to change the target airspeed then this would be saved to EEPROM and would be used for all flight modes, necessitating a reset of that parameter before the next flight if the changed airspeed target was only appropriate for that mission. The value is now only set in memory and not to EEPROM.

compass enable/disable in flight

It is now possible to disable the compass while in flight. Previously if you disabled the compass while flying the DCM code would continue to use the compass heading as a yaw reference, but that heading would not be updated, so navigation would be impossible. ArduPlane can now change to using the GPS. This is useful for longer flights if the operator suspects a problem with the compass.

logging of DCM and HWSTATUS

The MAVLink telemetry logs have been updated with additional messages giving a lot more information about the internal behaviour of the DCM AHRS system and the hardware. The DCM messages make it much easier to diagnose tricky problems such as gyro drift, while the HMSTATUS messages allow the operator to monitor I2C bus errors and the board voltage.

CLI on a 1280

The command line configuration and testing interface is now available again on older 1280 based APM1 boards. This had been previously disabled due to flash space issues but has been re-enabled due to space savings that resulted from the new AP_Param code. This means the only feature disabled by default on older 1280 based boards for this release is the on-board dataflash logging.

Thanks to all the contributors!

Many thanks to everyone who has contributed to this release! This release encompasses over 700 patches to our git repository from 25 developers. I hope everyone enjoys flying it as much as the dev team enjoyed developing it!


Views: 2321

▶ Reply to This

Replies to This Discussion

Permalink Reply by Rana on April 25, 2012 at 12:46pm 
There seems a serous bug in Arduplane 2.33. 
Please see the video; http://www.youtube.com/watch?feature=player_detailpage&v=2U8rvR...  
See that I changed the mode to Stabilized, then flew the plane slightly away then switched the mode to Auto, and see the model crashed.  
APM Dev. team, this is for your analysis. 
Regards
Rana

3D RoboticsPermalink Reply by Chris Anderson on April 26, 2012 at 10:34pm

Rana: I can't read your whole comment because you seem to have pasted it from some other format, but we're not seeing any issues (with many hundreds of hours of flight time). Do you have a log? It's not possible to analyze a video of a flight sim.


3D RoboticsPermalink Reply by Chris Anderson on April 27, 2012 at 7:18pm

Rana, we ran a full set of tests today and cannot see any issues whatsoever. I think any problem you encountered may be due to choosing some sort of sailplane as your flight sim aircraft, perhaps without the needed changes to settings. On the standard PT60 everything is working fine in Xplane.

Permalink Reply by Rana on April 28, 2012 at 12:55pm

Chris, its strange, during my few more subsequent simulations, it behaved properly in same simulator, same model.

I have the log, but it contains the log of other flights data, I do not have the tool to edit and cut the portion, so attaching the whole file.

Keep the slider at 19% of the log while playing in the Mission Planner 1.175

During my actual test of Arduplane 2.30, my model crashed exactly in similar way.

Regards

Rana

Permalink Reply by Rana on April 28, 2012 at 5:46pm

Sorry, forgotten to attach log fine.

Regards

Rana

Attachments:

DeveloperPermalink Reply by Andrew Tridgell on April 29, 2012 at 8:33pm

Hi Rana,

That log file seems to be corrupt, or at least I get garbage in mavgraph. Are you sure you can load/play that log?

Also, when describing a problem, please give enough detail so we know what to look for. For example, exactly what happens to navigation controls, control surfaces, altitude etc and what you think it did differently than what you expected.

Analysing a log properly takes several hours, but it is much easier if the user tells us exactly what to look for.

Cheers, Tridge


DeveloperPermalink Reply by Andrew Tridgell on April 29, 2012 at 8:58pm

Rana,

I've managed to extract the data from the log, but I still don't know exactly what I'm looking for. You said to look at 19%, but at 19% the plane is in STABILIZE mode, not AUTO. Is that where you saw the crash? The log enters AUTO at 21%, maybe that is the part of the flight you mean?

The waypoints are also very high - did you intend to fly at 2000m?

Cheers, Tridge

Permalink Reply by Rana on April 30, 2012 at 11:43am

Hi !

I could somehow cut out portion of the log in which I observed bug in the functionality of Arduplane firmware 2.33.

Same is attached, you can play the log in the latest Mission Planner 1.1.77

The abnormal functionality can be very well observed.

Regards

Rana

Attachments:
Permalink Reply by Rana on May 1, 2012 at 7:24pm

Hi !

Here is small recorded video of the same.

 

See that I changed the mode from Auto to Satbilize and flew the plane bit away then I changed the mode to Auto, see the model crashed.

Regards

 

Rana


DeveloperPermalink Reply by Andrew Tridgell on May 1, 2012 at 11:57pm

Hi Rana,

That log really makes no sense at all. For example, the VFR_HUD.alt changes rapidly between 0 meters and 160 meters continuously. That has got to me something wrong with the simulation environment you are using.

Similarly the heading oscillates between 0 and 69 degrees.

It looks like whatever simulation system you are using is giving rubbish values to APM, then occasionally giving good values. Here is an example of the data in your log:

2012-04-25 11:05:54.98: VFR_HUD {airspeed : 19.7466850281, groundspeed : 0.0, heading : 0, throttle : 0, alt : 0.0, climb : 0.0}
2012-04-25 11:05:55.06: VFR_HUD {airspeed : 19.7209300995, groundspeed : 0.0, heading : 0, throttle : 0, alt : 0.0, climb : 0.0}
2012-04-25 11:05:55.06: VFR_HUD {airspeed : 19.7399997711, groundspeed : 19.3899993896, heading : 69, throttle : 0, alt : 161.210006714, climb : 0.0}
2012-04-25 11:05:55.10: VFR_HUD {airspeed : 19.661687851, groundspeed : 0.0, heading : 0, throttle : 0, alt : 0.0, climb : 0.0}
2012-04-25 11:05:55.17: VFR_HUD {airspeed : 19.5906238556, groundspeed : 0.0, heading : 0, throttle : 0, alt : 0.0, climb : 0.0}
2012-04-25 11:05:55.21: VFR_HUD {airspeed : 19.5055732727, groundspeed : 0.0, heading : 0, throttle : 0, alt : 0.0, climb : 0.0}
2012-04-25 11:05:55.26: VFR_HUD {airspeed : 19.4086551666, groundspeed : 0.0, heading : 0, throttle : 0, alt : 0.0, climb : 0.0}
2012-04-25 11:05:55.30: VFR_HUD {airspeed : 19.3047180176, groundspeed : 0.0, heading : 0, throttle : 0, alt : 0.0, climb : 0.0}
2012-04-25 11:05:55.34: VFR_HUD {airspeed : 19.3999996185, groundspeed : 19.3999996185, heading : 69, throttle : 0, alt : 162.039993286, climb : 0.0}
2012-04-25 11:05:55.35: VFR_HUD {airspeed : 19.2039108276, groundspeed : 0.0, heading : 0, throttle : 0, alt : 0.0, climb : 0.0}
2012-04-25 11:05:55.39: VFR_HUD {airspeed : 19.122800827, groundspeed : 0.0, heading : 0, throttle : 0, alt : 0.0, climb : 0.0}
2012-04-25 11:05:55.44: VFR_HUD {airspeed : 19.0631637573, groundspeed : 0.0, heading : 0, throttle : 0, alt : 0.0, climb : 0.0}
2012-04-25 11:05:55.48: VFR_HUD {airspeed : 19.0087299347, groundspeed : 0.0, heading : 0, throttle : 0, alt : 0.0, climb : 0.0}
2012-04-25 11:05:55.53: VFR_HUD {airspeed : 18.9674320221, groundspeed : 0.0, heading : 0, throttle : 0, alt : 0.0, climb : 0.0}
2012-04-25 11:05:55.57: VFR_HUD {airspeed : 18.9299240112, groundspeed : 0.0, heading : 0, throttle : 0, alt : 0.0, climb : 0.0}
2012-04-25 11:05:55.62: VFR_HUD {airspeed : 18.8961048126, groundspeed : 0.0, heading : 0, throttle : 0, alt : 0.0, climb : 0.0}
2012-04-25 11:05:55.65: VFR_HUD {airspeed : 18.9200000763, groundspeed : 19.3199996948, heading : 68, throttle : 0, alt : 162.720001221, climb : 0.0}
2012-04-25 11:05:55.66: VFR_HUD {airspeed : 18.8661518097, groundspeed : 0.0, heading : 0, throttle : 0, alt : 0.0, climb : 0.0}
2012-04-25 11:05:55.71: VFR_HUD {airspeed : 18.8394527435, groundspeed : 0.0, heading : 0, throttle : 0, alt : 0.0, climb : 0.0}

Permalink Reply by Rana on May 2, 2012 at 8:37am

Hi Tridgell !

I am using AeroSIM-RC ver3.91, most of the people here are using this.

Plugin used is the standard APMHil.

I am not not escalating this, just because of one time observation but I encountered this many times at different occasions.

In a real test flight with Arduplane 2.30, I lost my plane in exactly the same crash as is shown in this very simulation video.

What you suggest further ?

Regards

Rana

Permalink Reply by Gábor Zoltán on May 2, 2012 at 10:23am
Could this be the same thing?
http://gabek.dyndns.org:28/ardu/Error.wmv

RSS

Social Networking

Top Content 

1 ArduPlane 2.73 released

ArduPlane 2.73 released
2 How to analyze a crash?

How to analyze a crash?
3 ArduVTOL

ArduVTOL
4 NEVER connect a Capacitor backup or voltage protector on APM board

NEVER connect a Capacitor backup or voltage protector on APM board
5 HD video for UAV's

HD video for UAV's
6 APM Copter 2.9.1.b has been released

APM Copter 2.9.1.b has been released
7 DIYDrones Chat Feature Info

DIYDrones Chat Feature Info
8 Arducopter Question

Arducopter Question
9 Arducopter 3Dr or Phantom

Arducopter 3Dr or Phantom
10 ArduVTOL - Wingcopter - Flight Report Nr.1

ArduVTOL - Wingcopter - Flight Report Nr.1

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