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.
DJI Wookong-M does not provide navigation features at the moment, but I'm not sure if these features can be upgraded just with firmware or if they plan to release a new board with additional hardware.
Right now gps hardware (including the cortex) is only used to loiter.
Did some more testflights yesterday with 2.0.48 but this time without any wind. Automatic mission performance was definitely much worse then with 2.0.46, I again aborted the mission.
I also noticed that engaging RTL while the hexa was slowly descending, kept it descending in stead of returning it home keeping the same altitude. I had to abort the RTL about 2m above ground and bring it back in stabilise with simple engaged.
Engaging simple with chan7 works very nicely.
Also tried circle mode. It didn't resemble a circle at all, just looked like a 'dancing quad', seemingly randomly rotating around its vertical axis. Loiter makes a much better circle.
I did the above test mainly to rule out the influence of wind on my previous results and also because I haven't had time yet to add my led modifications to 2.0.49 and upload it to the apm.
Balloon, which version did you use for that mission ? That looks pretty good, I had similar results on 2.0.46, but not on 2.0.48. Did you use standard navP of 4.0 ?
Nice video Jason !! Fun isn't it ? :-)
This's version 2.0.49. I used nav_P 3.0 and loiter_P 0.3
Which version do you have at the moment 48 / 49??
I used version 49.
I'm flying a Y6 configuration consisting of APM, PAN, campass, sonar, Xbee, Turnigy Plush 25A, RCTimer 2836 kv750, APC 11x4.7. I started with version 2.0.38 about three months ago. It flew well. I tried to upgrade to 2.0.41 but could not get it operational.
In the end of August I crashed the Arducopter due to a malfunctioning motor. Last month I build a new one and started to fly with 2.0.46. Last week 2.0.48 and since this morning 2.0.49.
It took me some time to get the Arducopter flyng with 2.0.46/48. Reason: somewhere after 2.0.38 the rotation directon of some motors was changed.
After adjusting direction of the motors de Arducopter was operational again. Behaved correctly on pitch and roll, but not on yaw. Turning to the left is OK. But turning to the right starts with an uncontrolled turn to the left. Giving more right yaw input makes the Y6 turn to the right at last. But small correctional commnds tot the right cannot be given.
This morning I changed the 2.0.38 code to support the prop directions of 2.0.49 and loaded it in the Arducopter. Test flying: no problem with yaw..
The difference between the code of .38 and .49 is that in .38 the power of the top motors is decreased to 92% (0,92) of the power of the bottom motors. This factor is now disappeared.
Entering this factor in the code againg solved the yaw problem alsmost. In fact, for my configuration 90% (0.90) is the correct factor.
Yaw to the right is somewhat slower than to the left but I am not longer surprised with a Y6 turning the wrong way.
Was there a reason for removing this top-bottom factor in a Y6 configuration?
Willy, I have the same issue with a Scorpion Y6. The Yaw issue has made 48 unusable for my Y6. 42 does well though. But I do not understand the code solution you mentioned. I hope Jason and others will look at this issue soon. What file did you edit for this factor?
I modified motors-y6.
I downloaded 42 and compared it with 49. I don't see any difference apart from a code clean-up. So another part of the code has been changed also,
So probably the issue is introduced between 43 and 46.
I shall make an issue report.
This is interesting. I will check in the GIT logs to see when this up / low ratio code has been removed. This seems to me a merge error somewhere.
I suppose that it is with 2.0.46.
Max has been the only Y6 tester i've been in contact with. He sent along the Y6 Mix based on the MultiWii mix. It's slightly different than our mix which is commented out below the MW mix.
He said it flew better and eliminated his issues with the earlier mix.
In 42 I see in motors-y6 the new code. Mat (above) reports its working. The same code is in 46. In 49 it is the same code also, but cleaned up. The old commented code is removed. Form at least version 46 the issue exists, So I assume somewhere else in the code something has changed.
The fix I made in motors-y6 removes the worst behaviour , but is not the correct one I think. Yaw is now is influencing nick a bit.
As I stated in the issue report (265) I am willing to test this issue. To me it looks as if somewhere a value boundery is exceeded.
A tip were to start digging in the code will help.