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.
If your radio's Yaw is not centered into the dead zone, it will be sending Yaw commands proportional to your stick movement. Check your radio to see. it may be just enough out of trim that you are commanding a slow yaw.
Tried it last night again.
Made very sure that all trims are neutral
Made extra sure that im not giving any rudder during throttle. (Gustav flies mode 1 btw, so that rules that one out too)
Im still thinking that it is a software thing, as the only thing that changed from stable to yawing is the firmware upgrade.
I'll play with PID values on the weekend, and post my findings.
pretty sure you checked them, but what about the subtrims?
"Added ability to dynamically set wp with toggle switch"
I see in the Git that has been added this capability in the very last version. It´s fantastic¡.
I think it´s very useful since you can program AUTO paths without the need of a computer,
directly in the flight area.
Seems that it´s activated as usual, defining what the ch7 do (in defines.h)
#define CH7_SAVE_WP 7
That define only enumerates that option along with six others to choose from
// CH 7 control
#define CH7_DO_NOTHING 0
#define CH7_SET_HOVER 1
#define CH7_FLIP 2
#define CH7_SIMPLE_MODE 3
#define CH7_RTL 4
#define CH7_AUTO_TRIM 5
#define CH7_ADC_FILTER 6
#define CH7_SAVE_WP 7
In APM_Config.h the default option is still set to "do nothing"
# define CH7_OPTION CH7_DO_NOTHING
I haven't flow this yet. There is a potential for it to crash a quad if the eeprom writes aren't queued (which they aren't yet). That's only if the quad is in the middle of an aggressive maneuver, though.
I'm keeping these compile time only because they are still pretty experimental and I want them on a different track than the beta.
yep I noticed the same problem - just to be clear the problem is with Safari browser on an ipad. Browser jumps back to top of page every 10 seconds or so.
That's because of Flash, which is used in several places here (we use the Ning platform). The Chat window at the bottom is one of the problems, and Ning is migrating that off Flash over the next few weeks. That should help...
So, I'm seeing varying performance from loiter. In a decent breeze just now the quad loitered within a few meters with no excessive position error and good control, and sometimes the error was quadruple (5m to 20m) with the ground speed roughly doubled. The seeking seemed to form more like a wide circle too. Is it just the limits of what nested PI loops can possibly do? I don't see how increasing the P terms could result in anything but a return to overly aggressive behaviour, and Nav I can't help with error that adds up to zero. Nav I term was the default 0.25 and it often fought well enough against the wind, but not always. Perhaps a bit more max int for that one? Nav P was between 3 and 4; I should try and shoot some shakycam clips of the nice and worst behaviour tomorrow... It's often a bit of a hit and miss, depending.