We were tuning the governor on a 800 size gas heli and if you look at the last flight on the log you will see that especially roll went nuts. We were able to get it down in one piece. But I can’t determine what went wrong. Any help would be appreciated.
https://drive.google.com/file/d/14Dk6tmz-A8T_1RqCGJZOyE-wTmmIYWxN/view?usp=sharing
What I don’t know is, was the crazy-ness caused by the autopilot losing it’s attitude solution, or was there some sort of interference causing the receiver to send bad erroneous info to the autopilot, or maybe a transmitter problem.
Heli was being flown by a 3d pilot so I now that the stick inputs were correct.
Heli had been flown about 20 times before with no problem.
We were tuning the head speed and had just reduced the head speed from 1800 to 1700 on the last flight when this occurred.
Also I had just upgraded to Copter 4.0
The problem is right at the end of the log, heli took off fine and about 7 seconds into the flight started making rapid roll movements, we were about 5 feet in altitude.
I would like to get some input on what may have caused this before we fly it again, Thanks
Hi Doug,
I did take a quick look at it last night. Vibrations looked acceptable. I didn’t see any errors from the EKF. I did notice that all the PIDs were zero but I forget to check the H_FLYBAR to see if that was enabled. I am guessing from the PIDs that this is a flybarred heli. The zero PIDs explains why the pitch and roll attitudes were biased from the actual attitude. And really that is an I gain thing. So one recommendation I would have is to increase the I gain to maybe 0.1 and also the ILMI to 0.08 in order to help the controller hold the desired attitude. I don’t know if this caused or contributed to this but it is always good to have the desired and actual values closely follow each other. It will give the autopilot better performance.
I will look at it a little more tonight. Reducing head speed with a flybarred heli can get you into a less stable state. Not sure what weight you are running in the flybar but it is possible that contributed. Then with the attitude feedback in stabilize mode, it could have set up a low freq lightly damped oscillation. Just spit balling though.
Thanks for the input Bill,
I have two electric 800’s and two turbine 800’s so I’m pretty familiar with setup.
This is a flybarless heli,
I did notice the bias in desired vs actual, I meticulously set swash plate to level, balanced the blades, and tracked them just like the other 4 heli’s I have. They all have three blade heads and three blade tail rotors but this is the first gas heli I’ve set up, the engine has been balanced.
The reason that the PID’s are zero is that we were just beginning the tuning process and wanted to get the head speed where we wanted it before we set the final values for VFF in roll and pitch.
This is using a Orange Cube but I have it pretty well vibration dampened, having said that I do know that Chris had a few Cubes go belly up from vibrations destroying the internal connections to the IMU, but I think he was hard mounting the flight controller, he thought that because the vibrations are very high at idle and don’t calm down till the engine reaches about 8000 to 9000 rpm that it just shook the IMU apart.
Here’s a short video of what happened
At the start he’s increasing and decreasing collective to check how the governor is responding.
Where the video cuts off (because the guy taking the video started running, Haha) it looks like the heli is going to crash, the pilot did save it with just a slightly hard landing.
@Shotfire nice video … looked at your data, did you get “land complete” during flight ? or is it a series of take off and landings ?
It’s a series of takeoff and landings, we we’re tuning the governor
You are not going to shake the IMU’s apart in that amount of hours with the control solid-mounted. That takes time.
We experienced that same sudden loss of control maybe about a year ago when testing ChibiOS builds. I found it was the servos randomly glitching or locking up. Nobody else could verify it, it was blamed on the control, I later verified it with two different controls, both 3.6.x and 4.x versions. I suspected it to be an issue in the I/O or I/O firmware.
Your video demonstrates EXACTLY what happened to my test pilot on two different flights before I tested it myself before I’d believe it, and then went to testing on the bench after I figured out what it was. Testing on the bench in armed state it would sometimes go 15-20 minutes of exercising the servos before it would suddenly lock up.
We were under time constraints at that point in testing, we reverted to NuttX and I never got back to looking into it further.
WOW, thank you CHRIS
Doug,
If this is the same issue that Chris is referring to then I will have to talk to @tridge to find out how to get the data to prove this is a problem. I suspect that a log will not show this issue since it is occurring at a hardware level. Maybe if someone with UAVCAN servos could test this (@JoshW 
) then we would have data that shows what the servo received.
I will let you know what I find.
Can show what they received and what they were doing.
@bnsgeyer Tell me how to test this to your satisfaction and I’m happy to see if I can help.
@ChrisOlson were there any special hardware requirements where you saw this more often than not. @Shotfire was using a Cube Orange. What hardware were you using when you saw it? I seem to remember one of them being a CUAV V3?
@JoshW This sounds like a test where you are watching grass grow. I would say that you should disconnect your motor, arm the aircraft can make it think it is flying. (maybe arm it on the ground and then lift it to a table and raise the collective to mid stick). Then keep on cycling the cyclic until you see a glitch in the servo movement. From what Chris says, it is pretty evident when it happens. He said sometimes it took 15 minutes to happen.
I’ve just had a think on this… I don’t know if doing this with UAVCAN would be a good test as it gets actuation commands differently than a normal servo.
Oh, cause it goes through the CAN bus. It might be worth trying, just to see if it is common between outputs. it might give @tridge more info on where the issue could lie.
EDIT: Anyone know how I could measure the servo position and feed it back into the controller in order for it to be logged? @Felix do you log your servo positions?
Just a FYI, I hadn’t seen this problem until yesterday right after I upgraded to 4.0.4, I just put 4.0.3 back on it and will try it tomorrow. If this happens in the air you better be a good pilot and keep you wits about you and prepare for a semi-crash hard landing. It can be saved but it is a hand full.
One other thing but not related to the loss of control issue. With 4.0.4 I was getting GPS glitch messages rather often, I noticed after going back to 4.0.3 I’m not getting any GPS glitch messages
V3 and V4 with an I/O. Never got it to act up with V5 either with I/O, or without.
I didn’t look at Doug’s log, but what you should see is a pilot input that seems to be larger than necessary, and then a delay before the attitude of the heli responds. And when it does respond it’s quite large, simply because of the pilot input. The rest of it is just the pilot “chasing it” to gain control again.
This was a year ago, but I never had it had lock up or glitch solid - it is momentary and random. I could see if I can dig out my old log when I tested it, but IIRC it didn’t show anything - the FMU pretty much works as normal. It appeared to me to be a glitch in the I/O and I think tridge said something about needing a logic tester to diagnose it.
Yes, when I looked at the log rc inputs it looks exactly like you describe, It appears like pilot over control and then you see the heli do a delayed rapid and over responsive attitude change.
@Shotfire I spent some time going through your log with Tridge. He was able to help me determine that the IOMCU was receiving the commands and they were synchronous with the commanded output from the motors class. He said that doesn’t guarantee that there isn’t still an issue with the code. So we thought the next step was have you do some ground tests to see if you can reproduce the issue on the ground. Tridge said that if it is an issue with the IOMCU then whether the aircraft is armed or unarmed does not matter. So his thought was just to have it run the servo test multiple times unarmed. Hopefully you can reproduce the issue.
Now if you can, one thing that Tridge thought could be the issue is the servo was not receiving a clear data signal. I guess servos were originally designed for 5.0 V but have been modified to accept 3.3 V. The Cube Orange was designed with protection to keep interference from coming back from the servo. Thus the protection requires a higher current drive and can cause a voltage drop and erratic servo response. The IOMCU has a software setting that increases the voltage from 3.3 to 5.0.
If you can reproduce the issue, Tridge thought that an easy thing to try to see if it fixes the problem is to set the IOMCU to supply the signal at 5 V instead of 3.3V. You can do this by setting the following parameter
BRD_PWM_VOL_SEL to 1
Let me know how the test goes.
No, I don’t log my servo positions. I just look at the PWM outputs which I calibrated to a servo position. Under normal conditions that’s absolutely sufficient, because the servos are strong enough to actually be at the positions where they should be.
Now for the test I would suggest connecting a second flight controller to the servo outputs of the first one. That way you could see the signal the servos would receive in flight. Do you have one that can still accept single PWM Servo inputs? One of the good old APMs would do it.
BTW, I’m running FW version 4.0.3 and haven’t seen the problem so far. Fortunately!