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!
Replies to This Discussion
-
Permalink Reply by Itzik Ronen on -
Hi,
In auto mode, after the “takeoff” command is ended (reaching the right altitude), the plane dives few meters and then start to climb heading to WP #2. How do I correct that?
Thanks
Itzik
-
Permalink Reply by Paul Marsh on -
Along with the change in waypoint following that I noted above (plane flies an arc from waypoint-to-waypoint instead of straight line when cross-track correction set to zero degrees), the plane also flies an oval instead of a circle in loiter. I'm seeing this in simulation mode, but I assume this would apply to real mode as well. Also, I'm using an earlier version of Mission Planner in which this was not happening before the firmware upgrade. Was there a change in navigation code that would lead to this flight behavior? Also, I set my loiter radius to a higher value to see if it would make it easier for the plane to fly a circle. It still flies an oval.
Thanks,
Paul
-
Permalink Reply by Paul Marsh on
-
I try not to cross-post, but I'll go ahead and add the graphic here to show what's happening in waypoint following that I noted in this thread. In this scenario, I set cross track correction to 10 degrees. The orange line is always pointing off to the side of the waypoint. The plane now flies the green line. Following the green line with cross track correction would be expected, But I believe the orange line should always point to the center of the waypoint. I don't believe this is a Mission Planner issue, but maybe it is.
I hope this helps if there actually is a navigation bug. If there is a parameter setting I need to change, please point me in that direction.
Thanks,
Paul
-
Permalink Reply by Paul Marsh on
-
I did a real flight today and I experienced the same waypoint following issues in real mode as noted above in sim mode. Namely, from waypoint to waypoint the orange line never pointed to the waypoint center and in loiter mode the plane scribed an oval instead of a circle. It's almost as if the point the plane is flying to becomes a moving target, particularly in loiter mode.
If these issues point to paramater that I need to adjust, any help will be appreciated in pointing me where I need to look.
Thanks,
Paul
-
Permalink Reply by John M. Smith on -
So I have a silly question. Is there anyway to upgrade my two APM 2.0's to the 2.5 versions? Was there hardware changes that must be made to get up to the rev?
-
Permalink Reply by Michael Pursifull on -
Try the 50% upgrade deal; buy two new APM 2.5, then list your APM2.0 on Buy, Sell, Trade for 50% list. This is a DIY community, remember :-)
-
Permalink Reply by Mike Mac on -
The APM 2 and 2.5 are the same except for changes to the circuit board layout. If you want something better wait for the APM 3 that will actually have better hardware. Rumors are that it should be out early next year. If anyone has more details I would like to see them.
.
-
Permalink Reply by Jake Stew on -
Don't hold your breath. Every step on the way to 32-bit has been delayed by YEARS.
The ARM Cortex M3 was released in 2004.
STM32 Cortex M3s came out in 2007.
Atmel came out with a Cortex M3 processor around 2009.
Arduino Due was announced and supposed to be available by the end of 2011.
My bet is that the Due will be ready by early 2013. And a 32-bit APM maybe, just maybe will be out in 2014.
Until then we'll just have to use 8-bit, Arduino based technology from 2005.
Just so you don't get your hopes up make sure you understand that our technology is currently 7 years behind, and we'll be lucky not to fall 9 years behind.
-
Permalink Reply by Jake Stew on
-
Not sure what's going on with that. It's certainly not ready for prime time, they're just now starting to talk about porting ArduPlane over.
It will be an interesting project if they get things going, but pretty hard to follow since I don't think they use English much.
-
Permalink Reply by Rana on -
Jake, You are right in your way of thinking. However Monroe has already reply appropriately.
1st View Point:
I would also say something; DIYDRONES and its commercial business only deals with applications for education and learning purpose. Its a community of 28000 members, many of them are contributing in their free times. Expecting platform & performance as available from commercial leaders is actually not justified.
DIYDRONES is like Sparkfun, they had to evolve based on the popular platforms on which many many people can work and eventually they evolved.
2nd View point:
As far as Multi-Rotor stabilization and navigation is concerned, even 8bit MCU's can perform ultimate and if algorithms not well coded, even ARM processor won't do the job.
Certainly with high-end MCU's, many advance tasks can be done like STM32F407 being used by AQ6 and many others.
-
3D RoboticsPermalink Reply by Chris Anderson on -
Jake, we're already released the STM32 M4-based PX4 boards, and ArduPlane/Copter are being ported to them as we speak.
And, as Monroe points out, ArduCopter is already running on the STM32 M3-based Multipilot 32 boards.
The Due boards may indeed take longer, but we're not waiting on them for ARM performance.
-
Permalink Reply by Jake Stew on
-
That's great news! Looks like a pretty nice board. Can't believe there's been no discussion about this yet.
Couple questions...
There's ST and Invensense sensors onboard?
Why use the BMA180 and a separate mag instead of ST's accel/mag combo? It would be nice to use some of the iNemo code and finally get the AHRS up to speed with a real Kalhman filter.
Is Arduino being ditched altogether?
I'd suggest ditching the POSIX description of the RTOS unless you want to be associated with the 90's. NuttX actually describes its self as "linux work alike" with "implementations of most standard POSIX OS interfaces".
Nice to see some relays on the board.
Social Networking
Top Content
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
-
Documentation Editors
51 members
-
Moderators
24 members
-
Agricultural UAVs
133 members
-
ArduCopter User Group
1298 members
-
Telemetry over cellular …
249 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
