3689683967?profile=original

I wanted to bring attention to the work that Tridge and the rest of the CUAV team have done to demonstrate the possibility of flying a Helicopter with a standard FBL controller handling the rate control duties.  They have been testing gas powered helicopter for next round of the Outback Challenge which will require a long-range VTOL aircraft.  Helicopters are a natural target for this mission of course.

Several of the CUAV team are experienced RC helicopter pilots, but not as familiar with installing a Pixhawk on a helicopter which can be difficult, especially in the case of gas engine helis.  As such, they were more comfortable having a normal Flybarless Controller handling rate control. In this case, the Skookum Robotics 540.   Tridge has made changes to the code which allow for a pure control pass-through from the RC Rx, through the Pixhawk, and straight to the FBL controller. This pass-through occurs in Acro mode, whereby the Pixhawk running ArduCopter has no effect on the flight control, so even if the Pixhawk should have a major AHRS/EKF failure, the helicopter is still controllable. 

3689683895?profile=original

Of course, the Pixhawk is capable of controlling a Helicopter without any FBL system, and this is the most common arrangement.  But the possibility of running an FBL controller in series with the Pixhawk helps lower the barrier to entry for many existing RC Helicopter pilots.  And also offers helicopters similar failsafe-function to airplanes, where they can survive the loss of the autopilot.

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • @JB - after decades of being around refuelling race bikes, cars, planes, not to mention daily use of chainsaws, strimmers, lawnmowers, making garden fires etc, the only uncontrolled fire I've ever seen was at a firestation safety day.

    LIPOs on the other hand scare me to death due to their random and quite violent fires - I've had one already (luckily I was outside) and I've only been doing this just over a year.  Very, very, very few people use lifeo - the vast majority use lipo and as we know from the latest 'hoverboard' malarky lion is just as dangerous.

  • Lol Rob ok...

    My being ridiculous was only provoked by you saying gas was safer than lipo. I can't see it being so and I simply pointed out my position, along with a request of some facts to prove it was in fact so. Further gas storage wasn't the subject, use in RC aircraft was. The points I made were valid and videos posted to demonstrator the intentional ignition of them. (it takes a awful long time to wait until they blow up of their on accord!)

    If lipos where so "dangerous" what batteries are you using onboard your gasser to run the pixhawk? Nicds? ;-)

  • JB, you're being ridiculous.  Posting a video of a forced gasoline explosion?!  Really?

    Just about every household has gas powered implements in their garage, and therefore store gas tanks as well.  How often do you hear of gasoline fires?  Safe gasoline storage and use is so common nobody even thinks about it anymore.

    Everybody in the hobby knows about the dangers of LiPos.

    3689643641?profile=original

    The problem with LiPos is the risk is so insidious.  You never hear about gas cans spontaneously exploding.  LiPos do.  Most smart people store their LiPos outside the house, and charge in a bunker. 

    Gasoline fires can be put out with a standard fire extinguisher, even water.  LiPo fires cannot be extinguished, period.  They have to be left to burn themselves out.  Best case, you can smother them with sand.

    Has anybody ever made a "safe gasoline refueling box"?

    http://diydrones.com/profiles/blogs/safe-lipo-battery-charging-box-...

  • Traditional heli's are definitely underrepresented in current commercial UAV offerings given their performance benefits, but I'd be curious to know what sort of TBOs (Time Between Overhaul) regular operators are getting? It's been almost a decade since I had an Ergo 30 (RC only), but a persistent memory has been the amount of maintenance and tweaking required to keep it in the air and performing nicely.

    Guy, this is a good question, and I don't think a good answer exists yet. I can say for myself, I had about 10 flight hours on my mapping heli with no need for maintenance. I typically hear extreme acro pilots doing 100's of flights (5 minutes each) between major maintenance.  Servos can last for at least 1000 flights before being replaced out of caution.

    The Zenoah engines that I use are commercial-grade service engines typically use in chainsaws or weed trimmers, and last a long time with minimal care. 

    Logically, a simple multirotor should last longer. Though I have heard of many professional operators replacing motor bearings are regular intervals (like 10 flights?!) which seems a bit excessive.  How long to highly stressed ESC's last?  No idea.  

    Airplanes, are also simpler.  But subject to constant crash-landings, do the airframes last 100 flights?  I know one operator who budgets for 20 flights per airframe.

    We just don't have good engineering data on anything.  It's all guesses and anecdotes.

  • Heli autopilots have always had pass-through modes.  It's almost a must for someone who flies helis manually as they need to be able to revert quickly to a comfortable mode if the autopilot does something unexpected.  It's something that fixed-wing pilots and those who only fly more automated systems often don't get because the margin for error with a heli is so much less.

    It is kind of interesting what "manual" flight control has become.  If you don't like what your "full" autopilot is doing you can switch to a pass through mode which uses a simpler autopilot (OK, stabilization system).  The days of "manual" control being the ability to only move control surfaces based on sight and sound are pretty much gone.

    Just to be clear, it is possible to have manual control with a standard Pixhawk-only setup.  Acro mode operates similarly to any FBL controller.

    The difference, and the reason why Andrew has worked on this, is the ease of tuning, familiarity and vibration resistance tolerance of a regular FBL controller. One of the difficulties using Pixhawk in a helicopter, particularly a gas powered one, is the vibration isolation of the Pixhawk, and the problems that causes when you get it wrong.  If this is not done well, the EKF blows up, and all control is lost (even in Acro).  

    I've been flying Arducopter on helis for 5 years, and have never used an FBL controller. I had one light crash last summer due to the EKF blowing up while I intentionally tried to provoke it with aggressive Acro, but the issue was fixed before 3.3 was released.  I have had the EKF get unhealthy (again with aggressive Acro) but does not cause a crash anymore.  I haven't had a crash due to vibration on the Pixhawk in a long time. 

  • @Tridge, thank you for all the advices. I'll try it as soon as I can with a TREX600E DFC and a Microbeast, I'll post some results here. Do you know if anything changed compared to the last stable release o nthe SBUS output side? I'll test it anyway...

    Thank you for all :-)

  • Developer

    @Nicolas, just to be clear, we are flying master, not the stable release of heli. We haven't tested the SBUS chaining to a FBL with the stable release.

  • Developer

    @Nicolas,

    Exactly correct, you need:

    • H_SWASH_TYPE=1
    • H_FLYBAR_MODE=1
    • H_TAIL_TYPE=1

    You should also set RATE_*_P, RATE_*_I and RATE_*_D all to zero. Then set

    • RATE_RLL_VFF=0.4
    • RATE_PIT_VFF=0.4
    • RATE_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

  • Great news, exactly what I and another user asked about some time ago : http://ardupilot.com/forum/viewtopic.php?f=66&t=7521&sid=1f... . I'm really happy that this could be done :-) And by the way, big respect to the whole team for all the fantastic job done...

    @Tridge, can you confirm the following mixing parameters ? 

    • Swash Type (H_SWASH_TYPE) = 1
    • Flybar Mode Selector (H_FLYBAR_MODE) = 1
    • Tail Type (H_TAIL_TYPE) = 1

    By the way, what about the SBUS channel-function routing order? Is it the same than the routing on the PWM outputs?

  • Developer

    @Ultrafuge, the only advantage of the SBUS chaining is wiring simplicity, which consequently also makes vibration isolation a bit easier. It is perfectly OK to chain the Pixhawk to the Skookum with separate wires for each input.

    The key to it really is that if ACRO mode is properly configured then it is a true pass-thru to the Skookum. That means you can flick to ACRO at any time and be flying your heli just like you would without the Pixhawk. The same thing works with other flybarless controllers.

    It is also trivial to setup the rate gains in ArduPilot, as you just set P, I and D to zero. Then set VFF to the gain corresponding to how sensitive the FBL is to stick inputs. A value of around 0.5 or so has worked well for us on all axes.

This reply was deleted.