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.
Replies
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_CALenabled, 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 aCOMPASS_OFS_Xvalue of -35 should be used.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)!?
Same screenshot again with ATT.YAW edges visible in PINK
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...
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 :)
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
-
1
-
2
-
3
of 3 Next