ACRO bug (fixed in 2.9.1b): while doing flips in ACRO mode, if you switch to Stabilize while inverted your throttle will go to minimum. To regain throttle control you need to switch back to ACRO then back to Stabilize again (i.e. switch to stabilize twice). You never lose control of roll/pitch/yaw.
Loiter/AltHold/Auto/RTL bug: if you switch into these modes with throttle at zero motors will go to minimum until you raise the throttle.
Auto mode altitude bug (fixed in 2.9.1b): setting a waypoint altitude greater than 320m over home altitude may wrap around and instead be interpreted as a low altitude.
ArduCopter 2.9 is now in the mission planner and the downloads area!
The major improvement is we use inertial navigation to improve altitude hold. This increased reliance on the accelerometers means you must do some additional set-up before flying:
3. If upgrading from 2.8.1, modify the throttle and altitude PID values:
Here is the list of major changes (a more detailed list can be found in the release notes):
As per usual PIDs are optimised for the 3DR/jDrones quad with 850 motors and 10" props. If you're using more powerful motors/props and are seeing bad flight behaviour in stabilize, start by turning down Rate Roll P in 25% steps.
Special thanks to our testing team lead Marco and the dedicated bunch on the 2.8.1 release thread who put their copters at risk while testing the pre-release version. Some of their videos are here: 1 2 3 4 5 6 7 8
Please feel free to report issues you find in the discussion below and/or add them to the issues list.
This seems to be the tlog
Hi,It seems to me, maybe do you have problem with Vcc, or anything bad during boot. In every way Vcc peak ( 0,5 V ) doesnt seems good to me.
Graham, looks like esc #1 is cutting off. Here is a plot of "servoX_raw" for all your motors:
You can see servo1 (motor/esc1) is being sent full throttle when things start going bad. That is usually a clear indication of a failed motor or esc, and yawing is a typical symptom of that. If it were the motor or a burned esc, it probably wouldn't be repeatable; it would crash and won't fly again without repair. So sounds like an esc cutoff to me... thermal or low voltage... neither of which should be used on a multirotor. Maybe you can "simonK" those super simple esc's? Not 100% sure, but worth a look.
Bill, IMHO the warning or change to wiki should be that the Maximum safe supply voltage on Input headers with JP1 removed is 5.25V and NOT 6V
Currently the wiki says the maximum supply voltage on the Input headers is 6V, that is simply wrong as the MUX chip cannot tolerate a supply voltage higher than 5.5V, which is the reason the MUX chip gets fried and no other chips is damaged.
It does not matter if USB is connected or not..
The MUX chip cannot tolerate 6V even if USB is not connected, if USB and BEC voltages are different all that will happen is the USB fuse may get warm, that's it. VCC for the entire board becomes whatever source can supply a higher voltage at that current.
Thanks Kevin, have replaced the ESC but it still does it, will replace motor next...
I also thought Vcc looked "rougher than normal", but I've seen my APM work fine in far worse conditions. From the logs it's pretty obvious that motor/esc1 is the culprit.
You know rethinking what I said above... something very well could be wrong with that motor. If motor1 had like a bad bearing, minor winding short, or burned magnet, that would result in higher load on esc1. That could make esc1 go in to thermal overload after some time in the air. Although, I still think that thermal and low voltage cutoffs have no business on a multirotor; they can add to safety with planes, but on multis they usually just make matters worse.
And yet it does it within a very short time. Strange, I ran each ESC and motor individually at 9A for 3 minutes each and can find no problem with motor or ESC 1 (quad hovers at about 4.3A each motor). This is a log after the ESC change with "motors" log enabled. I haven't changed the motor yet.
I have both the GPS status and the ARM with remote LED’s on A6 and A7. The ARM LED goes solid "on" at arming but begins to blink about four minutes into the flight. Happens every flight. I have LED_MODE set to 107. Any ideas?
At partial throttle an esc periodically sends a PWM chopped signal to each phase of the motor. At WOT an esc periodically sends 100% duty cycle. The period at which it must send these signals depends on RPM; it has to switch faster as the magnets speed up. However, that change in frequency is usually far less than PWM frequency. So due to the high frequency PWM component, at partial throttle the FETs have to switch on/off a lot faster than they do at WOT. Switching = heat... So, oddly enough, an esc operating at partial throttle typically produces more heat than it does at full throttle. This is why most esc's will choose to let out smoke while they're hanging out just under full throttle... versus when the pedal is to the metal.
Have you tried playing with esc timing? That sometimes has an affect on partial throttle efficiency. Some esc's allow you to change PWM frequency too, which might also help. If all else fails, you might just have to bone up for better esc's.
Full throttle is 14A so this was not 100%. I'm still trying to isolate the problem, have the quad clamped to the bench and have been checking rpm, oddly ESC/motor1 seems fine but Mot2 is low, just going to check through everything. (This is a quad with 250+ flights on it.)