V-22 Osprey Project - Yaw Problems on Initial Flight Tests

-

I had to take a pause on the initial flight tests for a few weeks while we had a new above ground pool installed and then built a deck to match it with the existing deck and house.

During a couple of spool-up tests on the V-22, I noticed a strong yaw tendency on the model.  The yaw movement quickly turns into an out-of-control spin before I shut down the craft for safety.  I've tried correcting it with control inputs, but they're not reactive enough.  I have checked the control servos many times and verified they are working properly, so my next suspect is the rotor speeds themselves.  It is possible that one of the rotors is not spinning at the same rate as the other and inducing a yaw motion.

The ESCs that I am using are the stock Kylin-branded 40A ESCs that came with the donor helicopters.  Because I purchased the helicopters a year apart, I am not surprised that they are not exactly the same.  The capacitors and heat sinks on one are larger than the other and the startup beeps are a little different.  I've gone through the initial setup and configured them each the same, but I wanted to verify that a speed difference exists before proceeding further.

I have a laser tachometer that I've used a few times before on other projects, but this measurement would get me dangerously close to whirling death-knives that are RC rotor blades.  I started by configuring custom throttle and pitch curves to use during testing.  The throttle curve is a standard -100 to 100 linear curve and the pitch curve was flat from -100 to 100 range to hold the blade position at 0 degrees as to not push or pull the model during these spin up tests.  The rotor blades are standard RC helicopter blades with a fully-symmetric airfoil.  Next, I physically restrained the model to my mobile workbench in the garage and began testing with one ESC at a time.  I created a throttle to RPM chart for each rotor so I could build independent throttle curves if there is a difference.

As I started to spin up the first rotor on the bench, I noticed that the rotor blades were at about waist-level.  It might be a sign of me getting older and possibly wiser, but it occurred to me that a catastrophic failure of the rotor head could send carbon fiber rotor bits into squishy parts of my body.  I regrouped and grabbed the transmitter, the tachometer, and my throttle chart and huddled underneath the bench in a position where I could reach out and trigger the tach in a "safer" manner.



The test results were revealing:



I did not run the test from the full -100 to 100 throttle range as I was really only interested in achieving a head RPM of between 2500 and 3000.  As you can see from the chart above, the right rotor lags the left by about 150 RPM at any given throttle position.  Is this enough to induce the yaw that I was seeing?  I'm not sure.

Another alternative would be to purchase new ESCs that have a helicopter governor mode.  I've looked quite a bit at the Castle Creations Talon 60 and Phoenix Edge Lite 50 ESCs, but having to purchase 2 of these would set me back $150 to $200.  I'm not prepared to do that quite yet.

With this new data in hand, I created separate left and right throttle curves and reduced the output of the left throttle curve about 6 points from the right.  I will need to retest and see if the output is more closely aligned before I do another flight test.

Also, by separating the throttle outputs I no longer have enough output pins on my FrSky S8R receiver to connect everything.  I do have an S-bus to PWM decoder that I use on another airplane to get access to the additional channels.  I'll borrow this device so I don't need to use any Y-cables for the ESC and tilt servos.  This will also free up 2 ports on the S8R for something else should I need them later.

A note on the S-Bus decoder:  It narrows the output band from the stock FrSky outputs.  A -100 to 100 on the FrSky translates to approx. -80 to 80 on the Sbus output.  I've had to enable extended trims/outputs on the transmitter to re-trim the tilt servos and ESC outputs.






Comments

Post a Comment

Popular posts from this blog

V-22 Osprey Project - Design Changes for v3

-
Image
It's been a busy end of 2021, and as we start 2022 I'm getting closer to building version 3 of the Osprey wing.  The single biggest problem I've faced is the amount of backlash in the direct spur gear drive of the tilt mechanism.  It introduces some nasty instability that, left unchecked, would likely destroy the model in flight. I've investigated other tilt mechanisms, but the one I keep coming back to is the rack and pinion design that Tom Mast uses in his model at Rotormast.  His design uses a high-torque digital servo with a small pinion gear driving a rack attached to the rotor nacelle.  The servo has been modified with an external potentiometer that's driven by a gear on the translation tube to give positional feedback to the servo.  I like this design a lot because 1) It works, and his model is proof, and 2) it requires less torque from the servo and has less backlash. I ordered the pair of modified servos, potentiometer, and rack from Tom's site and star
Read more

V-22 Osprey Project - Flight Control

-
Image
Now that I have a conceptual idea of how to build a V-22 using leftover mCPX BL parts, how do I go about controlling such an aircraft? I own a Taranis X9D+, and it can control up to 32 channels using dual receivers, so that won’t be a problem. I’m sure that I can create a mixing profile in the transmitter to handle just about anything, but I’m also sure that just like any multi-rotor “drone," this thing will need some form of automatic flight stabilization. I own a few multirotor aircraft and I’m familiar with how they function. Some research into the popular flight control software (Betaflight, iNav, Cleanflight, LIbrepilot, etc.) all came up short. No one has written code for off-the-shelf flight controllers to manage a dual-swashplate aircraft. I would have to build my own. I have not delved into writing code for flight controllers, but I have built a number of Arduino projects, and some of them utilize RC inputs to control servos and motors. It occurred to me that I
Read more

Whereabouts Clock Update

-
Image
After a few months, Life360 has gone the way of Apple and locked down the API I used to get location data from the phones.  This is disappointing, but inevitable. I found on a forum for Home Assistant that the app OwnTracks might be a suitable alternative. It's a neat little app that will trigger the phone to send its location data via MQTT to a server that you specify. I had to rework the code a bit, but the new operation is as follows: OwnTracks on the phone will push location data per its configuration to the MQTT server (Docker container) The Mosquitto (MQTT Broker) container will receive the data and forward the data to its subscribers The MQTTWarn container is a subscriber and translates the received data and adds it to the MariaDB database The Apache web server hosts a Python CGI script that is checked each minute by the Arduino microcontroller.  If the data has changed, the hands are moved to the new location. The only exposed port to the Internet is TCP 1883 for MQTT
Read more