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.
Well...you certainly don't have a vibration problem. That is spectacular! Were you actually flying?
Ah, so you think that while you're in stabilize mode the copter should hold it's altitude? I'm afraid that is not how it works. In stabilize mode the pilot controls the throttle completely...only in Alt-Hold, Loiter or AUTO modes is the altitude controlled by the autopilot. Apologies if I'm misunderstanding what you're saying.
Maybe this is a basic question, but doesn't the copter determine the RTL location (not the MP "home" location) as the first coordinates after achieving a lock? If it takes a while to settle down (which mine does) is it possible that the RTL location has significant error?
This could prove problematic if you're relying on RTL as a failsafe method and your copter returns to some location that's potentially off by quite a bit.
Is there a way to push your MP home location to the copter (or plane for that matter) as it's RTL "home" after GPS has settled?
Yes, the raw data above is from my last hovering.
Let me explain for the last automatically landing.
I just flied in stable mode, when I adjust throttle for hovering, the copter was down and land, then it disarm as well, I could not arm it again until I unplug battery and connect again.
This is very strange. I am thinking about there is any failsafe with voltage.
I have attopilot 90A, but I did not activate this failsafe.
In addition, the MP 1.2.32 seems to be not reliable. I feel it could not save parameters correctly.
Sometime when I connect it to the board, in screen radio calibration showed empty (all columns (throttle, ail, elev, rudder...) is grey although the radio is on and can arm/disarm the board.
My information is just for making the firmware better. And the progress now is very good.
The u-blox documentation (Receiver Description section 2.1) lists several dynamic platform models that can be chosen, and specifically states that "Dynamic platforms designed for high acceleration systems (e.g. airborne <2g) can result in a higher standard deviation in the reported position." I don't know which model is being used (I intend to dig into the code to find out some of these answers for myself, but I haven't had to the time to do so yet), but you might be able to make an adjustment there.
I also see from previous discussions that SBAS is enabled for both u-blox and mediatek receivers, but that the SBAS status is not currently visible to us. That leads me to ask another question... for the u-blox, is integrity monitoring enabled?
ok, I need to see a log files. preferrably a dataflash log file. Generally all mysteries are revealed once I can see a log file.
Yes, the old green bar issue in the radio config screen. That's purely a display issue and I'll remind Michael Oborne who wrote the planner about it. In fact, although the bars are all grey, you'll find that if you click the calibrate button on the bottom right, the green bars often appear.
Yes, log download via telemetry work in my system but stop to receive data after 1 minute.
my log about the issue has gone :(. I thought there is some conflict with my configuration so I erased all and load firmware again.
I just have the last log of my hovering.
Here it is:
I think it depends on what type of analysis we are looking for. On the amplitude warning LED indicator we are just looking for the delta of min max peaks over a short time period or even better a RMS value. This should give a first order idea of how strong vibrations are. For a min max delta we do not need to worry about the Nyquist frequency since we are not looking to determine frequency or reconstruct the waveform.
For the FFT analysis the Nyquist frequency would come into play. What is the sampling rate of data currently used for flight control?
Randy, how do you get that data for your graphs? Where are they? How do you get the scale on the right? NIce.. Got to have em...