When in a nav mode does the Pixhawk still pass RC signals to the FBL controller in the same manner as a rx would?
I have long been interested in using a Pixhawk or the like as a companion nav computer for use with a standard FBL controller. This will definitely help get some influential users off the fence and return to using single rotors vs ridiculous heavy lift multis. I personally have a new build coming off the table soon and with what I have invested in time and manufacturing cost I’m not comfortable jumping straight to a pixhawk for the initial flight testing. Plus my pixhawk tuning skills are not nearly up to par when it comes to helis. I am much more comfortable with the flight behavior of a vbar or sk720 anyways.
I use this configuration with AC3.3.3 and a MicroBeast. Didn’t test an auto mission yet but the loiter works very well even in strong winds. I tested with speeds up to 20 m/s without any problem.
Instructions on how to tune the Pixhawk are in the comments of the blog post. Please note that only channel 1 to 8 appears to be working on the SBUS output with AC3.3.3. I’m also experiencing some kind of delay in ACRO mode, which makes the piloting in ACRO a bit less precise. I don’t feel it anymore in STAB mode.
By the way, I use a Pololu RC Mux. This way I can bypass the Pixhawk remotly if needed (never had to do it) or if I want to do an aerobatic/3D flight with my well known MicroBeast behaviour…
Thanks…I went back and re-read the diydrones post. I must have missed the first time.
So these paramter changes are for the stock firmware or the special firmware. Or is the special firmware just the patch to swap channel 3 and 6? These values effectively turn off the PID correct?
These original post alludes to special firmware so just a little confused. Have been hoping @tridge would chime in here.
@Nicolas,
Exactly correct, you need:
H_SWASH_TYPE=1H_FLYBAR_MODE=1H_TAIL_TYPE=1
You should also set RATE_P, RATEI and RATE*_D all to zero. Then set
RATE_RLL_VFF=0.4RATE_PIT_VFF=0.4RATE_YAW_VFF=0.3
they are just a starting point. You can then use the PID logging to
do fine tuning so that desired rate equals achieved rate for each axis.
We’ve found the tuning of those VFF values is not very sensitive.
We also found we needed to lower ACCEL_Z_P a bit from the default or
you can get collective oscillation in ALT_HOLD mode… A value of 0.15
works well for our Trex700 gasser.
Before we did our first flights we graphed the RC inputs against
servo outputs for the roll, pitch, yaw and collective channels to
confirm they matched exactly in ACRO mode. They did.
We had one additional complication with the skookum 540, which always
requires collective on channel 6. The ArduPilot code puts collective on
channel 3. Some FBL controllers allow the input channel mapping to be
changed (eg. BeastX allows this) but Skookum 540 doesn’t. So we are
currently using a small patch to swap channels 3 and 6 in the PX4 HAL.
That makes the SBUS chaining work with no fuss. We could instead have
had separate wires for each channel between the Pixhawk and the Skookum,
but that would make the wiring messy.
What we really need is a H_SWASH_TYPE=2 which puts collective in channel 6 and throttle on channel 3.
Cheers, Tridge
These parameters cancel the rate PIDs so you should have the outputs almost the same as the inputs in ACRO (except for yaw, see here after). The special firmware of Tridge only swap CH3 and CH6. This is not needed if you can do a custom channel assignation on your FBL.
Concerning the yaw axis, I had the following problem in ACRO : the output was proportional to the input, but not equal. I found out that the ACRO_YAW_P is not cancelled with the external gyro configuration. This lead to have the yaw input multiplied by this parameter value. If you put 1 to ACRO_YAW_P, the yaw output equals the input. The counterpart of this is that you only have something like 30°/s in STAB and other modes. I did a little patch to the Copter 3.3.3 TradHeli to counter this…
Also, with my 600 heli, I had to change the loitier controller params, the defaults were too high and lead to toilet bowl effect. I used the params you can find here : GX9 high speed tests in AUTO. There is a log on the first post where you can find the params.
One question I really am hunting for an answer to is can a downstream FBL unit be used for the navigation flight modes as well by applying the same settings to cancel the pids? I’m ultimately searching for a process where the pixhawk’s only function is as a companion waypoint navigation unit and the fbl handles core stabilization and swash mixing 100% of the time.
Much to the contrary of dev opinions I am not sold on the reliability of a pixhawk handling the work that a vbar or sk720 has dialed in terms of robust performance. Traditional heli FBL have been proven for years in harsh 3D flying and their connected control feel is paramount to my project.
It is possible : in the link I gave you, Tridge is using a Skokum 540 for the rate control. Arducopter acts as attitude and navigation control. He achieved an AUTO mission at 32m/s with spline waypoints and the logs and video looks very good…
I didn’t try an AUTO mission yet but STABILIZE, ALT HOLD and LOITER flight are very good also…