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.
Nice. 2.0.49 is good for me, with the same Loiter performance as you get.
I still have more wobble during decends than with 2.0.45, but perhaps that it is because my PIDs are not yet correctly tuned.
Nevertheless i had a problem with Alt_Hold, where the copter did rise very fast in the sky when i tryed to push the throttle stick up to rise altitude a bit. I needed to switch fastly to manual to stop vertical ascension.
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.
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.
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?
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.
Oliver & Greg,
Approximately what height were you at when you had the fast climb issues?
What model sonar are you using?
I think I may have found a possible reason for this behaviour
I was at 3.86 meters (baro) and 4.80 meters (sonar) when i engaged Alt_hold.
I flew a bit like this, lowering or rising this altitude a few meters with the thottle stick, when suddenly, when i was at about 6-10 meters i think, i got a rocket climbing
This show that there is a Sonar calibration problem here. I did never checked this before, i think you did find one of the reason of the possible Alt_hold fast climbing process.
The other reason is perhaps something in the mixing and PI loops, causing this strange behavior.
I've kept the log of this flight. I had another flight later, with a slower strange climb in alt_hold. I've kept the log as well.
Sonar calibration problem: i don't think so.
i have no sonar and i also ended the life of the quad with a what you call rocket climbing.
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.
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.
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: http://code.google.com/p/arducopter/downloads/list
You will have to upload these with Arduino software.
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.