Can a large drone be flown without a flight controller?

Hi, I am developing a very large 200 lb tricopter drone (size of large station wagon) with a lot of rotational inertia. I would like to know if it is possible to fly it manually without a flight controller?

I developed a CAD model of the vehicle and it flies very well in Realflight manually without a flight controller. I have tested the vehicle by placing a narrow board under the vehicle and tried to balance it on top, and compared it with using a flight controller. The motors are at about 40% throttle and the vehicle hovers at 70% throttle. Since the center of gravity of the vehicle is much higher up into the vehicle, this test is forming an inverted pendulum. Tests have shown that using the flight controller the vehicle can be balanced on the beam, with a 1 deg in pitch ~1Hz oscillation. It can also be balanced somewhat using no flight controller, but it requires me to move the pitch stick up and down rapidly to balance it. Keep in mind there is ground effect and the inverted pendulum effects that make it more difficult to balance. Once in the air these effects will be removed and will be much easier to control. I have already programmed the transmitter/receiver so that the vehicle can be flown now without a flight controller. My question are there any other tests I can run to increase my chance of success? How would you approach testing something like this?

The reason I am considering trying this is that if possible it is always best to study an aircraft without a flight controller. Once the characteristics of the vehicle are understood, then it will be easier to adapt a flight controller to make it fly even better

Thanks.

Here is a link to see the vehicle:

Here is a link to see the vehicle being flown in Realflight without a flight controller:
https://drive.google.com/file/d/10phvcegCDk8A5cZLkGRIbp8AMSGRpjOf/view?usp=drivesdk

Here is a link to see the vehicle hovering with a flight controller:
https://drive.google.com/file/d/1csnLLtug1sz9msU4BM_flKp9pHXlquIa/view?usp=drivesdk

Here is a website to learn more about the project:
http://skychaser.se

@William_Walker larger vehicles may be able to be flown without stabilization because their unstable modes are lower frequency and can be stabilized by a human. Even the larger RC helicopters (700 size) could be flown by the pilot with no stabilization however requires a unique transmitter setup to help the pilot. More of a stick sensitivity thing. I have never done it but I know a user who did and described it to me. But I don’t remember exactly what he said because it was something I would never try.

Having said that though there are other ways to degrade the ardupilot control laws. You could use acro mode with the rate loop only and turn off the attitude control loop. Then you can adjust between feedforward if you want direct control and rate P gain if you want some stability. I think this is better than going with no stabilization.

So to add on to my previous post, acro mode can be modified with settings to provide a more manual control. I would suggest trying this in real flight simulator before using it on the actual vehicle.

Set Q_ACRO_OPTIONS to one. That will set it to use only the rate controller with no attitude correction from the attitude controller.
Set Q_A_FF_ENAB to zero.
Set your commanded max rates to something low. This is done with Q_ACRO_RP_RATE. maybe set this for 90 deg/sec.

In looking at your parameter list, it doesn’t appear that you have the acro options parameter. @iampete was the acro options included that allows using only the rate controller?

@William_Walker if this feature is not included in the Quadplane code then what I have suggested above won’t be possible.

Should be direct control in QACRO with ACRO_LOCKING 0. (on 4.2)

1 Like

@William_Walker based on @iampete post, what I was suggesting is possible. Looks like you would use ACRO_LOCKING instead. I also noticed that the roll and pitch rate scaling for the stick is done with Q_ACRO_RLL_RATE and Q_ACRO_PIT_RATE instead of Q_ACRO_RP_RATE (which isn’t an actual parameter for Quadplane).

Do you want me to continue to explain this suggested setup?

Hi Bill, this setup is getting complicated and will likely cause me as much problems as getting the PID loops to behave properly. Also it is prone to the same motor switching off and on problem we are observing. I was hoping that the vehicle could just be flown manually as it is. But if it can’t, then it is best to continue using a flight controller, since the vehicle is hovering well, provide I don’t rail the motors while doing an extreme maneuver. But I really need to solve the motor shutting off and on problem before I can trust it, since this has caused my vehicle to crash many times.

Referring to our other discussion area

you mentioned that you think this motor switching off and on behavior is due to the large gains in my PID loops. Perhaps I can just reduce the gains and see if it behaves better?

By the way, did we resolve the Integrator exceeding I_Max issue? As you recall I set I_Max=1 and the PIDP_I exceeded it a lot before the motors started to turn off and on. What should I set I_Max to?

Thanks.

It may be complicated to you but it simplifies the control laws in that it removes the attitude controller and allows you to just concentrate on the rate controller PID loop however you are in a rate command (acro mode) rather than attitude command(stabilize mode) control logic.

I don’t know how well you understand control architectures but the Quadplane in hovering flight uses the multicopter control architecture which is more of a model following design. This means that your control inputs are being shaped by a command model to prescribe the way the aircraft is to achieve the pilot request. So If you are in qacro and you displace the roll stick halfway and you have the maximum throw defined as 90 deg/s, then the pilot is requesting 45 deg/s. But it is not just a step input to the 45 deg/s. It uses the max acceleration to get to the desired roll rate. That is why I questioned your max acceleration parameters (Q_A_ACCEL_X_MAX) as they were left at the default values which are meant for small 7 lb quads, not 200 lb quadplanes. So getting the shaping parameters for the command model right is important so as you are not requesting more than the vehicle can physically do. This will slow the requests down and keep the controller from requesting alternating max and min motor output.

The stabilize mode is an attitude command mode and so your stick displacement equates to the attitude the pilot requests. If the pilot has the roll stick halfway then 50% of the max angle is requested. Thua if max angle was 30 deg then the pilot requested 30 deg but this is not a step input to the aircraft It is shaped according to the command model that uses a first order response with a time constant (Q_A_INPUT_TC). Again, using a time constant that ia achievable by the aircraft is very important to getting the desired and actual responses to match.

Yes, Pete reminded me that the correct signal to look at was not PIDP.I which you originally plotted but PIQP.I which is the pitch PID signals for Quadplane in VTOL flight. Based on you plot, it was not getting close to the Q_A_RAT_PIT_IMAX value.

@William_Walker have you tried using the Quadplane tuning wiki here? There is a lot of useful info especially in what the accel max Params should be set to based on the prop size.

Hi Bill,

I have spent the day testing the vehicle without a flight controller. The test was done indoors in a warehouse, and the vehicle was always within a few feet of the ground. It seems to work ok, but required some work to keep it horizontal. At the beginning I had problems with the vehicle turning, so I had to add washers to tilt the back motor. This eventually worked after 10 or so tries and adjustments. Here is a link to see videos of the tests. The 15th try is the most recent:

https://drive.google.com/drive/folders/1zCVCDkdcAyiqJTQVea9zdcf6C6uaSaZq

I will have to think about the results. Keep in mind ground effect is a bit tricky. Can you take a look at the tests toward the end and give me your opinion? Thanks.

Thank you for the clarification on how the control architecture works. I was not aware of this. Now it is starting to make more sense. Do you think if I fix the time constant and velocity and acceleration max parameters that this should fix my motors turning off and on, or is there something else I should do?

Thanks, William

PS. The videos are uploading now. Give it 10 min or so to upload before viewing.

I think this will help the aircraft fly better. You should really follow the guide in the wiki for tuning. It provides recommendations on certain settings for your size vehicle.

So I was looking at the pictures from your original post. How are the motors held to the metal tubes in this picture. Is the plywood glued to the metal tube?

Also I read that you were planning to make this into a manned version once you got the unmanned version working. Did you know that ardupilot has a strict policy prohibiting the use of this firmware in manned applications? You may reconsider your choice of flight controllers if you plan to use the one you develop for the unmanned in the manned application.

Hi Bill,

The two 10kW counter rotating back motors were replaced by a more powerful 17kW cont (40kW max) single motor, due to coaxial loss.





The vehicle is made of styofoam covered with 2 oz fiberglassed cloth. Plywood was used in certain areas to strengthen the structure: nacels, wing spars at CG and connecting the carbon fiber tubes supporting the back motor, wheel supports, and back motor support, which is fiberglassed to the carbon fiber supports.

Yes, I am aware of ArduPilots policy. This is just our 1st prototype which is unmanned and operated by RC. The manned vehicle will of course use something else. If I understand correctly it is possible to use PX4 which can be output from Mission Planner, or QGroundControl.

William

So with the single motor in the rear, do you plan on making it swivel and the angle actively controlled to control the yaw as is indicated in the ardupilot Tricopter motor setup guide?

Ok. Good.

I don’t know anything about PX4 and their policies. It just scares me to think you would use hobby grade controllers to control a vehicle meant for manned flight. Hopefully you understand the testing and safety requirements that you will have to meet to get this certified.

Hi Bill, Instead of tilting the back motor, Yaw is generated by the 2 front motors tilting asymmetrically. I prefer this because the front motors have to tilt anyway for forward flight. Adding a tilting mechanism in the back would add extra weight, and complexity. This is how the 1/6 scale works and it flies really well:

https://drive.google.com/file/d/1q6iPsVydYqC_2YI6IAgRftKsNPcW9C_0/view?usp=drivesdk

The back motor is fixed in place and tilted a little to compensate for the torque generated by the back motor. The front motors are counter rotating, so they cancel each other’s torque. This configuration is well known and is used in many tilt rotor VTOLs like the Convergence RC model.

Right now we are looking for funding and once we get it things will get much more professional. We will probably have a company develop our software. As you mentioned certification is the most challenging part of this work and getting the software certified needs to be done by specialists.

But until then we are just 2 guys working in a garage working with what we can get and funding the project ourselves. I have been working on this project for almost 7 years and started it in San Diego, Calif which is where I am from. I came to Sweden to build the full scale prototype almost 2 years ago with my business partner Dag Stranneby, who is a small aircraft pilot, and radio and signal processing professor at a local university. I am a physicist and RC model enthusiast, and we met when I taught signal processing and machine learning at the university 15 years ago.

William

1 Like

Years ago before the multitude of FC’s available today we built Tricopters with 3 gyro’s for control. It worked OK and could be flown having had lots of RC helicopter experience. see here: The Tricopter V2 – RCExplorer

But without a FC it was really limiting as control was mediocre at best without any angle limits. FC’s just made it a whole lot better, chalk-and-cheese actually.

I thought the whole idea of Arduopilot was that it was a public domain type of thing where people can create forks on their own, then if they turn out to have good ideas they get incorporated into the main fork?

What’s to stop any of us creating the “manned copter” fork? It was always going to happen.
I started planning a manned copter as soon as I flew my first quadcopter, and found that if I wanted stabilisation and autopilot, and lack the software skills for DIY, what choice is there, really other than arduopilot?

If anyone wants an actual pilot for their diy flying machine, look no further.

Sure. You could fork and start your own project but the ardupilot dev team would not provide any assistance for your efforts. It is against our charter to do so.

And that is a real problem with this technology, it can put this capability into the hands of people that don’t know any better. They think it is cool and it will just work and then they end up killing themselves or someone else.

I have updated the CAD model in the Realflight simulation to reflect the full scale vehicle I have built. No flight controller is used. It now uses asymmetric front motor tilt for yaw, where as the previous simulation tilted the back motor. The nacels are now longer, so the thrust from the front motors does not hit the body/wing. The part of the cockpit covering the back motor has been removed to allow the back motor to breath easier. There is only one back motor blowing thrust though the hole in the wing, whereas before there were 2 coaxial motors, producing too much coaxial loss. The real vehicle should fly very similar. It should be noted that it is a little unstable hovering in one spot. But the rotation is so slow, that it provides enough time to make control corrections. The vehicle has a lot of control authority. Forward transition is done by angeling the vehicle slightly up and giving it full throttle. Back transition is done by reducing throttle and waiting for the nose to drop and then transitioning. The throttle then needs to be increased. Turning in VTOL mode can be done using the asynchronous tilting motors, but is more effective combined using the Elevons, using back and yank. Here is link to see a video of the new simulation:

https://drive.google.com/file/d/1E9bxS2h1ZhvaTIike8joCkwvJJDoUoTz/view?usp=drivesdk

I finally got the courage to test the vehicle out of ground effect, in VTOL mode, without a flight controller using only manual control of the motors. I am using a Taranis X9D 2019 plus transmitter with FR Sky RX8R receiver. The throttle stick controls all 3 motors. The back motor also mixes the Elevator stick control. The front motors also mix the Aileron and Elevator stick. During the test the vehicle took off well, hovered for a moment, pitched forward well, and flew forward several body lengths. The vehicle started to tilt right about 10 deg, so I gave a little left roll command. Apparently it was too much and the vehicle tilted left 10 deg, at which point I started giving some right roll command. I could not stop the left roll, so then at 15 deg I started to apply full right roll. The vehicle roll up to 45 deg until the vehicle hit the ground on its left side. The wheels were completely destroyed, but the rest of the vehicle has minor damage and can easily be repaired.

The question is what happened? Why couldn’t I correct the left roll? Fortunately I fed the FRSky receiver Bus output to the Pixhawk Orange Cube flight controller which was used only to gather sensor data and receiver output data. Analysis of the flight log shows the vehicle developed a large 30 deg yaw as it flew forward, but because of my vantage point i could not see it very well. I think what happened is that because the vehicle flew skewed (rotated left by 30 deg) the right wing caught the onrushing more than the left wing and this induced a large left roll that was too much for the motors to control. Simulation tests in Realflight show that the this can be used to turn the vehicle on a dime (yaw combined with roll), as compared to using yaw by it self, which is very slow.

So to me the test shows the vehicle can be flown without a flight controller due to its large size with large rotational inertia. The crash was simply due to the vehicle not tracking straight and can be easily fixed by reducing the number of washers currently tilting the back motor clockwise a few deg. What do you think? Your comments would be appreciated? Thanks, William

Here is a link to see a video of the test flight:
https://drive.google.com/file/d/161h3PDc7_Z3c9iceEhoxLP1bT1LLOhFm/view?usp=sharing

Here is link for the log file:
https://drive.google.com/file/d/1vRYCe3Llyy5GhAzX-c0YdrwPXRtapyXY/view?usp=sharing

Here is link to see my analysis of the logs in PowerPoint:

Said the pundit, to the qualified pilot & aircraft engineer…

As an experienced pilot of both full sized and r/c aircraft, you’d be mad NOT to use some stability assistance in a full sized craft.

Add some redundancy and 2 from 3 error correction, of you want to be “sure”, manual override if you think it’ll help, but using a flight controller allows you do do those proving flights without risking your own neck.

It also makes the transition to manually piloted flight somewhat safer in my book, with an option always availlable to hit alt hold, if you find you aren’t 100% up to the piloting task.

And if you do choose an FC for any of the reasons I would, then despite the fact that none that are available to us are properly specified for full sized use, it’s got to be the one that has thousands of people constantly refining it’s performance and for which the basic code is open sourced, so you at least have a CHANCE of staying fully in control.

Acceptable risk is either judged by the individual themselves or by people like you Bill, on their behalf. When you legislate for the lowest common denominator, you get a society that is structured and only caters for the lowest common denominator, and assumes mediocrity in all. There are quite a few operating one man homebuilt quadcopters now and have been for several years. I’ve yet to read of anyone crashing one. Aviation is inherently risky, but if people didn’t take and manage risk there would be no aviation.

The original question was can a large drone be flown without a flight controller, and the answer is; " yes but only sucessfully by a skilled or rare gifted individual. For most others (including me) stab-aug at the very least is the way to go.

I’ve flown a fair range of quadcopters now including the legendarily easy to fly Silverlit X-UFO with it’s flipmaster mechanical gyro and the more manual it gets, the easier it is to stuff the airframe. His car test flight although it gave him valuable data, would very possibly have gone wildly different if he had taken off and flown it in “alt hold”, simply because of the reduced workload. Even at this point, the pixhawk in my drone is a way safer pilot than I will ever be.

There’s no way I’d want to fly a three rotor helicopter with no assistance, they are inherently unstable in all axes simultaneously. Anyone advising the poor bloke to do that, just want to seem him fail hard IMHO, or better yet, not make the attempt.

I fully understand that if someone does fly themselves in an arduino craft and it turns out to be a coding error, it could be traumatic for the coder, but someone is going to fly in an arduino craft one day if they haven’t already. (I think one early man carrying craft actually used a KKK fc!) So why not make it a proper “renegade” fork and at least let those who would misuse the FC in such a way do it in as controlled and safe a manner as is possible.

I’m sure some of the existing dev pool would find the “safety and reliability first” challenges irresistible.

Not sure who’s who in this reference but whatever. I feel at a disadvantage here as I think you know more about me than I do of you.

Yes, I am a big proponent of augmentation to help the pilot, if done properly. I am far from an expert RC pilot. I never fly in acro in heli’s… very scary.

Well, this could be a blessing or a curse. We all donate our time and have different styles of coding and testing and we are all human. I just found a bug that I caused in the heli autotune code that caused two users, luckily more experienced pilots, to have to land a helicopter while it was oscillating due to instability. Fortunately it didn’t result in any damage. My point is that we have so many devs contributing that it is more likely than not that unsafe code could make it into a stable version, and has in the past. So I don’t agree with this statement, it’s only a matter of time.

I’m not stopping you. Learn how to code and have at it.

Totally agree. I work with people everyday that do just that testing and flying aircraft.

It feels like you’re pointing a finger at me. I did recommend degrading the arducopter firmware to provide at least some stability. I definitely provided alternatives that he decided against.

Doesn’t change the fact that ardupilot developers have agreed to not enable this code to be used on manned aircraft or to be weaponized. Both of course could be done by anyone with the know how and just simply cloning the current codebase.

This has been very amusing. This really belongs under rants rather than wasting space on William’s thread.