Thread Tools
Feb 24, 2016, 07:27 PM
Thread OP

Ardupilot Arducopter APM Pixhawk News

Please just post news here and discuss elsewhere.

From Randy Mackay

"Hi there. I'm one of the main developers of ArduPilot and although it's probably been said a few times in the replies above (sorry, I haven't read them all), Ardupilot is still alive and moving forward. The project hit a major road bump with 3DR reducing its support but that's not going to kill the project. 3DR continues to support a couple of the developers and other companies have also stepped in over the past year. Intel has well over 10 developers devoted to DroneCode projects including at least 2 working on Ardupilot full time and a few others improving QGroundControl to work better with Ardupilot. Parrot has 1 or 2 developers and there are two smaller companies that have devoted 1 developer each as well. We also continue to have code contributions from independent developers.
I'm not saying it's all happy days, 3DR has been our major supporter for years but ArduPilot does not rely on 3DR for it's survival. We want ArduPilot to be widely adopted and developed by lots of individuals and companies . This is healthier than being dominated by a single player."
Sign up now
to remove ads between posts
Feb 24, 2016, 07:29 PM
Thread OP
From Leonard Hall:

"Like Randy, I am one of the main developers of the Arducopter code. I started working on Arducopter code back around the 2.7 release. Since then I have become the main developer responsible for the control code in Arducopter. Over the last year or so I have been funded by 3dr to help bring the Solo to market and to ensure my continued development of the control code that they have relied upon for so many years.

Now that 3dr have stopped my financial support I have more time to focus on aspects of the code that benefit the wider community, both commercial and hobbyist. I personally have a number of projects on my list of things to do:
- Randy and I are currently finishing on a rewrite of the motor mixing library to make it easier to incorporate a wider variety of control structures. This will in turn make it easier for different control architectures to be implemented by hobbyists, academics, or industry.
- I am now focused on finishing converting our attitude controllers to quertonion based maths. This will provide some slight improvements to our inverted recovery and also facilitate some forms of multirotor-plane hybrids.
- I have a design for some improved battery handling that will enhance the lifetime of batteries in our multirotors. This enhancement will be particularly relevant to long endurance multi rotors using low C batteries or high performance multi rotors that are currently pushing battery technology to the limit.
- I will add alt-hold to autotune. This will then make Arducopter the first autopilot I am aware of that is capable of tuning all it's controlers itself.
- I also have a plan to include a physical characterisation mode to autotune. This will make it easy for people with advanced control experience to create off line models of a multirotor to do off line tuning or advanced controller design. This will help those copters with secondary oscillations of large gimbals or flexible frames.
- Randy and I have tested an improvement to Alt-Hold that will make it impossible for people to loose height in Alt-Hold even at large lean angles. I want to extend this to improve Auto modes.
- I want to enhance follow me mode to take position, velocity, and acceleration values from the ground station. This will improve the performance of follow me for slow update rates and significantly improve how smoothly the copter moves around.
- I have the collision avoidance equations ready for some basic collision avoidance implementation. Initially I want to implement simple collision avoidance for the fence.
- We would like to bring the arbitrary geo-fence from plane over to copter.

In the longer term I would like to solve the S-curve equations for 3 dimensions (or find the solution that someone else has already done). This would help us improve our auto missions, especially tight splines at high speed.

There are also a number of the camera modes that 3dr have implemented using an external processor that would be better done on the autopilot. I am considering implementing them using our mission waypoints. For example, This would potentially let the pilot move forward and backwards along any path that can be set using the current waypoint system.

I am also very interested to hear from the community what advanced control features we should be considering.

So I personally am looking forward to having more time to focus on my own priorities within Arducopter now that 3dr isn't burning up my time in other areas.

I would also like to personally thank everybody that has supported Arducopter over the years!! "
Feb 24, 2016, 07:30 PM
Thread OP
Btw, for those of us interested in what's coming up and not following drones-discuss on google groups, the latest mail from Craig Elder about the latest dev call has a nice summary of some of the discussions/work items/expected features for the next 3.4 release (copter):

"Copter 3.4

Terrain following
Precision land
Motors refactoring makes adding support much more simple.
Discussion on rationalising the different altitude methods…
Getting plane and copter to report altitude the same…
knowing what type of altitude is being used.
Companion computer progress
Rasp pi scripts and image… etc….
Including red balloon finder etc…
Red balloon finder needs to be brought up to date.
TX1 and Odroid to come….
OpenCV 3 " ...
Feb 25, 2016, 09:28 AM
Thread OP

Arducopter 3.3.3 released

from Randy Mackay:

"We’ve release Copter-3.3.3 today. It just has a few minor improvements over 3.3.2. As always these can be seen in the Release Notes and below.

1) bug fix to Guided mode's velocity controller to run at 400hz

2) bug fix to MAVLink routing to allow camera messages to reach MAVLink enabled cameras and gimbals (including SToRM32)

3) Restrict mode changes in helicopter when rotor is not at speed

4) add ATC_ANGLE_BOOST param to allow disabling angle boost for all flight modes

5) add LightWare I2C range finder support

Separately it looks like the Pixracer issues are mostly resolved and we plan to push out a special Copter-3.3.4-pixracer tomorrow.

Feb 25, 2016, 11:47 AM
Thread OP

Arducopter-3.3.4-pixracer has been officially release

from Randy Mackay:

"Copter-3.3.4-pixracer has been officially released for all multicopters. This release resolves the teething problems we’ve seen with this new board. Changes are (ReleaseNotes):

1) fix parameter save issue caused by bus locking

a. the px4firmware ms5611 driver doesn’t make use of the same interrupt handling as other drivers meaning a special work around had to be put in place to turn them off when we’re accessing the eeprom (which is on the same SPI bus).

2) fix SBUS input

a. caused by #define name change in PX4 stack that we missed when we rebased on their branch

3) Resolve “bad gyro health” messages preventing arming by ignoring accel and gyro errors during first 2 seconds after start-up

a. These are real errors reported by the drivers shortly after start-up. This same issue happens with the Solo apparently so we applied the same fix.

Here’s the main support thread on DIYDrones:"
Feb 25, 2016, 02:46 PM
Registered User

Results from the Pixhawk Pro Survey
Feb 25, 2016, 02:49 PM
Registered User

What to ask in a software / flight control survey?
Feb 27, 2016, 08:24 AM
Thread OP

A new chapter in ArduPilot development

Posted by Andrew Tridgell on February 26, 2016 at 11:34pm
View Blog

The ArduPilot core development team is starting on a new phase in the project's development. We’ve been having a lot of discussions lately about how to become better organised and better meet the needs of both our great user community and the increasing number of organisations using ArduPilot professionally. The dev team is passionate about making the best autopilot software we can and we are putting the structures in place to make that happen.

Those of you who have been following the developments over the years know that ArduPilot has enjoyed a very close relationship with 3DRobotics for a long time, including a lot of direct funding of ArduPilot developers by 3DR. As 3DR changes its focus that relationship has changed, and the relationship now is not one of financial support for developers but instead 3DR will be one of many companies contributing to open source development both in ArduPilot and the wider DroneCode community. The reduction in direct funding by 3DR is not really too surprising as the level of financial support in the past was quite unusual by open source project standards.

Meanwhile the number of other individuals and companies directly supporting ArduPilot development has been increasing a lot recently, with over 130 separate people contributing to the code in the last year alone, and the range of companies making autopilot hardware and airframes aimed at ArduPilot users has also grown enormously.

We’re really delighted with how the developer community is working together, and we’re very confident that ArduPilot has a very bright future

Creation of ArduPilot non-profit

The ArduPilot dev team is creating a non-profit entity to act as a focal point for ArduPilot development. It will take a while to get this setup, but the aim is to have a governance body that aims to guide the direction the project takes and ensure the project meets the needs of the very diverse user community. Once the organisation is in place we will make another announcement, but you can expect it to be modelled on the many successful open source non-profits that exist across the free software community.

The non-profit organisation will oversee the management of the documentation, the auto-build and test servers and will help set priorities for future development.

We’re working with 3DR now to organise the transfer of the domain to the development team leads, and will transfer it to the non-profit once that is established. The dev team has always led the administration of that site, so this is mostly a formality, but we are also planning on a re-work of the documentation to create an improved experience for the community and to make it easier to maintain.
Expansion of ArduPilot consulting businesses

In addition to the non-profit, we think there is a need for more consulting services around ArduPilot and DroneCode. We’ve recognised this need for a while as the developers have often received requests for commercial support and consulting services. That is why we created this commercial support list on the website last year:

It is time to take that to the next level by promoting a wider range of consulting services for ArduPilot. As part of that a group of the ArduPilot developers are in the process of creating a company that will provide a broad range of consulting services around ArduPilot. You will see some more announcements about this soon and we think this will really help ArduPIlot expand into places that are hard to get to now. We are delighted at this development, and hope these companies listed on the website will provide a vibrant commercial support ecosystem for the benefit of the entire ArduPilot community.

Best of both worlds

We think that having a non-profit to steer the project while having consulting businesses to support those who need commercial support provides the best of both worlds. The non-profit ArduPilot project and the consulting businesses will be separate entities, but the close personal and professional relationships that have built up in the family of ArduPilot developers will help both to support each other.

Note that ArduPilot is committed to open source and free software principles, and there will be no reduction in features or attempt to limit the open source project. ArduPilot is free and always will be. We care just as much about the hobbyist users as we do about supporting commercial use. We just want to make a great autopilot while providing good service to all users, whether commercial or hobbyist.
Thank you!

We’d also like to say a huge thank you to all the ArduPilot users and developers that have allowed ArduPilot to develop so much in recent years. We’ve come a very long way and we’re really proud of what we have built.

Finally we’d also like to thank all the hardware makers that support ArduPilot. The huge range of hardware available to our users from so many companies is fantastic, and we want to make it easier for our users to find the right hardware for their needs. We will continue working to improve the documentation to make that easier.

Happy flying!

The ArduPilot Dev Team
Mar 10, 2016, 02:39 AM
Thread OP

Virtual Robotix working on collision avoidance for Ardupilot

Roberto Navoni
Mar 5!

"Hi Randy,
we are working a new class implementation for support the anti collision on Ardupilot , actually we implemented a code that use ROS class for recive lidar information from AP_Collision Class and use it for limit the Pitch and Roll on drone.
The idea is to limit des_roll and des_pitch variable with a factor that depend of distance to the target when you are far no limit when you are near the movment on pitch and roll have limit.
Actually der_roll and des_pitch is not in the telemetry but only in sd log.
@Randy do you think that this could be good approach ? Do you think that in telemetry this value is available ? We don't found...
To AP_Collision we send 4 parameter front / rear / left /right factor.
Roberto "

VR Brain 5 + VR Neuron + Lidar + SLAM and Anti Collsion System (2 min 6 sec)
Mar 14, 2016, 09:18 AM
Thread OP

Antenna Tracker 0.7.6 released

from Randy Mackay
"We’ve released 0.7.6 of the antenna tracker with a couple of minor fixes to logging.

There was a mismatch between the scale of the logging of desired pitch and yaw. Also the “mode” wasn’t being logged.

Very minor update but thought I’d email the group about it in any case.

Mar 21, 2016, 07:46 AM
Thread OP

Arduplane version 3.5.1 Released

Release 3.5.1, 21st March 2016

The ArduPilot development team is proud to announce the release of
version 3.5.1 of APM:Plane. This is a minor release with primarily
small changes.

The changes in this release are:

- update uavcan to new protocol
- always exit loiter in AUTO towards next waypoint
- support more multicopter types in quadplane
- added support for reverse thrust landings
- added LAND_THR_SLEW parameter
- added LAND_THEN_NEUTRL parameter
- fixed reporting of armed state with safety switch
- added optional arming check for minimum voltage
- support motor test for quadplanes
- added QLAND flight mode (quadplane land mode)
- added TECS_LAND_SRC (land sink rate change)
- use throttle slew in quadplane transition
- added PID tuning for quadplane
- improved text message queueing to ground stations
- added LAND_THR_SLEW parameter
- re-organisation of HAL_Linux bus API
- improved NMEA parsing in GPS driver
- changed TECS_LAND_SPDWGT default to -1
- improved autoconfig of uBlox GPS driver
- support a wider range of Lightware serial Lidars
- improved non-GPS performance of EKF2
- allow for indoor flight of quadplanes
- improved compass fusion in EKF2
- improved support for Pixracer board
- improved NavIO2 support
- added BATT_WATT_MAX parameter

The reverse thrust landing is particulary exciting as that adds a
whole new range of possibilities for landing in restricted areas. Many
thanks to Tom for the great work on getting this done.

The uavcan change to the new protocol has been a long time coming, and
I'd like to thank Holger for both his great work on this and his
patience given how long it has taken to be in a release. This adds
support for automatic canbus node assignment which makes setup much
easier, and also supports the latest versions of the Zubax canbus GPS.

My apologies if your favourite feature didn't make it into this
release! There are a lot more changes pending but we needed to call a
halt for the release eventually. This release has had a lot of flight
testing and I'm confident it will be a great release.

Happy flying!
Mar 23, 2016, 08:57 AM
Thread OP

New website

from Andrew Tridgell

"Hi All,

Thanks to some fantastic work by Hamish the new sphinx based
documentation system is now live on We will probably move to point at the same site soon. We have already disabled
editing on the old site.

There are still a few bits left to fix, but the new structure does look
very good. It is no longer wordpress based, instead it is a site
generated from rst files in github:

we have migrated all doc issues to that new repo, and we will do
documentation updates via github in future, accepting PRs like we do for

We are hoping that moving to a git based workflow will make updating the
docs easier.

Thanks also to Peter, Buzz and Jani for all their work on the new
servers and scripts for building the new site!

Cheers, Tridge "
Mar 27, 2016, 05:22 PM
Registered User

News about new discussion Forum Online

" The ArduPilot groups and support forums have been combined and are now located at

- The old support forums are archived at

- The wiki is located at"
Mar 27, 2016, 10:08 PM
Thread OP
from Andrew Tridgel
"The ArduPilot development team is proud to announce the release of version 3.5.2 of APM:Plane. This is a minor release with small changes.

The main reason for this release over the recent 3.5.1 release is a fix for a bug where the px4io co-processor on a Pixhawk can run out of memory while booting. This causes the board to be unresponsive on boot. It only happens if you have a more complex servo setup and is caused by too much memory used by the IO failsafe mixer.

The second motivation for this release is to fix an issue where during a geofence altitude failsafe that happens at low speed an aircraft may dive much further than it should to gain speed. This only happened if the thrust line of the aircraft combined with low pitch integrator gain led to the aircraft not compensating sufficiently with elevator at full throttle in a TECS underspeed state. To fix this two changes have been made:

a minimum level of integrator in the pitch controller has been added. This level has a sufficiently small time constant to avoid the problem with the TECS controller in an underspeed state.
the underspeed state in TECS has been modified so that underspeed can end before the full target altitude has been reached, as long as the airspeed has risen sufficiently past the minimum airspeed for a sufficient period of time (by 15% above minimum airspeed for 3 seconds).

Many thanks to Marc Merlin for reporting this bug!

The default P gains for both roll and pitch have also been raised from 0.4 to 0.6. This is to help for users that fly with the default parameters. A value of 0.6 is safe for all aircraft that I have analysed logs for.

The default gains and filter frequencies of the QuadPlane code have also been adjusted to better reflect the types of aircraft users have been building.

Other changes include:

improved QuadPlane logging for better analysis and tuning (adding RATE and QTUN messages)
fixed a bug introduced in 3.5.1 in rangefinder landing
added TECS logging of speed_weight and flags
improvements to the lsm303d driver for Linux
improvements to the waf build system

Happy flying!"

Quick Reply

Thread Tools