I want to make a V-22 Osprey drone… WITH THE SAME FLIGHT CONTROL physics as the real V-22.
That means:
CYCLIC:
-LATERAL cyclic in HOVER for roll.
-LONGITUDINAL cyclic in hover for pitch.
-DIFFERENTIAL LONGITUDINAL cyc lic in hover for yaw.
All cyclic phasing out as the vector comes forward.
AERO FLIGHT CONTROLS:
In forward flight, the physical ailerons should auto-level, elevator should damp out pitch rates, and rudders should damp out yaw rates.
So I need a board with:
-Attitude knowledge to auto-level the ship
-Attitude-RATE knowledge to damp out rates on the ship
-It needs to listen to my RadioMater TX16 transmitter… I don’t need auto-flight, I need easy-flight as I fly it.
-Running Aurdupilot, of course, to send commands to the 6 cyclic servos (3 per rotor head of course) and 4 flight control servos (2 aileron servos and 1 each elevator and rudder servo).
Goal is to use an APPRENTICE airframe as the ship (I like how it flies), with the rotor-heads built into nacelles attached to each wing-tip.
I’m just getting started, and am very very comfortable deciding what signals go where, and what sort of rate-damping and attitude-holding I want, and writing code accordingly… but I don’t yes know the entry-points to do that in the ardupilot world, either the software or hardware (all my work to date has been in X-Plane)
@Yuri_Rage thanks for calling my attention to this.
@AustinMeyer Very interesting project. Definitely near and dear to my heart as I tried doing this almost 20 years ago. Of course the technology was quite different then.
The V-22 actually does a little of both Differential collective pitch and lateral cyclic for the roll axis in VTOL mode. I think you should just use differential collective pitch as it has more control authority than lateral cyclic.
Do you plan to use an interconnecting drive shaft? The V-22 has one to allow for one engine inoperative flight and autorotation (however it can’t autorotate too well as the disk loading is really high). You may choose to not have one as it will greatly simplify the design and the electric engines are very reliable so you shouldn’t have any issues with single engine operations.
This model has a styrofoam wing? I’m not sure if that will be strong enough, especially if you plan to have the motor and then the frame, all of the servos, and rotor head. I think that you are talking at least 3 pounds for each nacelle. For the scale size, using the apprentice 1.5m wing, you are looking at a 600 size heli for a scale rotor blade length. You want to make sure that you use the heli gears and shaft for the size blades you intend to use so they are strong enough.
So to answer the question in your topic title, I would chose any board with an H7 processor that has at least 10 servo outputs which would be
2 outputs for each rotor head (don’t need lateral cyclic)
1 output for elevator
1 output for rudder
2 outputs for flapperons (you’ll want to deflect the ailerons down in VTOL mode)
1 output for ESC control (buy ESCs with governors so you can use just one output)
1 output for nacelle tilt
The reason for the H7 processor is that it will have good growth potential as the code is quite large and some of the older processors are starting to see limitations in their performance.
The more challenging part of this project would be the code. Currently, as far as I know, neither plane or copter support a V-22 like airframe with helicopter mechanics. The closest thing you could use would be a quadplane but it doesn’t support helicopter mechanics. You might be able to pull the helicopter swashplate library into plane but that is a tall order. the only other idea would be to slightly modify the quadplane that supports bicopter and tilting. Then use an H1 swashplate (you would have a mechanical mixer that would allow you to use servos for collective pitch and longitudinal cyclic). That might be the quickest and easiest way to get you in the air.
OK I’ve read your comments carefully. Regarding mass, control logic, flaperons, cross-shafting, etc, I’ve already coded and flown all of this in X-Plane so that is all done and tested in the sim: I’ve got my design and already coded my algos directly inside of X-Plane.
But I’m still overwhelmed on hardware: I understand the H7 processor is what I want… but… I kind of need to know about the whole autopilot hardware board here… like… do I want a pixhawk 4? or 6? Or cube? Or both? And which color cube? And why do we have a cube that sticks onto the pixhawk if the pixhawk already has an IMU ands stuff? The hardware OUT definitions you specified above are perfect, but I’m not clear on what autopilot board and cube (if any) I need here.
First-run: I do NOT need ANY redundancy of any sort, or even GPS for that matter. I just need the receiver to listen to my Radiomaster TX16S, and I need to know the variables in the aurdupilot code that represent the Radiomaster inputs and IMU outputs, and servo and speed controller outputs. I’ll do all the coding to connect the dots between the two (I’ve already done that in X-Plane, no fear of that part at all) if I can just get into the guts of the aurdupilot code and see what are the IMU and Radiomaster messages coming in, and servo and speed controller messages coming out, of the system. Once I see those variables and can read and write them inside the aurdupilot code, I got it. I won’t be using anyone elses’ hi-level code like ‘copter’ or ‘plane’ because that’s exactly the part I want to code myself.
Ah! I found this online!
“The orange and Yellow are built with F7 processors.”
So… you are saying go Cube Orange or Cube Yellow, right?
But why an7 cube at all?
Doesn’t the PixHawk 4 have an IMU already? So what does the cube even add, at all?
Is that the only way I can install and run Aurdupilot?
I guess: Does Ardupilot run on the Pixhawk, or the Cube?
Can I get the inputs and outputs I describe in my first reply with no Cube at all?
Goal is to minimize weight at the styrofoam model level I’m starting with… no redundancy GPS, FPV, etc, needed for my first revs.
You can use cube orange plus or CUAV Nora or a CUAV pixhawk 6x. You can look at all of the options and just make sure the processor has an H7 in it. It really depends on what you want to spend.
As far as the cube or autopilots that have a cube, they plug into a carrier board which may have an IMU but it doesn’t have the brains. That is what the cube is for.
You probably want to build your own motor mixer or you can write directly to the SRV_Channel library. Your inputs can be read from the RC_Channel library.
No. I wrote X-Plane, so I just wrote the controller natively inside that App. There will be a cool new feature in 12.20 for rotor control that will show this.
Whoa. Given that I want lo-level access here, not hi-level, do I want to SKIP ardupilot altogether and use the PX4 system instead?
If I use ArduPlane or whatever I’m just going to delete 99.9% of the code (tiresome) and boil it down to the inputs and outputs I describe… would PX4 be faster for this than Ardupilot?
I also wrote my own ground control station (based on Xavion, see it at the App store), so I don’t want to use QGroundControl or anything hi-level like that. I will ultimately (later, for rev 3 or so) want the lo-level transmissions of telemetry from the airplane to a receiver that then provides that data to the ground control station I wrote.
“PX4 is BSD, ArduPilot is GPL; this means that people modifying and then selling ardupilot are obligated to make their modifications open”
No good. This is the start of a project that could go commercial, with plenty of proprietary IP in there. I need to use PX4. PX4 also looks better for me since it is apparently smaller and more lo-level.
And I now understand that the Cube is brains of the operation, and that I want an H7, and know that I need a license that lets me branch off and mod and sell and keep new stuff secret. So it looks like I want PX4 code on a Pixhawk4 board with a Cube Orange or Yellow for the H7… right?
I don’t know much about the licensing. I do know that you will want a wing that will be rigid enough to keep from resonating with the rotor systems. Not sure how much you’ve worked with helicopter rotor systems. There are a lot of challenges here.
That is PX6 for the latest board, has you F7 processor, and and runs the PX4 which has the license that lets me do my own thing without publishing the code.
I think that’s it! Im just starting to fly RC helicopters now, and taking lessons in real helicopters now. So, I’m starting to get into rotor systems now at small and large scale. I’ve been simulating rotor systems in X-Plane since 1995 or so, and version 12.20 will have a cool new rotor model that tracks the blades all the way around for rotor-craft, if your frame-rate is high enough (or rotor EPM low enough!) to do it.
Interesting. What rotor degrees of freedom do you model? I assume you model flapping but do you model lead-lag? That is the one that can cause problems. Plus there is a lot of higher order dynamics and coupling that can cause aeroelastic issues.
OOooo! I do NOT model lead-lag! What sort of problems does that cause? I just sort of figured lead-lag all sort of cancelled out in the end when summing the rotor positions around the clock-face of the disc.
That is the origin of ground resonance in full scale helicopters. It also can cause aeroelastic issues for heli’s with more than one rotor system. Basically the rotor system center of mass oscillates in a horizontal plane about the shaft. If your supporting structure resonant frequency is not designed to stay away from the lead lag frequency, then you could see large alternating oscillations between the two rotor systems. I ran into this problem with the model scale V-22 I was trying to build years ago. With my first design, I was seeing nearly 1inch of movement at the head and couldn’t push through the frequency for fear it would break the structure.
The other challenge is building highly twisted rotor blades. I guess you might be able to find a propeller for multicopters that is big enough for your application. But then you have to make it so it can attach to your blade grip for individual pitch control.
Fascinating. Lets say the ADVANCING blade is on the RIGHT side of the disc when hovering. Then the ADVANCING blade races forwards, leading. The retreating blade is slower. It spends more time there. So I guess the CG shifts to the LEFT, where the blades spend more time? But it oscillates because hey, the blades gotta spend some time at 12/6 o clock as well, so this oscillation is at the frequency of the RPM itself? Assume a TWO BLADE system.
So now you have me interested. What kind of rotor system model do you use? Is it physics based, like a blade element model or rigid blade model? Or do you use state space models that basically models the tip path plane? I’ve seen that you had a Sikorsky helicopter and I believe you have a bell 206? How do you ensure the aircraft dynamics are model accurately? If you would rather not answer this in an open forum, feel free to PM me.
