OK, the problem is your motor interlock keeps disabling because your Channel 8 signal from the RC keeps going up and down (the blue line)
You must have some sort of mix tied to the channel 8 signal from the collective in your radio. You have to disable that. The Channel 8 signal should be a steady 2000 pwm when it’s on. And 1000 or less when it’s off. When you pull the collective to the bottom, it hits the lower limit and disengages the throttle, thinking you have turned the switch off.
OK so what I discovered that fixed the issue was I had my endpoints in my radio at 150%. Not sure why I had done this but lowering it stopped the issue. All is well now as far as I can tell!
Here is the log file with everything working correctly as far as I can tell.
No, that wasn’t the problem. The problem is that you have a mix between your collective and the channel 8 throttle signal. The Channel 8 signal is either on or off - it does not vary - yours is bouncing all over.
This is the plot of the RC IN to the Pixhawk and your channel 8 signal is moving up and down with the collective. Get rid of that mix in the radio.
I can’t believe I missed such an easy direction in the set up! I guess since it is so different from the norm I read right over it. How about this?
Looks very good, Chad. Now you have the output of a typical 85-35-85 V-curve for a nitro engine. This should work really good for you with no governor, or with a governor with a “stick switch”.
I am currently testing code with a MODE 3 5-point smoothed curve. The initial results look really promising.
Great! I am very interested in this as well because I have decided I am going to build a gasser. The 766 looks like the best platform by what I see looking around. I like the bigger size and will definitely stretch it to 806. Beyond that all I’ve ever used was a 3 point curve with a nitro before I had a gov. I see how the 5 point would make more sense with the gasser.
I would suggest the 766 configuration. If you get a TRM 310SX engine, it likes to run at 10-10.5K rpm. With the 7.5:1 gear ratio that puts the head at 1,350-1,400 rpm. Which is perfect for the 766 rotor (400 fps blade tip speed), but too fast for the 806 (435 fps) as a UAV platform.
The 766 ends up being the better performer on fuel burn, flight time and power loading. And it gives up nothing to the 806 for payload - either one will lift and carry a 25lb payload with ease. The 766 will hover for an hour on 2qts of gas, with 10 minutes reserve. The 806 doesn’t quite make an hour. The 766 will flat out kick the 806’s butt on a 100 mph run if you ramp it up 14,000 rpm.
With a little deeper gear ratio to get the head down to 1,150-1,250 rpm, the 806 would probably be about equal. It will fly at 1,150 but the engine is at the peak of its torque curve and has no torque rise with increased collective loading. And you have to increase the tail drive ratio to 5.1, which uses more power. The 806 really needs a 340 engine with a 8:1 gear ratio.
Bigger is not always better.
Edit:
The 806, however, is a perfect match to a Wren 50i turbine. And Carey has most of the parts you need to adapt a 44i or 50i turbine engine in it.
What kind of flight time can be expected with a turbine? I have not looked much into them before.
SOLD!
The turbine engine has double the power of a gas piston and burns 5x the fuel. You’re looking at 5 oz/min fuel burn with a 44i or 50i. So 2qts is good for about 12 minutes. Run 'em much below 75% torque and then you risk a flameout, so they’re definitely good at getting rid of JetA.
Well that does not sound good for UAV usage but would be a hell of a good time!
1 last issue I hope… I have noticed this throughout the build but forgot to mention it. The servos are jumpy throughout the range. The closest thing I could reference to is actually busted crunchy servos. The servos are brand new though and have maybe 5 flights with zero crashes so that is not the case. Here is a video showing it but the camera does not pick it up well exceot the sound. The servo horns look like they are vibrating.
Yeah, for some reason they do that on the bench with the Pixhawk, and I don’t know exactly why. Armed and in flight they are smooth. There is a parameter you can set, H_SV_TEST that is default 0. What that does is when you boot the Pixhawk it will exercise the servos thru their full range at minimum and maximum collective to check for proper servo operation and binding of the linkages, etc… independent of the RC radio.
Set to 1, it will do one test cycle, set to 2, it will do two test cycles, etc… Try that and they should be smooth as silk during that test.
Maybe @bnsgeyer knows why they do that “rachety” thing on the bench in Stabilize or Acro when you move the collective.
Edit:
I was testing different throttle curves last night with the new MODE 3 5-point smoothed throttle curve code. This is an example of a 50-70-75-80-90 throttle curve, the red line is the collective output, the yellow line is the throttle output. I thought I moved the collective pretty smooth when I went from bottom to top. And on the way down I hesitated at about the 75%, 50%, 25% and that’s why the flat parts coming back down. But the red line has all sorts of squiggles in it and that may be what’s causing this “ratchey” behavior on the bench. In flight I know it doesn’t do this.
Great to hear, I was a little worried how it would fly like that. I do believe it is time for a test flight to see how the different modes react. I currently have it set up for acro, stabilize, and position hold. Cross your fingers!
If I had to venture a guess, I would say it is due to the sample rate of the data. In looking at your logs last night, these signals are only being logged at 10hz. In the flight controller, the loop is being ran at 400hz. So that is why you don’t see it in flight. That’s why I mentioned last night that I would look at using a logging bitmask that gave the data at a higher sample rate.
So I reread the previous two messages and I guess I missed the point. When I saw Chris’s post with the plot I thought Chris was referring to is the plot and the rachety affect on it.
As for servos being ratchet on the bench I would recommend disconnecting your telemetry radio on the aircraft and observing of the servos without the RF from them. I know that telemetry radio had a big effect on my servos. I had got another cheaper brand of servo and they jittered so bad that I had to buy Futaba servos.
Just tested this and it made no effect on them. I use Xpert servos and they are very high quality.
Mine do the same thing as Chad’s. On the servo test routine they are smooth. When I move them with the cyclic they “chatter” like that. But they don’t do it when it’s flying. And mine don’t do it on the bench with the cyclic - only the collective.
Chad, I think rather than crossing fingers I would recommend staying away from Pos Hold right at first. Fly it in Stabilize, not Acro. Then pull the logs and look things over as far as vibration and IMU aliasing, and desired vs actual attitudes. Because Pos Hold is going to depend on the attitude controller working right, and historically nitro engine heli’s are quite “buzzy” and vibration-prone. Flying it in Stabilize will give you a “feel” for how it’s reacting, or if the attitude estimate drifts and you have to start fighting it due to vibration. The autopilot does not deal well with that, a human pilot can.
Just to be clear, Chad, when I fly any helicopter using the autopilot - even a fully seasoned, tuned and proven machine - I ALWAYS take off in Stabilize first to check the operation of the attitude controller. If the heli wants to drift, or you have to fight it there’s a problem and you can land right away and figure out what’s wrong with it before handing it over to the autopilot.
If the attitude controller passes, then I flip to Loiter and check the operation of the GPS, compass, navigation system, and observe how well it holds position in the wind.
Only after making those in-flight checks do I flip it to Auto and let the autopilot have 100% control of it.
Pos Hold is pretty much a 100% autopilot controlled mode that depends on everything else working right. That’s why I don’t recommend using it right away until checking out the rest of the systems to make sure it’s tuned right. You should actually check it in Altitude Hold first, before trying Pos Hold. Altitude Hold has the same handling characteristics as Stabilize with the addition of altitude holding and there can be problems with that due to excessive Z-axis vibes, improper tuning of the IM_STAB_COL’s causing a sudden collective change when switching, etc…
Thanks @ChrisOlson! I will get it up in stabilize and see what it does. If you don’t mind I’d like to post that log here and have you look at it and tell me what I need to look for. Thanks for all your help with this!
