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.
for bitmask : use http://ardupilot.org/copter/docs/parameters.html , calculate the bitmask from that info if you are using current AC build.
Sync issues is something you can hear, sometimes smell :) , google it - watch youtube for examples - you want to see perfect acceleration of propeller at any rate of fast stickbanging, no hesitation.
dataflash: nothing appears on SD ? - try removing (if any) partitions on it, and formatting it with FAT32 - if nothing, not even directories spawn, having tested different SD cards, I'd say the pixhawk is bad.
Thanks Again Andre!
The Bitmask, I've been looking at Logs on the Parameter List
I just wasn't clear on what was being called a sync issue. I have not seen any sync issues from bench testing.
Can a faulty power module cause DataFlash Logs not to be saved?
no, usually , you should have seen the folders be created, log started, it's common for it to abruptly stop logging on power loss. (and the logs are always useful until the last <second.)
I got the SD card working (Thank you) by formatting it and trying different Log bitmasks because some seemed unstable.
I also got the attitude to be stable with good control response by manually tuning.
Now the only real problem the drone has, is it will descend, for no obvious reason.
The PWMs from the PixHawk to the ESCs start to diverge (reducing over-all thrust) and their amplitude also gets a lot bigger, initiating a descent. From 6 meters altitude (above ground effect), and from a stable hover, at the end of the datalog on the right the drone just descended and no throttle stick input would arrest the descent.
CTUN ThO (not shown above) shows the PixHawk intended to climb, but the drone descended instead.
I'm going to try turning the PIDs down a bit, although only the kP is any value: kI and kD are very close to zero.
SO, I'm also wondering if turning UP kD will reduce the amplitute of the diverging PWMs. I just don't know why they are diverging. Yes I can see one motor is maxed-out and others are getting close to idle, I just don't know why. Its fine or 10 minutes at a time until this happens.
IMAX is also 0. – Can anyone explain what this parameter is and what its effects are please?
(I've read it limits the maximum I-gain, and I have Rate kI for roll and pitch at 0.06) (kI could do with being higher)
Stabilise or Outer PIDs are 4.5 for roll and pitch. What would turning them up or down do?
Any suggestions or recommendations are much appreciated :)
it sinks probably due to a local gravity anomaly.
would you like more wild guesses ? or prefer to post logs ? :)
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?
share it from drive.google.com or any other service - there are hundreds..
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?
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.
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 :)
Reading this on the PX4 website
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.
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.
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.