There is a preview on GIT right now. I flew a version of this


The PWM output has been set to 400hz (to counter the low pass filter in most Turnigy PWMs)

The DCM's Roll and Pitch gains were lowered to .03 (recommendation of Hein Hollander)

Mavlink has gotten a re-work for performance and memory savings.


Added a scaling factor to camera Roll And Pitch CAM_P_G, CAM_R_G in the params list.

Fixed some bad PID values for Alt hold that were giving folks trouble.

Exiting a WP for another is faster and more controlled now.

Added user hooks for those who want to execute their own code inline.

Increased loiter speed to center when the copter is flown > 400cm (now 800cm).


Loiter in action.


Views: 31761

Reply to This

Replies to This Discussion

The altitude hold rise would be disconcerting for sure.  I tried it for the first time on my fifth flight and it took full up deflection on the stick, but it did go up a few meters before I went back to neutral.

I'm having a little trouble with simple mode in alt-hold.  My setting in the Mission Planner didn't seem to stick. I'll need to debug that one. 

I hope the fly tomorrow a little bit more if the weather permits.

I switched from 2.0.45 to 2.0.49 today and managed to get two flights in towards the end of the day in calm conditions.  I tried ALT Hold on both flights and the quad is jumping i.e motors are pulsing again.  It is quite pronounced now on 2.0.49 than it was when I tried the same hardware setup on 2.0.45 i.e it was very intermittent.   Now if I had not spent the last three weeks focusing on the sonar I would be looking at the usual suspects but now I see the familiar  throttle oscillation but more intense.  My Sonar is mounted well clear of the electronics( ~ 4"), has a power filter and good shielded cabling.  The worst part of the ALT Hold behavior is the unexpected climbing.  I was very lucky to catch the quad because before I could blink it was (according to the flight log) some 133ft from the ground. I tried engaging ALT hold a few times and it just keeps trying to climb.  I thought it might stop once the baro kicks in but this is how I manged to almost loose my quad when is climbed at the highest rate.


I tried Loiter mode next and the quad is not able to stay on point.  The GPS is locked solid the  whole flight so I am not sure why the quad seems to eventually fly away from me requiring manual intervention to bring it back.  Pehaps to standard Loiter radius is very large in the default code settings,  Do we have to change a value to make sure Loiter keeps the quad in a tight radius?


I really am so close to giving up on this project as I cannot seem to get anywhere near what other people are reporting, especially on 2.0.49.   So far I have changed 6 motors to get a really low vibration free frame, replaced 2 sets for prop spinners again for balance reasons. On the electronics side I have replaced one ESC and the IMU Shield and the APM. All to remove possible sources of interference or faults.


Is there a way I can temporarily go back to the 2.0.45 code using the mission planner or will it only load the current linked code? I want to try the exact setup to see if I have the same issues due to some new electronic problem rather than the software.


My arducopter is a standard build (complete kit) except I am using the store offered 880KV motors with 12 x 4.5 props.The only parameters I changed on 2.0.49 is reducing the Stab Roll and Pitch P to 3.2 and increasing I to 0.01 respectively. One last check is the Maxbotics XL-Sonar EZ0 (MB1200) the correct sonar?


After checking in the logs, it seems that alt_hold did switch to stabilize without my intervention.


This explain the fast rise : in alt_hold, a full throttle stick input translate to slow rise, but in manual mode this translate to a fast ascension.


It's quite strange. I can't believe it was a radio problem, as i have RTL as failsafe mode and 2.4 Ghz radios would not have done this mode change because of digital error correction.




If you want to go back to 2.0.45 you'll need to use Arduino IDE.


I did had this fast climp problem with 2.0.49 and i think that the APM did switch wrongly to manual mode alone, as reported in the logs. Could you check your logs to see if you have a mode change just before fast climbing ? (you can see this more easily loading the KML file inside Google Earth and watching the paths).


To stop the fast climbing, i needed to switch back to stabilize, and it did stop the ascension.


I have the Alt_hold pulsing as well, but i think that it is more a PID setting problem. I modified alt_hold PID parameters and will try again today.


Loiter mode is ok for me, with about 10 km/h wind.


Auto mode for me is quite good, but not perfect : the wind corrections are really too slow, but it does work. The only thing strange is that at the end of the mission, it did not stay on the last waypoint. I'm not sure if we need a loiter command at the end to get it stay at the last point.




Hi Greg

I notice your in Australia, being upside down have you reversed your ALT HOLD ?....... Seriously, my tricopter motors pulse when in sonar hold. I have larger motors with more torque, and I had to reduce  my ALT HOLD P value to 40% of the default to get it working well. Your motors are larger, maybe you need to reduce your value. 

I hav'nt tried 2.0.49 yet, it's too windy here.


Do you have logs from your flight with the rapid climb - can you upload them here?

I too had one of these zoom climb events a few versions back - it took of like a rocket while in Alt hold or Loiter- scared the crap out of me. Took a while before I was comfortable with flying the thing again. Stick with it.

I f you really want you can get old versions of the code from here: 

You will have to upload these with Arduino software.



Had a good couple of flights with 2.0.49 today. Just tested Stabilise, Alt Hold and Loiter. Great results

Loiter was a tiny bit disappointing - in that in Alt Hold with only a slight breeze the aircraft would stay fairly steady in the one place. When I switch to Loiter the aircraft starts to fly around a 3-4 metre radius circle after a few seconds. Nudging the controls stops the circle for a short time then it starts circling again. It's the comparison between Alt Hold (steady in the one spot with little or no input) and Loiter (3-4metre circles) that is disappointing. All standard PI values no tuning.

Attached is the log and relevant graph from the Mission Planner


Charlie  yes I am in Australia we fly upside down here :-)  That is a good tip. Also my frame is not carrying any payload at the moment so I will play with the ALT HOLD P and try reducing it.  I am curious if the unexpected reappearance of more noise on the sonar is related to the note from Jason saying the PWM output has been set to 400hz in 2.0.49.

Thank you for the help on suggesting how to get the old code back.  I had another look at the logs and there is an unexpected return to Stablize from ALT Hold.  Yet I know I only manually engaged Stabilze when the Quad shot up unexpectedly.   I am going to try your i2C sonar mod once I get some parts by the way.

Just to clarify: How is a declination of x° yy' entered? Is it x.yy or x + (yy/60) and is there any difference in how Mission Planner interprets it, when compared to entering it in CLI -> setup -> declination?

I seem to remember Mission Planner instructing you to enter the degrees and minutes "as is" as a "decimal" value, but the current procedure doesn't have that old prompt. Also, what is the value "COMPASS_DEC"? It's 0.164235 for me and my declination is 9° 41'. The latter is of course shown separately as "Mag Dec" in CLI -> setup -> show.

i have open a topi with a problem , but i think that i found a bug at the planner in combination with .49

As mentioned in your other thread, you're using a very old version of the Planner. Please upgrade to the latest (1.0.85)

Reply to Discussion


© 2017   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service