AC3.2.1 APM 2.5 Throttle pulsates in Loiter

Hi.

I have a problem after updating AC to 3.2.1 from 3.1.5.

When in Loiter, the the speed of the motors rev up and down/pulsate quite rapidly. This was working fine when I was using previous versions of arducopter.

I have downloaded the logs, and have looked into accX, accY and accZ. These seems to be inside the range specified in the wiki at arducopter. (Log_vibrations.bin)

Please have a look at the Log.bin, and note the difference between ThrIn and ThrOut when I'm in Loiter mode.

 

Anyone having any idea what the problem may be?

Log.bin

Log_Vibration.bin

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

            • What I have'nt tell is that  If I let go my stick of roll very gently , it would not overshot ,even after a high speed flight. I guess the reason for that if my frame is too light. After a hight speed flight the vehicle would climb normally , the althold controller have to reduce the THR_OUT to keep the vehicle from climbing .Once the THR_OUT been reduced ,the stb controller can't hold the fram stabile ,so it overshot ! 

              • There is common manual what you should do, to get drone in the air.

                It is on apm wiki, and if you follow all the instructions there it will get better.

                I know it could seem, that it flies OK and it is awfully boring to do everything from scratch, but for now there is no other option.

                I like to skip some steps myself and I should admit, there is no easier way than through manual.

                1. Wizard.

                2. Autotune.

                3. PID extra tuning if needed. 

                Right now you are trying to tune advanced parameter, when basic parameters are not in good shape. It's a good way to have headache.

            • I mean no problem WITH althold,it just roll and pitch got overshoot. the althold is good!

              my setup :HEXA frame size 680mm  F4006 KV680   30A blheli   1238   4S5000   2400g   

              I have'nt done autotune.  my pid is so large now,  rate_p  =0.25  rate_i=0.25  rate_d =0.024 , I am not sure autotune can success or necessary,since  the loiter mode is very good ,soild  in the air. 

              the only problem is overshot after high speed flight ,if I let go roll stick quickly.

              I have tried lower rate_p to 0.185 ,the overshot get bad,almost to 70 degree,So I don't know, should I keep raise my rate_p ,  since it is so large already now!

              • Just try autotune. It will do everything as it needs to be. 

                Handtuning PID is like searching for a cat in dark room by smell :)

                My PIDs were WAY too far from default values.

                But still I recommend extreme caution, 700mm quad is no small thing.

        • Still consistent with my theory since the change was between 3.2. and 3.2.1  :)

          • Yes, but 3.2 has a lot of useful features that 3.1.5 does not have.

  • /!\ Message for Dvelopers, please respond. /!\

    Obi Van Kenobi, you are our only hope.

    Can we use complimentary filter as it is shown in this artice?

    It might not require as much resources and speed as EKF, but it could give fresh breath to APM 2.x platform.

    Comments appreciated.

    Reading a IMU Without Kalman: The Complementary Filter | Pieter-Jan.com
  • Hello All,

    I am having this exact problem in Ac3.1.5 with APM 2.5. Alt Hold was working fine in 3.2.1 (or maybe not this bad) but when I downgraded I started having issues. I have a discussion page in the following link with more info and flight logs (http://diydrones.com/group/arducopterusergroup/forum/topics/capston...). 

    As you can see from the image below and the log (named: 2015-04-21 20-18-29.log) attached, although the APM knows that the altitude is increasing and the error between desired alt and barAlt is increasing, it doesn't compensate.

    3701986734?profile=original

    red (barAlt) green (desired Alt)

    Thanks for helping!

    2015-04-21 20-18-29.log

  • I wonder if any of the developers had thought of creating a fork?  Let the APM side go separate path?  The current code is too large to fit onto an APM, but it has a lot of code for the Pixhawk that had nothing to do with the APM.  So maybe someone can go in and remove the Pixhawk specific code to get it back to a size that would fit the APM and allow the APM to still enjoy the new features?

    • It's not that simple. The reason 3.3 is pixhawk specific is because it uses EKF only for navigation - which is too slow to run on an APM. So pulling in features would require that you avoid EKF stuff - and that permeates the 3.3 codebase. Better to fork 3.2.1 and fix specific bugs as they come up. Like this one :)

This reply was deleted.

Activity