@bnsgeyer
That flight that the problem occurred on was the first flight using 4.0.4. I reverted it back to 4.0.3 which we had flown many times without a problem. I’ll let you know how that goes.
@tridge @bnsgeyer
Would it hurt anything to just go ahead and set it to 1 now and leave it there till I get a chance to do a real test?
From my discussion with Tridge that would be fine. From my understanding of the feature and I am in no way an expert on it, it shouldn’t adversely affect the servos. You may just want to power up the system for 5 min and just verify your servos aren’t getting overheated.
We went out to fly with 4.0.3 after about 10s the problem showed up but not as bad as in the video. We easily landed it. Before we shut everything down we were able to replicate the problem and took some video of it which I can up load later.
So here’s where it gets deeper, it was only one servo doing it #1, we were able to bring it back inside and power up again and could see the problem, the servo wouldn’t completely die but would stop intermittently. This could be a bad servo, maybe, it’s always servo #1 even if I move it to a different channel. The servo’s are fairly new BK servos, there maybe 3 months old from when I bought them new.
I changed the BRD setting to 1, and couldn’t replicate the problem, so I switched the setting back to 0 and of course it worked fine no problem. Right now I’m not sure if it’s the servo or the FC.
One question is do you know if changing the Volts setting requires a Re-Boot to take effect?
If I can get it to fail again and it doesn’t require a Re-Boot to take effect I could change it while it’s failing and see what happens.
yes, it does require a reboot
this is very much sounding like a hw issue, but if you do still suspect software then we really need to get a trace of the signal going to that servo. If after you do some more testing you do suspect a sw issue (eg. if you swap out the servo and it still happens) then let me know and we can discuss how you can get a trace
Just to confirm when you say a HW issue you are referring to the servo itself, I don’t want to assume anything.
yes, from you’re recent reports it sounded like it is most likely to be an intermittent servo problem (or cable). I don’t want to just assume that though, as if there is a hidden software problem I really want to know about it, so please do as much testing as is needed to convince yourself one way or the other.
Also note that it could be a problem in the flight controller hardware. It isn’t likely, but we have had cases in the past where a servo output pad on a board was intermittent.
It’s great that you can reproduce, at least sometimes, on the bench. One thing I commonly do with intermittent issues that I suspect may be hardware is use freezer spray to cool the component and a hot air gun (or hairdryer) to heat it. Sometimes an intermittent problem will happen more often when you heat/cool it, which helps to narrow it down.
I am an electronics guy, I have several oscilloscopes and logic testers, etc. I know I can get to the bottom of it. I’ve spent the last 30mins trying to get to fail again, Yep, time for the cold spray and heat gun.
Well, after freezing and baking the servo it still wouldn’t fail. It could be a bad solder connection inside the servo that vibration is causing it to fail. Anyway, I replaced the servo and will try it again.
I do thank everyone for your help !!!
1 Like
Well, despite the fact my diagnosis was correct, this is not the same thing we saw. All three stop intermittently, and for us it also manifested itself as a random “jumpy” collective response. And never got it to happen with a V5, which I think is what you got.
If it is only one servo I’d lean hard toward thinking it is a hardware problem - servo itself, maybe a bad connection on the crimp on the pin, cold solder joint on the pin on the carrier, etc… If it is a bad connection duplicating it on the bench will be difficult. It usually requires the normal vibration of operation in flight to make that evident.
If it were me and it can’t be found thru inspection, rather than replacing stuff on a guess I’d test it to failure in flight, hovering at about one foot. NEVER tie the helicopter down and run it on the ground at full power - that will blow the IMU’s, and despite the fact it is tied down a 800 will roll, twist itself out of shape and ground strike the rotor. A good pilot can still handle the helicopter on two cyclic servos if 1 or #2 dies in flight. Theoretically you can handle it if #3 dies too, although the collective control then becomes horizon pitch control, and it usually takes the pilot a bit to figure that out, which requires more altitude. So whatever you do, don’t swap a suspected bad cyclic servo to #3.
When 1 or #2 fails the collective is a bit tricky and have to use powered autorotation to get it back on the ground. At one foot you can basically just cut the power if it fails.
In the log you posted your pilot was using Stabilize and that is not the mode to use when testing for a suspected intermittent servo. That will only confuse the autopilot (self-leveling). Anything with altitude control will roll the helicopter as soon as you cut the power to do a powered auto. So use Acro. We modified Acro so you can set it for direct stick-to-swash control, and that will allow your test pilot to keep control of the machine with a dead 1 or #2 servo. When servos fail they normally lock in-place. We train our pilots on how to handle the helicopter with a dead cyclic servo by unplugging one and locking it with a zip-tie. Then fly it on two with student-instructor slaved radios so the student can learn how to use power for altitude control. We don’t want to lose any $15,000 helicopters due a simple failed servo. But Acro is the only mode it can be done in.
What?
Stabilize does not have altitude control. You can do a powered auto no problem at all.
And there’s actually very little difference in the control scheme between Acro and Stabilize. The difference is more in how they handle pilot inputs, not in the control outputs.
1 Like
Rob, please try flying a three-link helicopter on two swash links in Stabilize. It doesn’t work. The machine is uncontrollable, and Acro is not as you remember it to be. We modified it for helicopters to provide direct stick to swash control (with the right settings) so it doesn’t hold attitude anymore with a bump and center. Instead it bleeds off to current attitude, and that is adjustable. Collective pitch can’t be used at all, and must be set to where there is minimal cyclic effect from collective cross-control, the pilot handles the rest with cyclic and throttle alone.
With a dead servo, a pure pitch or roll input results in a combined input in the other axis, plus interaction on total collective pitch, depending on which swash link is compromised. Only a human pilot is able to handle that. The pilot’s duty is to identify, correct, execute to get the helicopter safely on the ground. The SAS will crash the helicopter. No different than stuck pedal and stuck mixer box training in manned helicopters.
The autopilot can only handle dead servo on four-link swashplates, and even that is not pretty. A human pilot is able to handle it much better.
I developed the failed servo training for our pilots to prevent losing expensive helicopters due to a failed servo. If you think it is possible in Stabilize I would like to see it demonstrated.