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.
Yes we could do that and that was my initial plan. The concern is what if you fly longer than you should and your battery starts to run low. This makes cruise throttle increase. When you replace your battery cruise throttle is still too high and you then might take off on 1/4 stick causing an accident.
Doing it this way is very predictable and that is what we want for the basic throttle setting. Not much can go wrong.
Later we may add a throttle mode that enables the auto tuned version, however the user would need to be aware of the risks. ie. when you use it at the beginning of the flight the hover throttle setting my be wrong, we won't be able to tell if the battery is getting low from our throttle position.
Nice. Thanks for all your efforts during testing.
The first officially supported ARM based board will be the PX4.
As for whether there will be an APM3 or not - those big hardware decisions are really up to Chris & Jordi (who take input from lots of people). I think 3 months ago we were hedging our bets about what was going to be the ARM solution but now that PX4 seems to be working there's less pressure to make an APM3. The original idea behind the APM3 was that it would be arduino based.
We are running low on compute power and RAM on the 2560 although that's been the case for at least 6 months but we've managed keep ahead of it by improving efficiency. There's still two known areas where we can improve efficiency further (geofencing uses too much RAM and dataflash writes are slow because they write 1byte at a time). I guess there will come a point where some new math intensive feature won't fit and if you want to take advantage of that you'll need to move to the ARM based board but I don't know what that feature will be yet.
Ah, he means because previously he had to connect each ESC to his receiver instead of taking advantage of the regular all-at-once method you can use with the APM.
To remove calibration completely we need to have a smart ESC with proper communication with the main controller. It's amazing to me that we don't have these yet but i'm sure they'll arrive in the next year in some form or another.
I've just checked the motors routine on my 3dr quad and it seems to work a-ok. We haven't touched this part of the code in quite a while but that doesn't necessarily mean there's no problem. If you can recreate the issue and maybe provide a parameters file I'll have a look at it. My guess is that your channel 3 min throttle has somehow become very close to the lowest pwm value that causes the motors to spin. My guess is that if you do the radio calibration and recalibrate your ESCs the problem will go away.
Did a run with about 8 WPs and the copter finished successfully. When it completed the waypoints, we attempted to use the RTL from the Actions tab in Mission Planner. At that point, all motors shut off. About 5 meters above ground they started back up, but it was too late.
I've attached the telemetry logs from Mission Planner for analysis. The logs on the ArduPilot are blank for that mission, but there are logs from previous missions doing the same day.
Hexcopter with the uBlox GPS and no sonar, running Firmware 2.9.
Hi Randy, I've been looking pretty seriously at dampening and isolation lately and I think I am actually making some progress.
I was surprised about the quality of these results but was applying what I had learned so far to the current design and from the surface it seems to have worked out really well.
Since our board is so small and light one of the most important tricks is to have the "solution" be short coupled: Nearer the actual frequency and total vibration displacement zone.
My F450 has the stand offs spaced considerably further from the board and even though it has longer O-rings it is under considerably more tension and although it dampens adequately (+ & - 5) its no where near as good as this and it has more total board movement (way outside the vibration zone) which can induce actual (albeit small) delay.
Restricting total board movement to 1/10" or less and having very progressive dampening (and not much initial tension) has produced this result.
I am pretty sure these principals can be used to produce a practical board mounting method that will result in similar performance.
After thinking about it again I realised what he was refering to... :-D
Thanks, What is weird to me is I am 90% sure I have calibrated that quad using the usb for power in the past, and didnt see this problem (I did see the problem where the bars are gray till cal is pushed, or reset is done) but it always cleared up easily. This quad is using the 3dr power board, so I have the power jumper removed.
I just thought of something else that may be drawing more current than the other one, this quad has one of the RFD900 modems on it, this could be the cause too. Not sure if I have calibrated the tx since installing it.. I bet that's it.
If I find the cause I will report back here.
BTW: I flew 2.9.1 today, It was cold and strong gusty wind from every direction, still, It flew beautifully, STAB, Loiter, alt hold, and acro, all default terms (except RATE pit and roll). great job (as usual).