I am attempting to use a Pixhawk for navigation and a helicopter FBL unit for Stability. I have read in several places this is possible. But after some attempts at making it work I believe I am simply misunderstanding some basic concepts. I have tried it on the older Pixhawk and the new Pixhawk 2.1. When I attempt to make it work it appears both the pixhawk and the external FBL attempt to fly the helicopter.
I appreciate any amount of help I can get. Links to videos, instructions or messaging.
Just for general info, this is Curtis YoungbIood, I used to be quite active in the RC helicopter community with a lot of experience in 3D flying, FAI and our own flight controls. I have a lot of experience setting up Multirotors, airplanes and even the Quad planes on the Pixhawk. All of these had different steps in logic but were not that difficult to implement, so I think I am just missing something in the basic logic of getting the pixhawk to work with an external FBL unit.
Any specific reason to still use the FBL controller? We are trying very hard with the latest releases (currently 3.6RC2) to bring a good experience on both Nav and Stab. Could you elaborate a bit on reasons of the FBL controller choice, if you want via PM ?
Hi Curtis! Glad to see you here. I miss your autorotation seminars. IRCHA is not like the old days anymore**.
Anyway, you do not need a downstream FBL unit. The system works fine without it. The only reason to use one is because you need a feature (like four-servo swash) that ArduPilot does not currently have. Or if you want to fly 3D aerobatics which the EKF system in ArduPilot can’t handle.
The setup is fairly simple - just turn on flybar mode, set the Rate VFF’s (feedforward) up to at least .35 and set all the rate PID’s to zero (turn off the rate controller in ArduPilot). Then do your normal tuning in the FBL unit. In Acro you now have straight-thru control to the FBL unit. In other modes the ArduPilot system provides the attitude solution, the FBL unit handles the rate control.
The CGY-750 works quite well - I have one on a helicopter. But you have to map the SBus in the FBL unit to match ArduPilot’s channel mapping (channel 3 is collective, channel 8 is throttle). I use channel 9 for governor, channel 10 for engine ignition kill.
** in some ways. In other ways it still is. Matt put piston power in that new 556 and that’s bringing some of the old timers out of the woodwork again…
Thank you for the reply. Actually I was just looking into using the latest release as well. I am happy to use whatever works. I had just seen a recent discussion where ChrisOlson had suggested to someone that using the extrernal FBL might be a quicker way to get the helicopter up and going if you already had a machine working well on the FBL unit.
Also we have a couple of helicopter projects that have non-traditional control setups that we already have working on our flight controller. So if we got the Pixhawk + FBL setup to work that might help us on several machines at once.
But to make it simple I have decided to just get a traditional FBL, 3 servo swashplate helicopter going. So either Pixhawk+FBL or just the pixhawk with new firmware is fine to start with. I will go which ever direction seems the most likley to give good results.
Thank you for the reply, I tried running all the PIDs to zero but then I could not get any control to the swashplate no matter the mode I was in. This was tested only on the bench. I could only get swashplate control if I had some value in the PIDs and then of course the pixhawk fought the external FBL. I must have just missed something in the setup.
Curtis,
That’s because you need to set the Rate VFF’s up to at least .35. That will provide the feedforward path so you have control outputs with the PID’s set to zero. And make sure to turn on flybar mode by setting H_FLYBAR_MODE to 1.
Oh, also be sure to set the swash type to H1. Most FBL units don’t want any mixing as they do their own CCPM mixing.
The Rate VFF’s are like the rate in your RC radio. The higher you set it, the higher the rate. 0.35 is usually the minimum for most FBL units.
You can also fly a FBL heli with flybar mode turned on and no downstream FBL unit. It will just be a no-gyro FBL in Acro. I have gone to this in all my heli’s without downstream FBL unit. I set up my own custom rates and expo in the RC that automatically flips in when I switch to Acro flight mode. I rather enjoy flying no-gyro, some people don’t.
Curtis another thing for setup of your FBL unit, make sure you use rate-only control in the FBL unit. Don’t use self-leveling or such features in it. ArduPilot will provide self-leveling in Stabilize and that will fight the self-leveling feature that some FBL units have. Neither one knows what the other is doing.
In normal Acro (for FBL) ArduPilot provides rate-only control like most FBL units. With flybar mode turned on ArduPilot provides direct-thru RC to output with no rate control, which flybars require.
So basically set up your FBL unit to simply replace the flybar, turn on H_FLYBAR_MODE by setting it to 1, and and it will “just work”.
To confirm, by self leveling you are not meaning the standard “heading hold” component of the PID control correct? I assuming you are referring to features like auto leveling etc… that were added to some flight controls for safety.
Curtis,
Yes. If your FBL unit is like a CGY750, no problem. But if it has one of those self-leveling features in it, that has to be turned off or it won’t work.
It’s the same on yaw. With your heli on the ground if you move your rudder without moving the heli, center the stick and the FBL unit brings the rudder back to center, you need to disable that if you want to use the rudder output from the FBL unit.
Since the ArduPilot system uses a compass heading (fused with GPS and other sensors) it will fight wind, or any other external force, to maintain that heading until you, or the autopilot, move it. Most FBL units only use gyros so it doesn’t actually know the heading. The ArduPilot system knows where it is in 3D space at all times.
I haven’t kept up with everything they’re bolting into FBL units these days, but I know some called “9-axis” (or whatever) have a mag chip. What you want is a good old rotate and hold 3-axis unit like a CGY750, or be able to set it so it does that.
Edit: further note - if your FBL unit is a stubborn one on the yaw you can use ArduPilot’s external tail gyro feature by setting H_TAIL_TYPE to 1 and just let the FBL unit handle it. And then your channel 7 can be set up for how much yaw gain you want to send to the FBL unit’s yaw controller.
Are you going to be flying a piston, or electric? We got a lot of new stuff in the 3.6 beta, but we got some special builds if you want to run the stable firmware with heli stuff in it. Including one that delays the servo output on boot so a downstream FBL unit can properly initialize its gyros. If you want that special firmware build let me know and I’ll link to it.
Initially I am setting this up on an electric helicopter using our own flight control, a TG Multi. Our flight control does need about 5 seconds for initialization.
A general question, setup on H_flybar_mode on 1 for the external FBL unit, I assume I still have to go through and setup all the servo limits, neutrals, pitch curves, etc as if the Pixhawk was flying the machine. The only change from a complete setup is the PIDs to zero and Rate VFFs at least 0.34. Otherwise the pixhawk will not know the limits during missions, stabilize etc… Is this correct?
To your point about H_TAIL_TYPE to 1. I assume this will treat it as an external tail gyro but also still “point” the yaw, such as pointing along the flight path in auto missions between waypoints. So the Pixhawk will “navigate” with the yaw but not control its basic stability.
Then you will want this firmware build. It has a 5-second delay without moving the servos at boot to the let the FBL unit initialize. We just invented this feature about a week ago. We didn’t create any new settings and just hard-wired the 5 second delay into the code. We wanted to test it to make sure that’s enough time, plus make it pretty much transparent to users that aren’t using a FBL unit so they don’t wonder why their servos don’t move for five seconds after boot. This is a v3 build for the Pixhawk2.1 or other v3 controllers. https://github.com/ChristopherOlson/ArduHeli/releases/download/v3.5.6/ArduHeli-3.5.6-v3_servo_delay.px4
Yes, all correct.
Yes, also correct.
Basically we want the outputs from the Pixhawk to mimic what comes out of your RC receiver being input to the FBL unit. The FBL unit should not know whether it is you providing control inputs, or the autopilot.
Only run the aileron, elevator and rudder outputs thru the TG Multi. Let the Pixhawk handle throttle unless you are depending on a governor function in the TG Multi. There is three throttle control modes
RC input - designed for ESC’s that have multi-speed governor.
Setpoint - designed for ESC’s with single speed governor.
Software throttle curve - designed for pistons or turbines with or without governor, or electric with (flat throttle curve) or without governor.
When you set up your receiver make sure it is set to hold last received value on the throttle channel (usually 8). If you lose RC contact and it goes to zero it will shut the heli’s engine down.
You can only autorotate a heli in Stabilize or Acro flight modes. And currently if you engage throttle hold in flight for an auto, and disengage to bail out, it runs the H_RSC_RAMP and H_RSC_RUNUP routine and won’t bring the engine back up to full power right away. We have some different spool logic that is not all done yet (we’re waiting for a couple other developers to finish their part of it). When we finish it for heli we plan on putting in a setting that will allow bypassing that ramp and runup time so auto practice can be done the normal way with throttle hold.
Just be aware of that. At the present time if you engage throttle hold in flight you’re pretty much committed to a full-down auto. And if your engine quits in flight in any altitude controlled mode the autopilot will increase pitch to try to hold altitude until you get a blade stop. So I always keep either Stabilize or Acro handy to get into an autorotation profile ASAP if flying in any altitude controlled mode. Because many times if the heli is way out there on an auto flight, without FPV you don’t even know it quit until it uses up half your headspeed.
How do you check that the cyclic control from the pixhawk is going the correct direction when using the external FBL? For example collective has a Max,Min, Mid in the H_ SERVO_Man. In this case i found the pixhawk collective was backwards from my FBL collective. I do not see a similar test for the cyclic and yaw.
Would it work to turn up the “P” gain just for initial setup to confirm the controls are responding the correct direction?
Well, the individual servo outputs of the ArduPilot system can be reversed with the SERVOx_REVERSED settings for each servo, identical to the way you might reverse a channel in your RC radio to get servos to go the right way for your particular FBL unit. But doesn’t the TG Multi have an option to reverse servos too? If it does I would leave all the servos in ArduPilot normal and do the reversing in the TG Multi.
Yaw should move with the H_SV_MAN setting. To get cyclic to move set H_SV_MAN to manual and use your RC radio stick.
You can, but it’s not needed if you got the rate VFF’s for aileron and elevator set to at least .35 That will give full servo travel.
One other thing - if you run into a situation where you can get cyclic control right, but collective is backwards, and you can’t reverse the collective in the TG Multi, you can reverse it in ArduPilot. But not with the stock 3.5 firmware. You’ll need the ArduHeli 3.5.6 build to do that and the setting is H_COL_CTL_DIR. Set it to 1 to reverse the collective direction without changing the cyclic direction.
Thank you for the reply. The concern I have is when I moved collective going through the radio my collective looked fine and moved the correct direction. I only knew the Pixhawk was not correct when I set the H_SERVO_MAN to Max and the swashplate went to low collective. So then I reversed it in the program using the H_COL_CTL_DIR and then had to reverse it in my transmitter as well. Now the collective moves the correct direction with my control and with the max setting in H_SERVO_MAN. But without some equivalent MAX control on cyclic I do not see how I can know which direction the pixhawk will give for aileron, elevator when navigating. I do see the yaw move with the H_SERVO_MAX but which yaw corresponds to MAX and which to MIN? Also how do I confirm the yaw gyro matches the control response?
Sorry for so many questions. Just trying to avoid a bad surprise when I flight test it.
my current setup is a SAB 570 helicopter, using 333Hz Swash Plate Servos (MKS) ND 550Hz Tail Servo (MKS).
The tail servo only works if I connect it to an FBL system. With a standard receiver, it does almost nothing (at least no coordinated movement commanded by my sticks).
I assume I will see the same effect using pixhawk and this tail servo…
Is it possible to fly this setup with Pixhawk or do I need to use the external FBL unit plus Pixhawk?
so far, pixhawk hardware did not arrive… so I cannot plug and play with it.
but want to make sure to start with the right setup
It should work fine. A receiver is not going to drive that tail servo, as it is likely 760uS center.
ArduPilot will drive it just fine - BUT make sure to set SERVO4_TRIM to 760, SERVO4_MIN to maybe 600, SERVO4_MAX to maybe 900 BEFORE you hook the servo up to the controller. Or it will burn the servo out. The defaults are for 1520uS centered servos.
I am not particularly fond of those hobby-grade 760uS centered servos. They run hot and are high-strung 3D equipment that does not stand up long-term in UAV helicopters. I got tired of autorotating wildly spinning heliopters due to another 760uS servo that bit the dust. A suitably fast cyclic servo works fine on the tail for a UAV machine, runs much cooler, and draws less power. A cyclic servo on tail duty normally lasts hundreds of hours in a UAV.
Keep in mind in the 3D world people think servos are really great if they get 200 flights and it still works. 200 seven minute flights is only 23 hours of flight time. I put that amount of hours on a UAV heli in less than a week, flying surveys with it.
