FC: Pixracer
FW: Copter 3.5.5
GPS: Generic Chinese u-blox NEO-M8N
New quad. Did a few flights prior for autotune and shaking out any obvious issues, but otherwise not a lot of flight time.
Flew quad out some distance to get an estimate of RC range. Had some trouble seeing which way the quad was facing, and there was some wind causing it to drift away, so I popped it into Loiter to get it to stop moving. However the mode change failed and the quad kept drifting. After some minor panicking, I got the quad into loiter and it held position for a while, and then suddenly shot up into the sky at max throttle. I quickly put the quad back in Stabilize to get it to stop flying up, at which then it started spinning until I got it back into Loiter. At this point loiter seemed mostly stable, and I was able to fly it back.
From my own look at the logs there’s a few issues that seem to have happened.
There was an GPS glitch that unfortunately happened shortly before I tried putting it into Loiter. However all it says is “Unknown ErrorCode(2)”, while HDOP is <1 and it has lock to 12 satellites.
For some reason, the internal altitude calculations dropped like a rock, despite both the barometer and GPS outputting the correct values. This seems to line up with it asking for a higher altitude (DAlt), despite already being at that altitude.
For some reason, while in Stabilize, the quad spun, despite the FC saying it was trying to correct it (based on DYaw), but it doesn’t seem to be actually correcting it until it went into loiter (based on RCout).
Can someone help me explain what went wrong here?
Let me know if I need to add any more information. I really want to get the confidence to be able to put this in full auto.
Since you were range testing, how did you define your default PWM inputs in case of radio/receiver link loss ? It could be that the default value on channel 3 (Throttle) was high, so that when the RC radio link went into failsafe, it made your ship shot up in the sky (until you regained radio control)
Did you have any failsafe messages ?
I don’t believe so. I had good RSSI the whole time, and had tested link loss while on the ground by turning off the radio, and the FC correctly saw the throttle drop low.
Also, logs show that throttle was more or less constant, and I had dropped throttle to try to get it to stop rising.
Kyo, what kind of vibration damping, if any, do you have, and/or how stiff is your copter?
What you describe is usually a tell tale of excessive vibrations, and it seems to be the case (just looked quickly), with vibrations up to 3g on accel x and y for instance, on both imus. See vibration damping.
Nothing outside the foam tape holding it down. Copter is fairly stiff, but I don’t really have anything to compare it against in terms of stiffness. Copter is also fairly large 680mm frame with 15in props, which may be contributing to the vibrations.
Does the accelerometer normally override both barometer and gps altitude when both are available? Seems like an odd choice since barometer should theoretically be more accurate than dead reckoning altitude from accelerometer readings.
You should also look at the RCout values.
Something is not right with your CW motors (3 and 4) as the CCW motors are almost idling most of the time and having to shut down (<1100) quite often.
In this case any disturbance will cause the stabilisation to override altitude and you will observe a sharp rise in altitude.
Good point. I suspect the arms might not be on straight, given I eyeballed them when I mounted the motors. Any tips on making sure the arms are straight?
Do you know of any other common issues that can cause this sort of issue?
What I do to make sure the arms are (nearly) perfectly straight is to mount the arm to some “holder” (i milled one out of wood with a tube shaped recess in it and then secure the arm in that recess so it can’t turn) and then drill a hole into the arm on both ends all the way through into the wooden holder. I do the drilling either with a drill press or directly on the cnc mill - that way they are nicely “perfectly” vertical. As the arm is mounted during all of this and can’t move both holes are along the same axis.
Now all I need to do is have a matching hole in the arm holder on the centerplate and in the motor holder plate - with these extra two “alignment” screws throuh the “alignment holes” i can make sure that the motor holder plate is fairly well aligned with the centerplate. Basically you can’t get it wrong that way as long as the two holes in the arm are along the same axis.
I just fit the props and then eyeball them to make sure they all spin on the same level.Moving the props end-to-end all the way around soon spots a wonky motor.
