The ArduPilot development team is proud to announce the release of the first beta version of the 3.5.0 release of APM:Plane. We think this is going to be a great release and we'd love some feedback before we do the final version.
The biggest changes in this release are:
- switch to new EKF2 kalman filter for attitude and position estimation
- added support for parachutes
- added support for QuadPlanes
- support for 3 new flight boards, the QualComm Flight, the BHAT and the PXFmini
- support for arming on moving platforms
New Kalman Filter
The 3.4 release series was the first where APM:Plane used a Kalman Filter by default for attitude and position estimation. It works very well, but Paul Riseborough has been working hard recently on a new EKF variant which fixes many issues seen with the old estimator. The key improvements are:
- support for separate filters on each IMU for multi-IMU boards (such as the Pixhawk), giving a high degree of redundency
- much better handling of gyro drift estimation, especially on startup
- much faster recovery from attitude estimation errors
After extensive testing of the new EKF code we decided to make it the default for this release. You can still use the old EKF if you want to by setting AHRS_EKF_TYPE to 1, although it is recommended that the new EKF be used for all aircraft.
Parachute Support
This is the first release with support for parachute landings on plane. The configuration and use of a parachute is the same as the existing copter parachute support. See http://copter.ardupilot.com/wiki/parachute/
Note that parachute support is considered experimental in planes.
QuadPlane Support
This release includes support for hybrid plane/multi-rotors called QuadPlanes. More details are available in this blog post: http://diydrones.com/profiles/blogs/quadplane-support-in-apm-plane-3-5-0
Support for 3 new Flight Boards
The porting of ArduPilot to more flight boards continues, with support for 3 new flight boards in this release. They are:
- the BHAT board
- the PXFmini
- the Qualcomm Flight
More information about the list of supported boards is available here: http://dev.ardupilot.com/wiki/supported-autopilot-controller-boards/
Startup on a moving platform
One of the benefits of the new EKF2 estimator is that it allows for rapid estimation of gyro offset without doing a gyro calibration on startup. This makes it possible to startup and arm on a moving platform by setting the INS_GYR_CAL parameter to zero (to disable gyro calibration on boot). This should be a big help when flying off boats.
That is just a taste of all of the improvements in this release. In total the release includes over 1500 patches. Some of the other more significant changes include:
- RPM logging
- new waf build system
- new async accel calibrator
- SITL support for quadplanes
- improved land approach logic
- better rangefinder power control
- ADSB adapter support
- dataflash over mavlink support
- settable main loop rate
- hideable parameters
- improved crash detection logic
- added optional smooth speed weighting for landing
- improved logging for dual-GPS setups
- improvements to multiple RTK GPS drivers
- numerous HAL_Linux improvements
- improved logging of CAM messages
- added support for IMU heaters in HAL_Linux
- support for RCInput over UDP in HAL_Linux
- improved EKF startup checks for GPS accuracy
- added raw IMU logging for all platforms
- added BRD_CAN_ENABLE parameter
- support FlightGear visualisation in SITL
- configurable RGB LED brightness
Many thanks to everyone who contributed to this release! The development team is growing at a fast pace, with 57 people contributing changes over this release cycle.
I'd like to make special mention of Tom Pittenger and Michael du Breuil who have been doing extensive testing of the plane development code, and also contributing a great deal of their own improvements. Thanks!
Comments
Andrew,
I was wondering if there has been any thought on add the ability of typing in the Altimeter setting (29.92 in/Hg) for high altitude flights?
THanks
Joe
Hi All,
Here are my results for the 3.5 beta 1 from the Australia Day weekend.
https://www.youtube.com/watch?v=ZzBA5NbzeBY
Everything was going really well until I put it into a clockwise loiter turn, expecting anti-clockwise. The real problem began when I flicked passed FBWA back to manual. I have a lot of difficulty transitioning from FBW back to Manual because the aircraft is so aggressive, without APM. I will review my switch programming.
In time the ambition and the ability will converge !
On the code side I was seeing short drop outs on the airspeed sensor logs, you can just see them in the video.
The log times seem to be diverged by about a minute for some of the streams. (Airspeed/Pitch)
The M8N GPS unit didn't receive any physical damage and it was still on it's mounts but it is toast. I can't get any comms with it but it does seem to have dumped it's diagnostics into uncenter. Will follow up with Ublox
Compass seemed to be OK, I can't to get it to run properly with just one on the wing. It want's the onboard compass in the loop as well. Onboard is sitting ontop of the power module, right behind the 586Watts of takeoff power. I really want the onboard out of the loop for ground steer/auto takeoff.
Two more airframes and another M8N on the way, I did have a spare Sbach without APM and I have had a sensational 3 days of flying.
Thankyou to all the contributors on this amazing journey.
Paul
Hi Andrew,
I've considered you a national treasure since 2000 when I first became aware of your work with rsync and samba.
I was given an APM Mini 3.1 in December to put on a quad. I prefer fixed wing and started integrating APM into my 800mm Sbach. When I started delving into the APM Plane code it's got your name all over it and I can see you are very passionate about it :)
I have spent most of January coming upto speed on APM, my passion bordering on obsession, with no real consultancy work being completed as yet. I'm now onto a Pixfalcon with Digital airspeed, which I have just loaded 3.5.0 Beta1 code.
I was getting some really strange compass errors before this, these appear to have been around for a while.
I detailed my findings here on the last post
http://ardupilot.com/forum/viewtopic.php?f=113&t=13847&e=0
These appears relevant as well.
https://github.com/diydrones/ardupilot/issues/1355
http://ardupilot.com/forum/viewtopic.php?f=110&t=12581&p=40...
My comment is, the EKF filters are sensational and the work that is being done is ground breaking. My concern is that it may mask faulty input hardware/signals.
Where I am struggling is understanding where to get data displayed from the sensors raw for setup, debug and identifying faulty sensors used in redundancy. In particular with multiple compass streams and GPS streams now available. I'd also make a request/comment for the 3 axis compass calibration twirly bird in MP going into APM Planner 2.0.
For now I'm set for Sunday and I'll be trying the auto takeoff on the bush track where we fly. Enjoying the efforts of the community it's really is amazing what has been achieved.
Well done!
Regards Paul
Thank you for the wonderful work.
I have some questions about the Flightmods and navigation,
How do I get the Flightmods
17: QSTABILIZE,18: QHOVER,19: QLOITER
activated or where they must be inserted, a screenshot would help.
the next problem
how do I get the commands inserted
DO_VTOL_TRANSITION,NAV_VTOL_TAKEOFF,NAV_VTOL_LAND
a small guide with Screeshot would be helpful
or a binary file.
best regards
Rainer
Tridge,
Sorry this took so long,
Here are my thoughts. There should be a place on the flight data screen of Mission Planner where the operator can input the current Altimeter setting (i.e. 29.93 in Hg) so that the Pixhawk will adjust the altitude to the current pressure setting. This will insure that the UA is flying at the same altitude as the rest of the air traffic in the area. It is not recommended to us an online system to update this due to other traffic in the area may not have access to it and is using settings provided by air traffic control.
I hope this makes since and that it can be implemented.
Let me know if you have any questions or need any clarification.
Thanks
Joe
@andrew,
I will put together a quick outline today. i think having the operator enter the Barometric pressure on the main flight data page would be best so that as air traffic control provides us with new altimeter settings we can update it.
thanks
joe
@Joe, it could be added in GCS implementations now, with options for how the QNH or QFE gets into the system.
What mechanism for getting QNH into MissionPlanner do you want? You could either automate it by using QNH off an internet service (presumably over http) or the operator could enter it periodically, and the GCS could smooth it by applying the change in steps.
It would be useful if you could outline what the ideal system would be. Do you want mission items to have altitude as AMSL based on QNH? Or do you want a different frame type, so some mission items are relative to QNH and some are relative to the planes startup pressure?
@Andrew,
Thanks for the information, this is helpful but like you said not ideal. When do you think we can have something like this available in Mission Planner and APMplane. I think this could be a great addition to the system considering how many people are using PixHawk for High Altitude Long endurance systems that need to play nice in the NAS.
Thanks
Joe
@UAS_Pilot, ok for that you can use three existing methods. They aren't ideal, but perhaps they will be sufficient.
There are two parameters that control the interpretation of the barometric pressure. They are:
GND_ABS_PRESS (in pascals) and GND_ALT_OFFSET (in meters).
To adjust the baro baseline in flight you could either change GND_ABS_PRESS, or change GND_ALT_OFFSET. I'd recommend you change them in small steps, no more than 0.5 meters at a time. You can update them as often as you like.
The third approach is to use a high accuracy GPS (such as an RTK GPS) and set EK2_ALT_SOURCE=2 to use GPS as primary altitude. That of course doesn't work if other aircraft in the airspace are using QNH.
We should really have a mavlink message for setting the QNH. The closest to that right now would be to set GND_ABS_PRESS to the QNH after the board boots, and then make all your missions use altitudes AMSL. If you use the MAVLink param_set message to send updates to GND_ABS_PRESS regularly, making sure you use only small steps, then I think it would achieve what you want. Not an ideal procedure I know, but should work.
The reason for the small step sizes is you don't want the EKF to see a sudden step in the pressure. Keeping the changes to below 0.5m altitude change equivalent would keep the EKF happy. Larger changes will work, but the EKF will be unhappy for a few seconds.
The same procedure could of course be used with QFE instead of QNH if that is the type of airspace you are in. Then your missions could be done as altitude above the local airport.
N we are not looking to ceate a fail safe, but a way to adjust during flight to adapt for changes in pressure in the indicated altitude.
We have a UAS that is planed for operation @ 60,000FT MSL and fly for 10 days plus, and we are required by FAA to have the ability to enter the standard pressure setting while flight in Class A airspace so that we are indicating and flying at the same altitude reference that other aircraft are flying. Did I explain this well?
Oh, and Before anyone starts warning about rules and regulations, we are operating within a Certificate of Authorization (COA) as a public aircraft performing research.
D
-
1
-
2
-
3
of 3 Next