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.
Just took it out a few mins ago, I had reflashed it with 2.9.1, did an erase, recalibrated, and set everything up. all looked good.
as soon as I took off, well the first time it started to yaw and I backed off right away, I went out and rebooted (ahhh, I hope the modem reconnected) took off again, giving it a bit more gas, and it yawed and yawed till I could get it landed. It seems like it is in full time yaw now. I am not sure where the compass offsets should be, but they are lower than before, when I went outside tonight they were zero from the erase.
I wll attach the logs from these very short flights, I am not sure which one is which, actually I was surprised there was 2 from around this time, unless it started a second log when I rebooted (i disconnected the batt, and then pressed reset button)
I had a very similar incident happen twice to me with 2.8.1.
The 1st time I thought it was pilot error, the 2nd time there was no chance of pilot error.
The video from the second time revealed a strange hum just before the incident, which I then tracked down to a marginally bad bearing in one of my motors.
My suspicion is that motor pulled more juice than it should have (when the sound was heard) and APM browned out. (Heck maybe APM didnt brown but no more power could be had from the battery for the motors?)
I haven't had the time to look at the logs from the 2nd episode.
But I also experienced similar feelings of lack of throttle response (indeed the 2nd time my throttle hit full and it made no difference) during the incidents.
Thanks a lot, very important for my understanding of this.
So, except excel you don't recommend additional software for normal use and analysis?
What are the program name for LogBrowse as I want to associate with my log files without CLI stuff, boot etc. from MP.
What about a "process use" in HUD. Also a button in MP with something like full-log/normal-log.
I'm not lazy but tired of moving to USB, reboot after using CLI. It's a kind of frustrating when playing with this beautiful platform.
Again, thanks a lot for your response and all the work you do.
Ok, good ideas. we can definitely make a little screen which allows you to turn on/off the logging instead of having to go into the cli and do the whole enable/disable thing. That's actually very easy so I'll talk to michael o about that.
What's a little harder is transferring the logs without going into the cli. We can add that as a longer term goal though.
- future is so bright...
Regarding inertial, Biggest problem seems to be motor / prop vibration.
Solution is actually pretty easy, proper isolation and dampening of Flight control board.
I started a discussion on Vibration isolation and dampening for 2.9 - - and have managed some excellent results myself.
Check out the discussion and the replies:
I O-ring suspension mounted my APM 2 in my Flamewheel 330 and managed + and - 1 Accel vibrations.
Plus and minus 5 is more than adequate for solid inertial and that is what I have on my Flamewheel 450 also O-ring suspension mounted but not optimized as well as the 350.
This isn't rocket science, the biggest problem is for those people using dampening materials, they usually use way too much of it or way to stiff a material for the really light APM (or PX4) flight control board.
The shock isolation / dampening system needs to be optimized for the mass (weight) of the control board and the flying vibration frequency and amplitude of the air frame.
For us that translates to not much total movement, very progressive and just the right amount of dampening.
Check out my discussion and if you can't de-vibrate your flight control board adequately for inertial navigation youve got a lot bigger problems than that.
Inertial nav is the future because it is A LOT better, make the move and move on we are going to need what little extra code space we can squeeze out of the APM to do interesting new things not hold up old inadequate methodologies.
Nice! I've added a link to the discussion from the trouble shooting guide here.
By the way, we can't make any promises about master at the moment. The 2.9 branch is what was used for the 2.9.1 release. We will cut all the final improvements from 2.9.1 into master in the near future. Some are there, some are not. So for example, the THR_MID improvement is not in master yet.
Randy, talking about HUD
In upper right corner the sat.time is displayed. It would be nice if it also showed the dated&year.
So great to see while replay logs.
In earlier post i had a wish with time stamp on logs together with the accumulating number in CLI view. Should be easy to expand this sat.time a bit in stead.
I am just wondering what "master" is?
We pulled in the big guns on this problem and got Tridge (master of the compass learning algorithm) to have a look at your logs and it's very clear that the issue is interference from the motors. There's so much interference from the motors that the learning algorithm simply can't learn what your offsets should be no matter how much time and data they are given. The offsets get worse and worse instead of getting better.
It may help to reset your compass offsets to zero or do the "live" calibration method and ensure that COMPASS_LEARN parameter is set to zero.
The best thing to do though is to somehow get your APM further away from the source of the interference or if you know which parts of your set-up are causing the trouble, you should replace them.
One very positive benefit from looking at your logs is it demonstrated the importance of the motor-interference-compensation code that we're working on for 2.9.2. Below is a graph of you mag field with the current algorithm (red) vs the new one (green). Ideally your mag field should be around 300. It's ages away from that with the current algorithm but much, much better with the new.
So...reduce the motor interference or wait for 2.9.2. By the way I think you would have had this problem with 2.8.1 as well although perhaps it's made worse by the more aggressive alt hold which likely moves the throttle around a bit more.
ok. 2.9.1 feature - time to upgrade.
I am running Simonk firmware - whats the bug fix actually fix?