I have ArduPlane 3.1.1 in a 3DR PixHawk used in a flying wing, configured as a glider (no motor). I've noticed that if I start a Mission to a waypoint (all servos fully armed), but instead of letting the plane fly the mission, I just sit the plane on the bench, the servos will begin to creep in a certain direction and rail over time. I have the servos configured as elevons and the pitch component is affected, not roll. On inspecting the log files, the nav_pitch typically rails first to max_pitch (up or down), then the RCOut channels 1 and 2 will begin to drift at the same time causing the servos to drift. The drift may begin immediately or may take up to an hour before nav_pitch goes from 0 to railing.
I'm planning to drop the plane from a balloon, so I need it to be seeking the waypoint while suspended from the balloon, then once released, the autopilot controls the plane to the waypoint. I'm trying to use the software as-is (no added programming) to complete the mission. I'm not sure this is possible and I'd appreciate any advice in this area..
I tried a small test run where I dropped the plane from 1000 feet from a balloon. Since the control surfaces were railed, the plane headed straight down to the ground (did not recover under its own control). I had to snap to FBWA to recover from the dive.
The log files of the test flight and several bench tests are here. I would be happy to send further details about each log file. Some of them I had to split into BEGINNNING and END since they were loo large for Mission Planner to load. If you look at Nav_Pitch and RCOut Channels 1 and 2 you can see the servos drift over time.
Has anyone noticed the same behavior? I can reproduce it at will. The creeping may begin after a couple minutes on the bench or may stay stable of an hour, then creep. I'm not sure what is triggering the defect. But once it happens it puts the plane in a state that isn't flyable
Replies
That's a great suggestion, but I'm just not sure how it can be done. The plane will be completely out of radio contact (about 90,000 feet altitude) when it is released from the balloon. The release is just a timed release (you can program it in a mission on a given servo channel), not a specific altitude. It is automatic, completely done on its own without the radio. I was planning on having it go into failsafe (once radio contact is lost) and setting failsafe to "continue the mission" so the radio would not be needed.
Without code changes (which is always a possibility), I'm not sure of a way to make switches between modes automatically without radio contact. I wish there was a way to program a mission to wait for x minutes, then begin flying the mission. But the timer commands (Delay) depend on the program working on waypoint command first.
Another possibility (almost) which may help would be to run python scripts in the Mission. But I couldn't follow the documentation on the 3DR website (typical) to figure out how to do this, and even if I could, I'm not sure what the scripts might say to avoid the servo drift problem.
I'm sending the PixHawk hardware back to 3DR in a couple days just to check out if there is a hardware problem. My guess is that anyone who sets their PixHawk on a mission and waits too long to release the plane will see this problem (although it might be rare, since you usually snap it to a mission in flight).
I am certainly up for any other suggestions! Again, thank you for your response and help!
Thanks for your reply! I tried setting the I term to zero (also the D term, although probably unnecessary). This time the drift happened almost immediately. See the attached files. I graphed the RCOUT for channels 1 & 2, and the NavPitch. You can see that NavPitch drifts down to -24 (max), and the RCOUTs follow. Once railed (with lots of noise), they stay railed for the test duration.
During my actual field test, I mentioned that I dropped the plane from a balloon in their railed state. Once flying, the plane does not recover, but dives straight for the ground. Hmm...
RCOUT Channels 1 & 2.JPG
NavPitch.JPG