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!
Tags:
Permalink Reply by Tom in ON on March 18, 2012 at 6:13pm Just to clarify, it stops every time after uploading to the APM 2.0 board without errors and starting Mission Planner. When mission Planner connects to APM 2.0 board it stops halfway. Now it stops at: got param RC4_DZ
It times out and can't connect. Get this error message: Time out read - GET PARAMETER List 94-176
I have the latest FTDI drivers and made sure the libraries are all there. I am pretty sure it's not the 2.30 code, as I similarly was not able upload with 2.28, but at least this time Mission Planner actually recognized the board and started loading off of it. Again, if upload with Mission Planner instead of Arduino, all works fine.
I may try a simple code next, just to see if it works with Arduino.

Please try on another PC. If that doesn't work, you've got a hardware issue.
I'm having the same behavior that Tom experienced.
I'm using APM2.0 (the purple one).
If I use Mission Planner to upload the 2.3 firmware in APM I don't have any issue. Using mission planner I can calibrate radios modes pids etc.... I also tested HIL with X-Plane uploading the HIL version (using MP) and all looks good.
The problem is when I download the Zip file source code, I can compile using the arduino-relax.
I can also upload to APM without any errors.
But APM just don't work. I don't get the leds 'flash show' during hardware initialisation when I reboot the APM.... I'm sure I missed something in the setups of Arduino: libraries, sketches location and ArduPlane folder.... My latest setup for version 2.28 was working fine. ... and what do you know? they plublish a new version...2.3 well the problem is probably pretty near the keyboard... I will try again later...
But I do agree with Tom, since uploaded using Mission Planner 2.3 works great I feel ok to use this release on the Bixler almost ready to fly. For sure I will use ArduPlane 2.3 for first real flite.
Thanks Andrew and team!
many many thanks.
Eric
Permalink Reply by Tom in ON on April 1, 2012 at 12:11pm Eric,
Did you manage to fix your Arduino to APM2 uploading problem?
I am suspecting too that there is something wrong with the libraries, even though I am pretty sure I followed the setup guide carefully. I had no issues with APM 1.0 and the FTDI connection.
Hi Tom, no I did not manage to fix Arduino. But since then I upload 2.32 on APM2 (using MP) and I did not try to compile and upload this latest version with Arduino yet. To be honest, I want to fly! and I put aside the subject. I did my first flight this morning with the Bixler. I lost communication with my plane in mid-air... scary! The Bixler Circled around and one tip of the main wing hit the ground. The "cheap plastic rod" broke... I replaced it today with a wood rod... not sure if it will do the job but it looks solid ... I don't know what happened there. I suspect a bad connection with the jumper on APM2... when I arrive near the crash site, the ESC was beeping (no throttle signal) and all leds were off on APM2. I found a better jumper stolen from an old disk drive in my scrap yard and replaced it. ... but I quite scared for test flight #2 ;) I will try again to compile/upload 2.32 this week if I can find the time. Please if you manage to do it, let me know.
Eric
Permalink Reply by Tom in ON on April 1, 2012 at 4:54pm Eric,
Sorry to hear about the crash. Good thing is that you are able to get it up in the air fairly quickly. My APM 2 still has temporary connectors with servo wires, but I can see how some of the servo connections may become lose. Thinking about using some pin headers and sockets and solder them up with wires.
I suspect that the problem with my Ardunio upload are the libraries. Must be missing some libraries, regardless that I followed the guide to the teeth. Let you know if I figure it out.
Permalink Reply by jim C. on March 19, 2012 at 7:16am
Permalink Reply by Daniel Portillo on March 22, 2012 at 1:11pm That's great, the new compass calibration has resolve all my navigation problems, now my maja flies over to the teoric road.
Permalink Reply by Gábor Zoltán on March 26, 2012 at 5:18am My question is; Could the new version case my barometric pressure sensor go crazy?
If it is not. What could?
I already posted it here:
http://www.diydrones.com/forum/topics/unreliable-barometric-altitude

yes, the new version had a nasty barometer bug which Randy has just fixed.
Because of this I've now done a new release, version 2.31. This release also has a much improved compass learning algorithm.
Sorry for the bug!
Cheers, Tridge
Permalink Reply by Tom in ON on April 1, 2012 at 9:22pm OLD:
MP connection stops every time after uploading with Arduino to the APM 2.0 board without errors and starting Mission Planner. When mission Planner connects to APM 2.0 board it stops halfway. Now it stops at: got param RC4_DZ
It times out and can't connect. Get this error message: Time out read - GET PARAMETER List 94-176
I have the latest FTDI drivers and made sure the libraries are all there. I am pretty sure it's not the 2.30 code, as I similarly was not able upload with 2.28, but at least this time Mission Planner actually recognized the board and started loading off of it. Again, if upload with Mission Planner instead of Arduino, all works fine.
Update:
Well...when APM 2 tries to connect to MP and gets stuck halfway, I press the hard reset button on the board and it completes the rest of the loading. However, even it seems connected, nothing works.
I tried to remove any other voltage cables except the USB, also tried it with the battery and USB at same time.
The only thing I do not have set because it does not give me the option is the "set RTS close" under the USB port. I do not have that option under my USB port, may be it was the FTDI USB port option previously.
It's frustrating that I am stuck with the stock code and can't modify. I tried it on another PC using Win XP, same problem with the Arduino environment.
Tom, please switch to V2.32 will take it from there.
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.1297 members
79 members
183 members
690 members
24 members
© 2013 Created by Chris Anderson.
Powered by

load the APM version 2.30 in my 2560, do one test flight and has the absolute heighterrors, sometimes it works well, sometimes not. seems that the navigation alsodeteriorated and the indication of the magnetic compass seems to be crazy. is mypreimera aprecicacion. attached file