V-22 Osprey Project - Prototype 1

-

"Two helicopters on a stick"

For my first prototype, I want to attach two of the mCPX BL helicopter frames to a central boom to test the control system in a hover. Essentially, two helicopters on a stick.  Upon examination of the stock mCPX BL frame, there is not a good way to attach the plastic frame to any cross support. I would have to design my own.

I took the measurements from the stock frame and started sketching them up in Fusion360. After a few test prints to confirm the dimensional accuracy, I created a way to attach the frames to a 15mm square dowel.


I’m using a Flip32+AIO FC board (https://www.readytoflyquads.com/flip32-aio) that I had in stock. It’s a Naze clone, and already quite old as FCs go, but it should provide enough functionality for this build.

The stock mCPX BL controller has a built-in ESC for the brushless motor, but I will have to use different ESCs since I’m not using the stock control board. I happened to have 3 12-amp ESCs in my stash that should do nicely. They are not the smallest form factor, but should do fine for this prototype. For now I’ve been testing with an Arduino Mega board, but it’s likely I’ll switch to a smaller form factor Arduino for the final craft.
The linear micro servos with the mCPX BL have a JST-SH connector on them. These are very tiny and don’t fit with the standard Dupont 2.54mm servo connections. I’ve removed the JST-SH connector and soldered on my own Dupont connections.


The real V-22 has counter-rotating proprotors with the left rotor turning clockwise and the right rotor turning counter-clockwise (as viewed from above in hover mode). The mCPX BL rotor is setup for clockwise rotation, so no changes are needed in the control setup for the left rotor. The right rotor, however, has some interesting issues:
  1. The motor can be reversed simply by swapping two of the three leads. It’s using a standard brushless DC motor.
  2. The rotor blades use a symmetrical airfoil so they won’t care which way they turn.
  3. The rotor head cannot be flipped on the mCPX BL. The linkages from the swashplate to the blade grips have a 90-degree right-hand twist to them that won’t fit if the blade grips are reversed (upside down).
This leads to an interesting problem. On nearly all helicopters, the control inputs are done from the front of the blade 90 degrees in front of the direction of rotation. This is due to gyroscopic precession (http://www.copters.com/aero/gyro.html). Essentially, the input of a rotating mass (gyro) will have an effect 90 degrees later. Therefore, to pitch a helicopter forward additional lift is given to the blade as it passes the 3 o’clock position. The lift actually occurs behind (90 degrees later on a clockwise rotating rotor), causing the helicopter to pitch forward.

With the right rotor of my prototype turning counter-clockwise and the blade inputs coming from the rear of the blade (90 degrees behind), the controls are a bit weird! For starters, I knew that the collective inputs would be reversed (up is now down), and I thought that all other inputs would similarly be reversed from normal, but they aren’t. Because I’m controlling the blades from the rear and the blade is rotating in the opposite direction, cyclic inputs remain the same as the left rotor.






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

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...
Read more

Whereabouts Clock: New Clock Mechanism

-
Image
 When I made the first mechanism of the Whereabouts Clock I utilized sail winch servos to get a motion that was at least 360 degrees.  Most RC servos are limited to about 180 degrees before they hit a physical limit.  I always wanted to create a clock with motors that weren't limited in the number of rotations, such as a stepper motor. However, stepper motors don't retain positional accuracy after a power loss.  The motor drivers only know "left" or "right" and a number of steps.  If the motor is moved, or power is lost, it has no idea where the motors are any longer.  In most control systems using stepper motors there are limit switches that are triggered to "home" the motors to a known position. Also, the Arduino Uno is limited in the number of IO pins.  Most stepper motor control requires at least 4 pins and additional lines for motor enable, micro switches for positioning, etc. A while back I purchased an Arduino Mega and a six-pack of 28BYJ48 ...
Read more