This should be interesting

Tim, why are you calibrating the ESC? aren’t you going to use the governing function of the ESC? Just curious.

Now VFF, is that feed forward in the traditional sence? Not that im going to try and apply conventional FBL tuning techniques here, but I know I run mid range, to upper mid range feed forward numbers usually. I like a more direct feel when flying 3D, but that being said i guess that has no merit as it applies here as this heli is definatly not flying 3D.
I know ive seen the term VFF referenced a few times in my reading, but am drawing a blank on the definition.
My goal is certainly going to be to get the P gain as high as possible. My experiences with every other system agrees with that sentiment, whether it be a multi or a 3D heli, the P gain was the key to good flight. I always go right to the point of ossicilation, then backed it off a cpl percent.
I havent gotten that far yet, but im wondering what filters i have access to with rc3.5 i could employ to get gains up without pesky feedback ossicilations?

Last time the esc was used, it was with Spektrum gear with Set RPM Gov mode. Now i am flying with FrSky and when i tried to arm the esc it wasent seeing low throttle so i had to put it back to Linear Throttle mode and calibrate. Now it arms as it should and i can set up my headspeeds in the Castle Gov and move on.

VFF is just the parameter name. The full name is ATC_RAT_XXX_VFF where XXX is the axis. So this parameter (VFF) resides in the PID controller and takes the error between the requested rate and the actual rate and applies this gain and sends it to the mixer. It is as close as you will get to direct control[quote=“timbaconheli, post:22, topic:16800”]
I havent gotten that far yet, but im wondering what filters i have access to with rc3.5 i could employ to get gains up without pesky feedback ossicilations?

The only filter I know of in 3.5 is a first order low pass that is applied to the error signal prior to going to the PID controller. My notch implementation is pretty easy to incorporate but it also filters the error and not the gyro signal (that’s why it was easy). But as long as the freq you are trying to attenuate is greater than 5 hz, it works pretty well.

I’m not Bill, but VFF is Velocity Feedforward. It basically bypasses the rate PID loop. With a flybar where you have a built-in mechanical rate controller and you tune it by changing flybar weight or paddle pitch, you simply turn off the rate PID loops by setting everything to zero and turn up the feedforward until you get the response you want.

With FBL you will use the electronic rate controller built into Pixhawk and all the params start with ATC_RAT and apply to roll, pitch and yaw. It is very much like tuning some FBL controllers. It is just a matter of knowing where to find the settings. Make sure you use the Full Parameter List or Tree in MP or APM Planner2. Don’t use any of the Extended Tuning pages etc because those are specific to multi’s and will make settings for you in your helicopter you will be less than impressed with :slight_smile:

1 Like

That’s definitely good. Should have no problem with yaw authority.

Curious what headspeed you’re running with the 800 stretch? 1,000 - 1,100 rpm?

Historically i run 1000-1300 rpm with the 800. Had a good tail at those speeds after the blade and gear swap.

Tim, another comment on this. I have no problem with those push/pull linkages with the bellcrank. I’ve always felt they provide a nice straight link to the swash with more convenient and less packed-in arrangement of the servos. And the ratio on the bellcrank should be like 1:2.1. So you don’t need to use the crazy fast direct linked servos. I rather like that setup myself, it’s quite robust at the expense of a bit extra weight, but also really reliable. I wouldn’t even think of changing it.

The 3D rage has bred a lot of stuff in heli’s that lighter, faster, more responsive. But I don’t necessarily consider all that stuff to be good for a UAV heli.

Yeah, im really hoping the push pull setup helps reduce any feedback loops and ossicilation with the servos. When i fly 3D with my other 800 that has direct to swash links, i often think about how much punishment those poor servos take with no leverage in between. :confused:

The push/pull provides a redundant link to the bellcrank. And the bellcranks are hefty with good bearings in them where the bellcrank shaft goes thru. I think it’s a really heavy duty system. I think you’ll find it easy to tune with Ardu.

So, later tonight im going to have a go at finishing up the heli setup, ive been wondering about something. With Pixhawk, is there a parameter or place to teach it your geometry? Ive read through quite a bit of material and havent seen it referenced yet. Every FBL system ive ever set up has a step involved to teach the unit your head geometry, and if the numbers come back wrong, thats where you can move balls to a different hole or move links in or out on the servo horn to adjust it to the FBL’s liking.
Its funny as ive heard Pixhawk and Copter referred to as “the rabbit hole” on a few occasions, and at the moment thats totally what it feels like…
Ive had many a drone run away or committ suicide, really hoping nothing like that happens here… i remember when a Q500 4K i have decided to beat itself off the side of my house last summer for no apparent reason. Landed on the table in front of me doing the chicken dance until the props stripped clean…

No, there is no way to do that with Pixhawk/ArduCopter. What I recommend is that the manual for most heli’s will have recommended setup for extreme 3D and another for sport. Use the sport setup mechanically for a UAV heli.

Another hint, Tim, is that when you do your head setup look at the H_COL_MID and H_COL_MAX values that it takes to have 0 to10 degrees of collective pitch at each one respectively. If you have 200 pwm between those values, Pixhawk/ArduCopter should be fairly easy to tune. If you have less than that you have a higher mechanical rate and the heli will be more twitchy. If you have more than that the heli will be more sluggish and easier to tune.

Since you are building a camera ship I would recommend going with a slow mechanical rate, if possible, and use tweaked up P gains to stabilize it. Having twitchiness and fast handling with a camera ship is not desirable. Here is a vid clip of a 600 hovering in 15-20 mph wind, flown by a Pixhawk with AC3.4.6. It is so rock stable don’t need a gimbal on the camera. The camera is hard-mounted on the right landing gear leg and gets totally jello-free video (GoPro H3). This is a flybar, of course for me, but flip it into Acro and it will still do snap rolls at 500 degrees/sec and totally blow the EKF right into a parallel universe.

I was looking through your parameters and you have .17 listed for ATC_RAT_YAW_I, the highest value I can input is .12.

Are you using the exended tuning page in MP? You should be able to enter anything you want in the Full Parameter List. Don’t use the Extended Tuning or Heli page.

I was not in the full parameter section of MP. That would explain it. Btw, i’m noticing the tail servo moves quite slowly when I deflect the stick. Much slower than the swash servos. Much different behavior than i’m used to. Also, is there anywhere to input servo specs like frequency? or does it just default to a set rate like 200hz?

Refresh rate on the servos is 125Hz, and that should be fine for any digital servos I know of. And yes, in Stabilize flight mode on the bench the tail servo will be quite slow and gentle, and the swash servos should move quite snappy. That’s pretty normal. You’ll have plenty of yaw rate in flight if you care to use it at full stick deflection.

The servos i have installed are rated for 333hz, im assuming no issues with running at 125hz on the swash and specifically the tail? Historically in my experience the tail especially likes a faster servo, is that just not the case in this application since the system wont be doing any hard manuvers? That being said, ive had a tail that ossicilated slowly in a hover that was completely resolved with a faster, higher frequency tail servo.
So i adjusted that parameter in full parameter list. After changing it to the number specified, i get a green bix and it say the “parameter is out of range”?
Good to hear about the tail servo reaponse on the bench, it just seemed quite sluggish.
Also regarding the tail, usually i pick the heli up by hand and slide the tail left and right to check for proper gyro correction. When i do this with the pixhawk, the blade dont seems to actively compensate?
Also with compensation, the swash compensates correctly in the roll axis, but the pitch axis is not acting right, doesent compensate in the opposite direction. Ive gone through the calibration and all seemed good?
Thanks for the help it is appreciated,

Well, yeah. But the control loop in ArduPilot doesn’t run any faster than that. So having a higher servo refresh rate is not necessary. That is hard-coded into the firmware.

Yeah, you’re going to see that in MP. MP does a lot of hand-holding and I prefer APM Planner2, which lets you do stuff without complaining about it. Have to keep in mind it’s built for the multi-rotor masses and us heli pilots have to put up with some of that stuff. It might complain about it, but it should let you set it for a heli anyway.

Yes, when you do the hand rock n roll test, and yaw it side to side, it should react like any FBL controller in attitude mode. The quicker you yaw the tail, the quicker you should see the servo react. I like to watch the servo arm itself because the blades don’t normally move much unless you really put the twist to it.

I assume you set up the head according to Rob’s video, which still applies to 3.5. Now, if I understand correctly, when you roll the heli you get proper direction roll counter-response. But if you pitch it you totally reversed? If you move the swash with the sticks, is it normal?

There is a setup step you may have missed in the radio cal. And that is that all the green bars move in the direction of the stick except pitch. Pitch normally has to be reversed in your radio so the green bar moves opposite the stick. Now, if you did the head setup without having the pitch direction set properly, you didn’t enter the correct direction for the servos. So the autopilot is moving the servos the direction you told it, but it moves the correct direction with the stick.

This is my guess as to what happened. So if that’s the case reverse the pitch in your radio to get the opposite direction in the radio cal screen. Then you’ll have to reverse the servo directions to be right and the autopilot should be happy.

As far as my setup to date, it has all been seat of my pants. Havent watched Robs videos yet, just done some reading. I should probably look them up.
Now i know for sure every green bar matches the sticks, so with that logic you are 100% correct, this is likely what is going on as pitch is not reversed in my Horus. I had to reverse a couple servos in the MP to get proper operation, but if i reverse pitch in the radio, uncheck reverse in the MP then the pitch bar should move opposite and give the results you mention and hopefully correct the swash in the right direction.
Thanks for the info on the controller rate. As it only runs at 125hz, am i wasting fast servos on the system?

Firstly, no you are not wasting fast servos on the system. I use 333’s and can’t tell any difference.

Here is the docs on radio cal

Here is Rob’s video on head setup. You’ll definitely want to watch this. Seat of the pants is not going to work, unfortunately