APM Copter 2.9.1.b has been released to the Mission Planner and is also posted in the downloads area.
2.9.1b is a maintenance release incorporating changes to 4 default parameters that have been optimized since 2.9.1 was released.  There are also 4 minor bug fixes.  There are no code function changes or additional features.
The changes are:
1) reduce default INS_MPU6K_FILTER to 20hz
2) reduce InertialNav Z-axis time constant to 5 (was 7)
3) increased max InertialNav accel correction to 3 m/s (was 1m/s)
4) reduce yaw_rate P default to 0.20 (was 0.25)
5) bug fix for alt_hold being passed as int16_t to get_throttle_althold_with_slew which might have caused problems if you climbed over 320m.
6) bug fix for throttle after acro flip (was being kept at min throttle if pilot switched out of ACRO mode while inverted)
7) bug fix to acro trainer to do with roll correction 
8) prevent cli from being entered more than 20seconds after reboot.
Users are recommended to:
    Update Mission Planner to 1.2.41 and
    Update their flight code to 2.9.1b from the Firmware tab on Mission Planner. There is no need to go through a new configuration process in the Mission Planner.


Views: 99895

Reply to This

Replies to This Discussion

I have seen the same behavior, which resulted in a nasty crash over the weekend:

Was flying FPV and at some point my RX went in to fail safe (action: RTL). It then came back to ALT-HOLD upon which I decided to engage RTL, just to make sure.

The Quad pointed towards home and went zipping towards home. WP_SPEED was set to 10m/s (36km/h, or 22 mph) (I just upped it from 5m/s/) . I noticed it descending rapidly and to my surprise the speed went way over the 10m/s. As a matter of fact it went well over 50km/h and it had descended so fast (and was not out of sight) that it crashed in to my neighbors roof at 70km/h (video went blank), skidded of and slammed in to the side of another neighbors house.

Result, not bad: broken props (carbon), broken arm and broken motor mount (I replaced the props with cheap plastic ones and she now flies much better using less power(!). However at 50% instead of 60%.


Cause: I suspect that the software prioritizes speed over altitude. When it increases speed, it simply does not have enough power left to maintain altitude. It does not explain though why the speed went well over the set speed of 10m/s. I never had the issue when the speed was set to 5m/s. The OSD and telemetry were showing a decrease in altitude (in other words: the APM was aware that it was descending).


Am I correct in my assumption that the software favors WP_speed over ALT_HOLD?



how did u tuned alt hold parameters...iwe started to notice same problem on my y6...

Emin, I can't remember the defaults but these are my settings now. Save or write down your current ones so you can revert if needed.

thank you...when you were talking about your problems i was not aware i have the same bcs i didnt fly for a while....also tought problems are more disaster...flying forward descend and flying backward ascend yes?mine is like that...

2 things to check if you don't mind

  • What does your log file show for an altitude? It could be the pressure is dropping around the baro and it is indicating to the APM that the vehicle is climbing.
  • Does the same thing happen if you fly the trunk?

just a quick question have you changed the 'RAW'in logs download to 'INV',thank you,Marty

sorry IMU is that the new raw,Marty.

Getting to know this release :-)
I've been tuning my TBS like quad the past days.

The alt hold and loiter were already working (taken into account that I use an APM1 with Mediatek on this frame).
The only issue I had was that, when in RTL, the quad started off like a Porsche towards the home.
I searched a little in this forums and turned my quad into a Beetle, now it is going home more slowly.
Also tried a guided flight with the Droidplanner om my tablet and must say it was nice to see that it was working quite well.
This was my test frame, so now moving to the real TBS with the APM2.5 and Ublox.

My initial idea was, if I can get it tuned on an APM1 it must certainly work with an APM2.5 :-)

My testing was done using trunk. I also have my baro in a container, and very little vibration.

If the weather holds I'll do some test runs and post my logs later. I'll try to explore the variables, like inav-tc and the amount of ventilation my container has.

Yes, that's correct what was RAW is now called IMU in the latest versions.

Thank you very much Dave.

I just had a crash in this version. The Multirotor started behaving realy strange. Can somone help me understand what happened. First the GPS behaved strange taking forever to lock. But I don't use it so I did not wait for more then 6stelites then started flying.

Then I was flying around in Acro in average wind gusts. A little unstable but ok for just flying around.

Then suddenly it would not obey me I have flown this multirotor many hours total,with no such problems. And I Got some random controol back, when trying to make it come back to me it responded random. Luckily it ended up in a bush with only some broken props. and not a broken nex5r camera. I don't know what to look for in the logs, because those logs to me are some alien language :) I supply mission planner logs and flash logs.

the flying starts at ~76% off the tlog file don't kow if its the same with the flash log because I dont understand how to read those files. was leting it sitt outside for a while before flyig to let the gps get new locks since it was not even connected to the multi rotor since friday.

//Edit spelling and stuff


Reply to Discussion



Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service