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:

1. Perform the new accelerometer calibration in the mission planner (video).  The auto-trim metho has also changed (video).

2. Add vibration dampening foam between your frame and the APM.  Some suggested materials: DuBrogelhk foam.

 3. If upgrading from 2.8.1, modify the throttle and altitude PID values:

  • Increase your Throttle Rate P, reduce I to zero, increase D
  • Increase Altitude Hold P, reduce I to zero
  • Tune Throttle Accel P and I terms but try to keep P about 1/2 the size of I

 

Here is the list of major changes (a more detailed list can be found in the release notes):  

  • Alt hold using inertial navigation (Leonard, Randy, Jonathan)
    • AUTO_VELZ_MIN, AUTO_VELZ_MAX parameters control the max climb/descent rate for the autopilot (cm/s)
    • PILOT_VELZ_MAX controls max climb/descent rate for the pilot (in cm/s)
  • Landing improvements (Leonard/Randy).  Copter will descend to 10m or until an object is sensed with the sonar.  Then slows to 50cm/s descent (speed can be adjusted with LAND_SPEED parameter). (video).
  • Surface tracking with sonar (Randy/Leonard).  Copter will attempt to maintain current distance from objects in front of sonar regardless of altitude.  Only used in alt-hold and loiter, not used for missions.  Sonar can be enabled/disabled with CH7 switch. (video)
  • Failsafe improvements (Randy/Craig/John Arne Birkeland) including bug fixes, additional check for PPM encoder failure and implementation of battery failsafe.  Set-up instructions are here.
  • Mediatek gps driver accuracy improvements and use of SBAS [Craig].  Instructions on upgrading your mediatek to firmware 1.9 are here.
  • Traditional Heli improvements (Rob) including (a) bringing heli code back into the fold, (b) enabled rate controller (previously only used angle controllers). (c) fix to rotor speed controllers - now operates by switching off channel 8.  (d) allow wider collective pitch range in acro and alt hold modes vs stabilize mode  (e) bug fix to allow collective pitch to use the entire range of servos
  • Acro trainer (Leonard). Copter will return to be generally upright if you release the sticks in acro mode.
    • ACRO_TRAINER : set to 1 to enable the auto-bring-upright feature
    • ACRO_BAL_ROLL, ACRO_BAL_PITCH : controls rate at which roll returns to level
  • Camera control improvements (Randy/Sandro Benigno):  (a) AP_Relay enabled for APM2  (b) Trigger camera with CH7 or DO_DIGICAM_CONTROL command  (c) Allow pilot override of yaw during missions and fixed CONDITIONAL_YAW command.
  • PPM sum support for transmitters with as few as 5 channels (Randy/Tridge/John Arne Birkeland).
  • Performance and memory useage improvements (Tridge).

 

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.

 

Views: 297954

Reply to This

Replies to This Discussion

If you have the BEC connected to the PWM Inputs you should be fine with a current draw of up to the BECs limit. If you have the power routed via the APM PM or the PWM outputs, there's a diode and a 500mA fuse in the line. You are limited to 500mA max. Another user noted some issues with TM1000 telemetry causing voltage drops with the extra current it draws when telemetry info is sent.
See http://diydrones.com/xn/detail/705844:Comment:1103989
(I don't agree with the voltage changes read as the ADCs use an internal reference voltage, but the rest is something to think about)
I personally think the changes that Robert is adding log crtical low Vcc events help eliminte the brown out complications.

continued ....

In the 2.90, I noticed that playback of the flight i did outside of my house, was skewed about 5 to 7 meters apron from it's actual path when I played back the Tlog, this seemed strange.

Then I took my arducopter out to an open field and tried out the Loiter mode.. After holding about a minute and a half and some wandering, suddenly it tilted forward and abruptly tried to go away.. I stopped it quickly by switching to stable mode again.  I also noticed that in spite of arming and unarming repeatedly the previous home position a few miles away showed in MP as the "home" position.  

I finally used the link to set the home position to get it set to the correct location.   Continued ...

 

What's the epH epV values? (Estimated position horizontal/vertical)

So, I brought it home and fired it up again. The home position remained at the field I had just left, even after arming it and dis-arming it several times.  Then I updated it to 2.91.

2.91 immediately felt good and the loiter was much more solid and I could now move it to a new position without leaving loiter mode and it would stay out (most of the time)..  So, my limited use of 2.91 seems to be much better, however, I am going to wait for 2.92 or whatever it evolves too, simply because I have another copter to fly, and I can wait until these bugs are ironed out before proceeding.   I may do some testing though and will post here good or bad.. To sum up what I think, something seems to have changed about how the GPS data is used??  and being a programmer my self, and unexpected behavior that others have reported have shown itself with me too, when It tried to fly away that one time..   Thats All I've got.. and thanks again for all the hard work all you guys are doing and I sure a upcoming release will get us to a very stable, yet capable AP

leonardthall,

If your intent is to drive another user and customer away from 3DR, APM, arducopter and arduplane you are doing a very good job.  I will gladly use my APM2.5 fund for something else.  I'm glad I haven't ordered replacement parts because I will now not order them from 3DR.

People can use more than experience and hard data to form an opinion.  They can also use the observations of the person who is actually on scene.  Unless you are saying that the users and customers are all liars?

I troubleshoot computer networks and network switches for a living and I'm pretty good at it. I know when electronics are not acting as they should or as expected.  I know they don't always log what is actually happening.  I've seen them log events from ports that the port never actually saw.  I've also seen them not log things that actually went traversed the ports.  I know what I was doing with the TX and I know how the quad was acting.  I've clearly shown that the quad crashed 160 feet from the point where the logs shut off.  I've clearly shown that the the battery was sufficient as to not cause a brownout.  There are many reports of the APM hanging and many fly-aways.  There are many more reports of weirdness with 2.9.x than there were with 2.8.x.  There has been a major change in navigation between 2.8.1 and 2.9.  It's likely not a coincidence that there are many more reports of problems.  You can ignore them all you want to the detriment of the community. 

I wish I'd had telemetry.  I wish I'd had volts and amp measurement for the telemetry.  I did have Spektrum voltage telemetry for the battery and rx and they were both showing fine.  I wish I'd filmed the flight. I was here and you weren't. I know how the quad was acting and how differently it was acting than it did in 2.8.1. It was not a brownout and it was not pilot error.  Finally, I really don't give a damn if you believe me or not.

Randy,

Please understand that I very much appreciate your help.  I really do understand how much you go above and beyond to help users. So I'll get back to reasonable conversation with you on this incident if you want to keep conversing with me.  I hope you will forgive me for my rant.

I think I've figured out my frustration after reading you latest post with the updated graph.  I think you are focused on one problem and I'm focused on another.  Your focused on the GPS weirdness and I'm focused on the crash. I don't see the GPS weirdness as the cause of the crash.  My thoughts are as follows.  Even if the GPS were totally screwed, when I switched to stabilize the final time, the quad should have levelled of when I let go of the sticks and I should have been able to recover and land safely.  This did not happen.  When I realized the quad was no stabilizing, I tried the controls again.  I tried yaw, roll and pitch with no results.  The motors were audibly at full speed so I cut the throttle to minimum yet the motors were still at full speed.  I'm a good enough pilot to recover if stabilize would have been functional but it wasn't  I have enough experience to know when my inputs on the TX are not being replicated by the quad, they weren't.  I've attached the receiver to an Arduino Uno to test that the inputs from the TX are coming out correctly on the RX.  I've tested the battery and it is good.  I am confident that the crash was not pilot error nor the result of a brownout.

Facts:

I didn't have the throttle on full and hold full pitch and full roll while watching the quad crash into the ground.

I didn't panic, lose my mind and not know what inputs I was putting on the TX.

Spektrum receiver is powered by APM.

Spektrum telemetry module showed 11.2 volts on the battery and 4.7 volts on the RX.

When the battery was plugged into the charger it showed 11.3 volts and it has been charged twice and discharged once and in both charge cycles it charged to full capacity.

We don't know what was happening after the logging stopped and the quad travelled 160 feet and crashed.

Questions:

If there were an APM reboot caused by a brownout, wouldn't the motors stop and cause the quad to just fall from the sky?

Shouldn't releasing the sticks in stabilize mode cause the quad to level out and just climb if the throttle were high or sink if the throttle were low?

What could cause the the logging to stop but the quad continue at a high rate of speed and crash 160 feet away from where the logs stopped?

Theory:

At the time the logging stopped, the APM had frozen and kept feeding the  outputs at the time of the freeze to the motors.

Looking for a bit of help with 2 issues after updating...

Issue 1:I upgraded my standard 3dr quad to 2.9.1 and all went fine until it came time to calibrate my radio (DX8). As this video shows the values from my radio bounce around slightly even when the sticks are still. The calibration process ends and I'm able to fly but I have to constantly adjust to stay put. I think the inputs are also making my quad difficult to tune since the values are changing. Has anyone else had this happen?

Issue 2:

When I enter into Loiter, power completely cuts out. All was fine for me in 2.8. Am I missing something?

Issue 3:

Is the altitude limit supported on all APM boards? I set a ceiling of 10 meters and enabled Alt limiting in mission planner, saved the setting to my quad and took it for a test flight. Took off fine but exceeded the ceiling - went about 30 meters high before I brought it back down.

Any help would be greatly appreciated. Thanks.

Hi Jason,

The radio bounce may appear worse than it is. It is hard to tell from the video but your radio value may be right on the edge of a line in the display making it jump up and down with only a small change. You can look to see how big those changes are by looking at the actual time that is displayed in the mission planer here:

As for Loiter cutting out, do you mean that the throttle goes to zero and the quad drops to the ground or do you mean the motors momentarily drop before entering a stable hover. You can expect the motors to cut momentarily if your altitude is increasing. This is because the new Alt_Hold is quiet aggressive at maintaining altitude. If you are having problems a log with INAV and RAW turned on will be helpful.

As for the limits, I understand that their status is questionable at the moment and are officially a use at your own risk thing. Personally I wouldn't be using them yet.

Hope this helps.

Tony, I don't work for 3DR and I don't care where you purchase your equipment from.

I am just a volunteer here working to improve the code and help people out.

Leonard,

Thanks for the reply. I'll have to check when I have my laptop in front of me. I made another short video of the values changing in MP while connected via xbee. Are these values the same as they are in the area circled above? Also, I attached a log file that I think INAV and RAW are enabled.

The loiter issue - basically throttle went to zero and it began falling. I was about 10 meters off the ground, not climbing and was able to switch out of loiter and gas it before it hit the ground.

Thanks for the heads-up on the alt limits. I had some ideas for filming I was hoping to use this for. Guess I'll wait :)

Jason

Attachments:

leonardthall,

I'm glad your done wasting your time.  I don't recall anyone asking you to waste your time by butting into this conversation with nothing constructive to add.  I didn't become aggressive with Randy.  I just said I was angry that he was blaming me and/or a brownout.  If Randy fells like I was being aggressive with him, I'm sure he can stand up for himself.  I'm also sure he and I can sort things out for ourselves. 

You joined in the conversation and didn't add anything constrictive, you just reinforced the "if it isn't easy, blame anything other than the APM or code" mentality.  You called me "mate" in such a condescending fashion that my first impression was that you were being an ass.

I did not input full throttle, full pitch, full roll and drive my quad into the ground. I'm a good pilot, if I would have had control I could have recovered.  If the APM would have been running and stabilize engaged, I could have let go of the sticks and the quad would have leveled, not driven itself into the ground at full speed.  Again, if you don't believe me, I don't care.  Nobody asked for your opinion.

I'm not the only one seeing an increase in problems with 2.9.1.  Look at Nicks post, currently on page 153 of this thread.

I never said you worked for 3DR because it doesn't matter if you do or don't.  This forum, the hardware and some of the community is supported by 3DR.  If customers are driven away, withholding money is the only true power that they have.  If enough customers stop spending, 3DR may wonder why and try and fix what is wrong.  I realize I'm only one person and my money is not much in the big picture.  However, all bankrupt companies started their decline with the first dissatisfied customers.  Do I believe 3DR will go bankrupt?  No, I don't, I believe they will fix problems before that happens.

Is not good at the moment, for the x/y inertial nav wait the 2.9.2 exit.

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service