PixHawk Drone keeps descending and we don’t know why

So I made a drone since I’ve made other RC models before, and I’ve been learning about all the extra things that go along with drones. Such as the extra sensors, computer and software and firmware.

I really like the PixHawk but Mission Planner has bugs and it often doesn’t connect or freezes, or won’t allow the PIDs to be changed.

The Drone’s an X8 with 4 arms and two propellers on each arm, with one above the other.

In flight, or even just above the ground, it will often start descending, until the throttle stick is at the top and the drone even rocks back and forth a few times before meeting the ground.

The frame is rigid (carbon tubes and plates) and the flight controller is properly fitted with gel in the centre of the frame. No Bad AHRS or any other fail safes or warnings.

In the Datalogs show the motor PWM outputs going wild when the drone descends. Also in flight, some motors will go to 100% and others to idle!

I’m not sure what’s going on here.

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

Join diydrones

Email me when people reply –

Replies

  • Try the latest AC3.5rc3 that's out now, is beta but it works pretty good
  • On flights where the drone does not have uncontrolled descents, IYAW is NOT doing these square edges.
    What is IYAW please? What effects it?

  • I have just found this on here
    http://ardupilot.org/dev/docs/extended-kalman-filter.html#extended-...
    (Am I right in thinking please an awful lot of the parameter names and locations in the Arducopter documents are no longer correct for Arducopter 3.4.4 and Mission Planner 1.3.44)?

    MX,MY,MZ - X, Y, Z body magnetic field biases (sensor units). If you are flying quickly, or are at low speed with EKF_MAG_CAL enabled, these will slowly change during flight as the filter ‘learns’ the earth’s magnetic field. These have the same meaning as the compass offsets, but are the opposite sign (eg in the following figure MX stabilises at a value of +35, indicating that a COMPASS_OFS_X value of -35 should be used.

    ../_images/MagXYZ.jpg

    For me (IF I'm looking at the right thing with names that are different to the Arducopter documentation),
    I have EKF_MAG_CAL ENABLED to (after first climb and initial yaw alignment)
    On the below screenshot:
    Red is altitude
    Green is IYAW in PINK that looked busy like it was doing something then slams flat with a ATT.YAW square edge (Which I am also unsure of what that is)
    And at the same time (50 milliseconds later) EKF3: IMX, IMY and IMZ start modulating and diverge. - So that does not agree with the above from Arducopter Docs (IF I'm looking at the right thing)!?


    3702362240?profile=original

    Same screenshot again with ATT.YAW edges visible in PINK

    3702362145?profile=original

    Extended Kalman Filter Navigation Overview and Tuning — Dev documentation
  • A new (and small) datalog attached.
    I'm wondering what's causing the ATT.YAW edges.
    Is this the EKF_MAG_CAL Mode? It's set to "After first climb and yaw"
    And I can see in the Log EKF3-IMX, IMY and IMZ are flat then go busy at this edge.
    IYAW looks like it stops working. And there just doesn't seem to be enough lift
    to stay airborne despite RCIN3 and Th0 going high.

    I read here that Copter 3.4 has multiple EKF implementation and YAW controller issues.
    http://discuss.ardupilot.org/t/copter-3-4-rc5-possible-imu-or-compa...3702362119?profile=original

    2017-03-08 09-43-33.bin

    D1 DataLog 8 March 2017 Run 2and3.png

  • Reading this on the PX4 website
    http://px4.io/docs/multicopter-pid-tuning-guide/

    I am looking for parameters for motor band limiting.
    I'm not sure if the below paragraph means it's something that can be adjusted, or if it's something that just happens as a result of the physical setup.

    Motor Band / Limiting

    As the above example illustrates, under certain conditions it would be possible that one motor gets an input higher than its maximum speed and another gets an input lower than zero. If this happens, the forces created by the motors violate the control model and the multi rotor will likely flip. To prevent this, the multi rotor mixers on PX4 include a band-limit. If one of the rotors leaves this safety band, the total thrust of the system is lowered so that the relative percentage that the controller did output can be satisfied. As a result the multi rotor might not climb or lose altitude a bit, but it will never flip over. The same for lower side, even if commanded roll is large, it will be scaled to not exceed commanded summary thrust and copter will not flip on takeoff at near-zero thrust.

  • Hi Andre, that's excellent thanks - I had thought of that one :)  Maybe it's a case of trying other propellers. Or spinning them faster. The motors get to their maximum rpm, and the PWM at 250us is topped-out. The motors etc are using only a tiny amount of power compared to their rating. So more thrust is possible.

    Now I'm wondering what the square steps in the Actual Yaw are: They do not agree with the Des Yaw, or RCIN ch4.
    I am still looking for a free online file sharing thing to get the logs online :)

    3702359427?profile=original

  • it's diverging is linked to the motor maxing out, one part is underperforming, to maintain attitude, the others need to perform less...   then, at some time the total thrust is less that what's required to maintain altitude.  

  • Ok so I need to sign-up to a google drive. (I will thanks)
    I completely understand that it's guesswork without the info the datalogs provide.


    But in my previous post I was simply asking if anyone recognised, or knew why the PWMs were diverging?
    I now believe the PixHawk is asking the drone to change it's attitude... and the drone just can't because with some motors topped-out, and others gracing idle, there's no more control thrust to change attitude AND lift the drone. 
    What's your thoughts please? Datalog? :D

    I'm now also looking for .param files for 7Kg X8's to compare settings if anyone has any offerings please?

  • share it from drive.google.com or any other service - there are hundreds..

  • The .Bin file is 64.8Mb so too large to upload here.
    Is there a way to cut it up or upload it somewhere else?

    Log Screenshot March 1 2017.png

    https://storage.ning.com/topology/rest/1.0/file/get/3702356774?profile=original
This reply was deleted.

Activity

DIY Robocars via Twitter
RT @SmallpixelCar: Wrote a program to find the light positions at @circuitlaunch. Here is the hypothesis of the light locations updating ba…
yesterday
DIY Robocars via Twitter
RT @SmallpixelCar: Broke my @HokuyoUsa Lidar today. Luckily the non-cone localization, based on @a1k0n LightSLAM idea, works. It will help…
Thursday
DIY Robocars via Twitter
@gclue_akira CC @NVIDIAEmbedded
Wednesday
DIY Robocars via Twitter
RT @luxonis: OAK-D PoE Autonomous Vehicle (Courtesy of zonyl in our Discord: https://discord.gg/EPsZHkg9Nx) https://t.co/PNDewvJdrb
Wednesday
DIY Robocars via Twitter
RT @f1tenth: It is getting dark and rainy on the F1TENTH racetrack in the @LGSVLSimulator. Testing out the new flood lights for the racetra…
Wednesday
DIY Robocars via Twitter
RT @JoeSpeeds: Live Now! Alex of @IndyAChallenge winning @TU_Muenchen team talking about their racing strategy and open source @OpenRobotic…
Nov 20
DIY Robocars via Twitter
RT @DAVGtech: Live NOW! Alexander Wischnewski of Indy Autonomous Challenge winning TUM team talking racing @diyrobocars @Heavy02011 @Ottawa…
Nov 20
DIY Robocars via Twitter
Incredible training performance with Donkeycar https://www.youtube.com/watch?v=9yy7ASttw04
Nov 9
DIY Robocars via Twitter
RT @JoeSpeeds: Sat Nov 6 Virtual DonkeyCar (and other cars, too) Race. So bring any car? @diyrobocars @IndyAChallenge https://t.co/nZQTff5…
Oct 31
DIY Robocars via Twitter
RT @JoeSpeeds: @chr1sa awesomely scary to see in person as our $1M robot almost clipped the walls as it spun at 140mph. But it was also awe…
Oct 29
DIY Robocars via Twitter
RT @chr1sa: Hey, @a1k0n's amazing "localize by the ceiling lights" @diyrobocars made @hackaday! It's consistently been the fastest in our…
Oct 25
DIY Robocars via Twitter
RT @IMS: It’s only fitting that @BostonDynamics Spot is waving the green flag for today’s @IndyAChallenge! Watch LIVE 👉 https://t.co/NtKnO…
Oct 23
DIY Robocars via Twitter
RT @IndyAChallenge: Congratulations to @TU_Muenchen the winners of the historic @IndyAChallenge and $1M. The first autonomous racecar comp…
Oct 23
DIY Robocars via Twitter
RT @JoeSpeeds: 🏎@TU_Muenchen #ROS 2 @EclipseCyclone #DDS #Zenoh 137mph. Saturday 10am EDT @IndyAChallenge @Twitch http://indyautonomouschallenge.com/stream
Oct 23
DIY Robocars via Twitter
RT @DAVGtech: Another incident: https://t.co/G1pTxQug6B
Oct 23
DIY Robocars via Twitter
RT @DAVGtech: What a great way to connect why @diyrobocars community is so valuable and important! Have to start somewhere @IndyAChallenge…
Oct 23
More…