Can a large drone be flown without a flight controller?

@William_Walker I am sorry to see that you had a crash landing but glad it was relatively minor damage. I took the liberty of conducting my own analysis on your data. In order to get a better picture of the elevator and aileron control inputs being made by the motors, I calculated them from the esc data. it is pretty rudimentary but I think it paints a clear picture of the cause high roll attitude and why you weren’t able to control it. I assumed that the front two motors combined thrust matches the thrust of the rear motor in a hover. thus the calculation for the elevator control is.
elevator = (average(front left, front right) - rear) / 1020
aileron control was calculated using the front motors only
aileron = (front left - front right) / 1020
throttle was calculated from the average of all three motors
throttle = average(front left, front right, rear) / 1020

Here is a plot of my estimated control inputs and the pitch and roll attitude

You can see that I noted when there was max up elevator input which was somewhat limited (only achieved 0.8) by the throttle because the front motors were at max thrust. And since the front motors were at max thrust, there was no way they could provide any roll control. So the left roll input made at 37.5 seconds to arrest and correct the right roll created a left roll rate that continued because a correcting right roll moment could not be made due to the front motors being at max thrust.

The fact that the aircraft requires large thrust changes in the motors to correct for rather small attitude changes and rates leads me to believe the control power in the pitch axis is too small. I also think that you would be best to have some help from a flight controller in stabilizing the vehicle. If you look at the plot and it is pretty evident that the pitch attitude and elevator control are 180 deg out of phase with each other. This means that at the frequency you were moving the control (which is pretty low) the aircraft couldn’t keep up with your inputs.

Just my 2 cents based on what I’m seeing in the data.

Hope this is useful.
Regards,
Bill

Wow Bill, this helps a lot! We will really have to think about what you have shown. We could never have gotten this data using a flight controller since the motors would have shut off as soon as the motors railed, as has happen so many times in past tests. This test was really necessary and the more I look at the data, the more it is telling me about the aircraft and it requirements and performance. Tests with a flight controller added a lot of complexity, and introduced another layer of behavior that was difficult to separate from the actual vehicle behavior. Although it cost me a crash, I think it was really worth it. Now we will have to really think about how we will test the vehicle next time. But to me, the test showed that the vehicle is stable without a flight controller. What happened would have happened even with a flight controller. As I have mentioned before, we will certainly use a flight controller eventually because it will make the transitions smoother and enable the vehicle to be autonomous. But at this point in the project, the flight controller was getting in the way of understanding the real performance of the prototype and its behavior.

By the way, here is the Tiranis X9D Plus 2019 Mixer setup I used to control the vehicle:

Inputs:

Rud 100 Rud
Ele 100 Ele
Thr 100 Thr
Ail 100 Ail

Mixer:

Ch1 100 Thr - Back motor
+=100 Ele
Ch2 100 Thr - Front Right Motor
+= -100 Ele
+= -100 Ail
Ch3 100 Thr - Front Left Motor
+= -100 Ele
+= 100 Ail
… + more for front motor tilt, and wheel steering servos
I also used Special functions to create a DisArm/Arm switch

Since the back motor seems to have more power and is not railing, perhaps a useful improvement would be to use only the back motor for Pitch control, and use the front motors only for Roll control. This can be achieved by eliminating the Ele commands in Ch2 and Ch3. This could fix the problem, but the pitch command would be slower reacting, but I think this would be ok.

Here is your Elevator Band which limits Roll control superimpose with the motor signals. Note the Back motor signal is not railed in this region.

I have reconstructed the Throttle, Elevator, and Aileron control signals in a different way and I think it is more accurate. I generated the equations by solving the 3 unknowns (Thr, Ele, Ail) from the 3 Equations:
BM = Thr + Ele
RM=Thr - Ele - Ail
LM= Thr - Ele + Ail

After some algebra, the solutions are:
Thr = BM/2 + RM/4 + LM/4
Ele = BM/2 - RM/4 - LM/4
Ail = LM/2 - RM/2

Plugging the solution into the above equations show that these solutions are correct. Here are the plots of these signals superimposed with the motor signals:

In general I see the problem is that the motors are railing and this can cause a problem like what happened, and perhaps removing the Elevator stick control of the front motors will improve things. But in this case I don’t think it explains why I could not stop the roll in this last test. If you look at the Ail control signal you can see I pulsed the Ail stick left several times to stop a slight right Roll. Then I stopped pulsing the Ail stick as the vehicle reacted and rolled right. When the roll was at 10 deg to the left I started applying some right Ail stick control. But since this did not stop it, I then applied full right Ail stick control. The motors were not railed when I started the right Ail stick input. So I think something else was going on.

I still suspect that the 30 deg Yaw (due to the back motor not being at the correct angle to cancel its torque), caused the right wing of the vehicle to get more lift than the left wing and this created a large torque that made it difficult for the motors to stop. I will present a back of the envelop calculation that will attempt to show that the forward speed generated a force on the right wing that is about the opposing thrust of one front motor, which is the condition when full right Ail is applied.

Above are is the acceleration in the X direction as seen by the IMU in the FC. We can use this to do a back of the envelope calculation to determine the approximate velocity of the vehicle, and then use the lift eq to determin an aprox force on the right wing and compare it to the force of one front motor which is all that is on when full roll command is applied: The velocity would be the Area under the acceleration curve since a=dv/dt, or v=Int(a dt). From the above plot we can assume (a) has an average of 1 sec over period of 4 sec. So the velocity = 4m/s (9mph). Using the Lift equation of a wing: L=1/2 p Cl A v^2. Assume p=1.225kg/m^3, Cl=1.0 (for AG19 Airfoil at 7 deg alfa), A= 1/4 area of vehicle = 1/4(11.15 m^2 )=2.8m^2. So L= 1/2 x 1.225 x 1 x 2.8 x 4^2 = 27.4kg (60 lbs). The thrust force of one front motor is max 80 lbs. This back of the envelop calculation shows the force of a front motor is just a little larger (25%) than needed to correct a lifting force under one side of a wing as the vehicle slips (twists such that one wing is forward and other is back).

Cl info on our AG19 airfoil:

Summarizing: The above calculation based on the IMU acceleration shows that the vehicle flew forward at about 9 mph when the vehicle rolled uncontrollably to the left. The resultant force under the forward wing (due to a large slip) is about the same as the max force of the motor which can correct the roll. This is back of the envelope evidence that the lose in roll control was due to the vehicle yawing a lot as it flew forward, and the wing tip caught the resultant air stream and flipped the vehicle. If the vehicle had not yawed so much as it did, the force on both wings would have been the same and the vehicle would not have developed a strong roll other than what was commanded.

I have a lot of experience flying gliders on cliff slopes as a kid and this effect is well known. Flying on a cliff typically involves the wind airstream to be at an angle with respect to the gliders flight path. If one turns into the cliff, the wind, blowing into the cliff, can radially roll the vehicle and cause you to crash into the cliff. It is always best to turn away from the cliff and into the wind, and put a little down elevator to ensure the wing tip on the wind side dips down and keeps the wing from catching the wing and flipping the vehicle.

I still don’t understand this. So you are saying when you were using the arducopter firmware that as soon as full thrust was requested from the ESC that the motor would shut off. That sounds like a set up problem but I don’t know enough about multicopter setup to help.

Completely disagree. It will require a highly skilled RC pilot to fly that aircraft for any amount of time. Based on what I am seeing in the response after the input, the phase lag is substantial. You really need to consider using the arducopter firmware to help at some level. It may at least allow you to fly with less phase lag in a degraded version of acro mode.

This equation looks to be correct but the aileron in the graphs appears to be inverted (i.e. + left rather than + right). It looks like that is the way you intended looking at the plot legend. Any reason why?

I doubt that. You already have pitch control power problems. Removing the front motors from pitch control will effectively cut your control power in half. Bad idea.

What were the winds that day? I think that the motors did have an effect but it was delayed because of the effectiveness of the motors on roll response. Right now I have concerns about pitch and roll control power.

I’m not so sure about this analysis. I’m skeptical that the “wing” had much to do with this especially saying it was asymmetric. There is such a small moment arm for both the wing and the motors. This concerns me.

I find it hard to believe that in normal operations of this vehicle that you wouldn’t encounter a similar situation in hovering and maneuvering in a low airspeed environment. If the control system cannot arrest roll rate that developed in your short flight then I think you would encounter a similar situation in the routine operation of the vehicle in real flight conditions (winds, urban canyons…).

William, I believe you really need to step back and better evaluate the control authority in the pitch and roll axes, as well as the power margin in the vertical axis. Keeping the hover thrust mid range in the esc control will provide more controllability with hitting limits in the pitch and roll axes. Just my 2 cents. Good luck!

During many of my test flights soon after the motors rail. The motor signals start to oscillate wildly off and on and then stop, which has caused the vehicle to crash many times. I have asked the community several times for a solution, but know one has been able to help. Ref the following link for the discussions on this problem and for pictures
of the motors signals oscilating wildly and then stoping:

Until the problem of the flight controller behaving badly when the motors rails is solved, it is too dangerous to use. This is why I am trying to fly
the vehicle without a flight controller. Once the vehicle is working and it’s flight behavior is better understood, I will try again to integrate flight controller.

What you call phase lag to me is just time delay due to the huge rotational inertia of the vehicle. From the log pictures we can see the time delay for Elev to Pitch changes is about 1sec. And the time delay for Aileron to Roll changes is about 4 times faster. As long as one anticipates for this delay, the vehicle can be flown easily in the flight sim, and during my last test I felt I had complete control up until the point that it stoped reacting to right Aileron stick command.

You are right. I just plotted it this way so as to not have so many lines crossing.

Removing pitch control from the front motors will just slow down the effect of Elevator stick control. Because of the tremendous rotational inertia of the vehicle it is very sluggish to changes. The Elev stick controll actually felt overly responsive. There is currently a 1 sec delay between Elevator stick control and vehicle pitch. Removing pitch control from the front motors will just slow it down to about 2 sec. I think as long as one anticipates the delay, it can be flown.

It was a very calm day with 2m/s (4.5 mph) wind. We have tested the vehicle in windier condition perhaps double that speed and the vehicle did not seem affected.

There is clear evidence in the log pictures that indicate that aierodynamic forces were affecting the vehicle as it accelerated forward with it’s body skewed 30 to the forward movement.

  1. The Pitch curve shows that the pitch mirrored the Elevator stick command when it lifted off and hovered. But as it moved forward, the vehicle did not react very much to up Elevator stick command. This is because as the vehicle moved forward, the resultant airstream pushed the nose of the vehicle down.

  2. The Roll curve shows that the vehicle was level until it started moving forward. Then it rolled 10 deg right. This was probably due to the right wing skewed forward catching the airstream and pushing it down more compared the the left wing that was further back. This would induce a right roll.

  3. The slope of the Roll curve gets steeper as the vehicle rolled left, even well after the left Aileron command, and even after applying full left Aileron stick command. This is evidence that the on rushing airstream got under the right wing, due to the vehicle being skewed left by 30 deg, and rolled the vehicle.

You may be right, we will have to test more to see how it behaves in winds and gusts. But the manned vehicle will be heavier, at least double the weight, which will make it lass sensitive to winds and gusts.

In the simulator you can see that the vehicle starts getting tossed around a little with 10

well there have been studies for piloted aircraft that show 250 milliseconds of time delay will cause a pilot to get into Pilot Induced Oscillations (phase between pilot input and aircraft attitude is 180 deg) which can result in loss of control. IMHO, there are many things here that are stacked against you. First you have non-linear thrust from the motors because you control motor rpm with your sticks which is the square root of thrust they will produce. so the moments produced on the aircraft are not linear with your stick inputs. Second, you are near the motor limits when making multiple axis inputs. Last you are dealing with significant lag in the vehicle response.

What validation have you done to show that the sim is even close to predicting the response of your aircraft? Did you perform some validation of a smaller model with the sim model? Then you could at least have some confidence when scaling up that you understand the dynamics. There has got to be a lot of unusual aerodynamics happening with your body design. Things that simple wing lift theory can’t predict.

I know that I seem to be very negative but I just want you to rethink your way forward.

Yes this is a very unique vehicle. Have you ever tried using arducopter on a scaled down version of this design. There are huge benefits of learning about the code and how to tune on a smaller vehicle with similar thrust to weight and dynamic scaling. Plus much less costly. you could look at how it would perform with smaller inertias and then larger inertias. It would give you a sense of how to tune the PIDs as the inertia gets bigger.

Good luck. I hope you are able to figure out how to get it flying.

Hi Bill, I have really appreciated your comments and they have pushed me to think deeper about the issues. So thank you! I found a video which discusses what I think happened during the last test. Refer to 5:30 - 6:50 min into the video. It suggests that as we moved forward and body twisted, it entered a Slide configuration which is stable and it felt stable during the test, but as soon as rolled the vehicle left, it entered a Skid condition which caused the vehicle to roll over. Refer specifically to 5:30 - 6:50 min into video below:

I have modified my simulation so that only the Elevator stick controls the back motor, and only the Aileron stick controls the front motor. It seems to work as I thought. When it pitches, the pivot point is about front motors, whereas before is was about the CG. So the back end of the vehicle goes up and down with pitch and the front motors do not change height with pitch control. The sim also shows the pitch is now a little slower. But the vehicle is clearly very flyable when you maneuver it slowly. Here is a link to see a video demo of this:

https://drive.google.com/file/d/1noyKJrnTEVa4VLKV_BeYLyOxP9O5oe_Q/view?usp=sharing

I have already built a 1/6 scale version of the vehicle that uses a Pixfalcon flight controller running ardupilot and it flies very well. Getting it to work was very easy and I had no problems tuning it. Here is a link to see a short video demo of these early tests:

https://vimeo.com/489938796/f6bc2a48b7

I have also since tested the 1/6 scale model in RealFlight and it flew about the same. Realflight is not perfect and for instance does not simulate the vacuum issue we have in the back due to the back motor thrust going under the side panels. It does not model the complicated physics of the hole in the back. So there will be differences, that is why we are building and testing real prototypes.

Thanks again for your help and comments.

William

Can you post a log from a flight of the 1/6 model after it was tuned?

And a log that includes hovering an low speed flight

Here is test I just ran on the 1/6 Scale model. Unfortunately it is in bad condition due all the crashes it has had. As you will see a wheel fell off on take off. But for your purposes this probably does not matter. The model works for limited simple demos. In the test I simply flew it around in VTOL mode in the windless warehouse, which is a little small for the turning radius of the vehicle.

Log file of test:
https://drive.google.com/file/d/1YGzamV8KVKKFqnWEcG5uCTTYwKxyDS_9/view?usp=sharing

Video of test:
https://drive.google.com/file/d/17JJQo84Qp7efxxJlYZWVkPJu5LmZSv-o/view?usp=sharing

Here are detailed pictures of the 1/6 scale model:
https://drive.google.com/drive/folders/1j68z1Qh_AZvRhpnr3g798ylBluGNtuC0

I used the following on the model:

  • Built using foam board and hotglue
  • Tiranis X9D Plus 2019 Transmitter
  • FRSky RX8R receiver
  • 433MHz mini telemetry receiver
  • 7 x Hitec HS5055MG micro servo
  • 3 x EMax RS2225-2205 2300KV Race motors
  • 2 x 5045 BNR couter rotating props for front motors
  • 5149 Gemfan triblade prop for back motor
  • 2 x Tattu 4S 1300mAh XT60 conn 75C lipo batteries

Hi all. I have made progress with the testing of the Sky Chaser full scale prototype without a flight controller. It seems to be working, but I would like to get your opinion. As you may recall I chose to remove the flight controller because it was causing the motors to shut off in mid flight. I have tested the full scale vehicle in Realflight 9.5 and it seems to fly quite well without a flight controller since the vehicle is so large and has large rotational inertia, thus giving the pilot time to stabilize the vehicle. The only problem is that there is a 1 second delay. But again the flight simulator shows that this is not a problem once one gets used to it. Here is a link to see the flight simulation:

https://drive.google.com/file/d/1LcJQWlslJxcqzgwmRZYQ8s5He7Yb4fz1/view?usp=sharing

Testing has gone slow since the vehicle seems to not be trimmed out to fly straight. In our first test the vehicle took off and stabalized ok. But started yawing left and rolling right. When it flew forward, it entered a Skid condition, where the oncoming airstream got under the right side of the wing and almost flipped the vehicle over when I tried to correct for the right roll. Here is a link to see a video of the the test flight:

https://drive.google.com/file/d/161h3PDc7_Z3c9iceEhoxLP1bT1LLOhFm/view?usp=sharing

Although I did not use a Flight Controller to stabilize the vehicle. I did use one to record the TX stick inputs (Throt, Ail, Elev, Rud) and the resultant vehicle reactions (Pitch, Roll, Yaw). Here is link to see these signals during the flight:

We took some washers out from the left side of the back motor to make it tilt less, and reduce the left Yaw, and we gave some left Aileron trim and tried it again last week on a grass field. The vehicle took off very well with out a Skirt (used to previously back motor thrust escaping under the side panels, thus creating a vacuum) and it flew quite stable for about 100 m. The vehicle still Yawed ~16 deg during the flight, but the Ail trim must have been too much since pulses of right Ail control were needed to fly level. When I got to the end of the field, I tried to give the vehicle a slight amount of left ail to see if I could turn it. But the vehicle rolled left a lot more than I expected, so I decide to land the vehicle quickly because I was getting very near a ditch and a road. Here is link to see the flight:

https://drive.google.com/file/d/1LTt6YRxX7uRqZrZJWKk5fNPrJcutDGnn/view?usp=sharing

Although I did not use a Flight Controller to stabilize the vehicle. I did use one to record the TX stick inputs (Throt, Ail, Elev, Rud) and the resultant vehicle reactions (Pitch, Roll, Yaw). Here is link to see the results:

https://drive.google.com/file/d/1N1e255hM4cKyZlBiuFDqDY9fxJOD_1Z2/view?usp=sharing

To me everything seems to be ok. The vehicle seems to be responding well to Pitch and Roll commands. But Yaw control has not been tested yet. My plan is to Take out a few more washers on the left side of the back motor to correct for the left Yaw and to reduce the left Ail trim in the transmitter to correct for the left Roll. I will then try to fly in a large circle around me on a large grass field, and use the Rudder and Ail to weave about this circular pattern to test their effectiveness.

Your comment would be appreciated. Thanks,

William

P.S. I should mention that Bill Geyer helped me develop a SITL model for the full scale vehicle for Realflight 9.5. It seems to work ok, but not nearly as well and as smooth as flying it without a flight controller. I hesitate to use it because the flight controller has stopped the motors repeatedly during numerous test flights due to the motor signals railing. Here is a link to see one of the tests where the flight controller stopped the motors in mid flight:

https://drive.google.com/file/d/1gxa5mDEFPype01eP6R1W1ZBdAjq6iy_z/view?usp=sharing

Log file:
https://drive.google.com/file/d/1kSqEx0E3emf8R_CD-Wx1iPFjBJELHhlx/view?usp=sharing

Bill changed some of the acceleration and angular acceleration parameters in the SITL model to reflect those expected in the full scale model. But it is not clear if this will fix the problem and I don’t want to use it to test the vehicle until it is flying better. Currently the vehicle hovers at 70% throttle and this does not give much headroom for the extreme maneuvers often encountered during initial testing. Once the vehicle is flying better, I will reconnect the flight controller and try it again because we eventually want the vehicle to be able to fly autonomously.

Hi William, Glad to hear that you were able to do more testing. However, IMHO I really think you are going about this wrong. You are accepting more risk by attempting to continue this flight test program without a flight controller. You have a lot of money tied up in this and there is a very likely chance that you will crash this because of the significant delays in the aircraft response. It would be best if you figured out how to use the flight controller to at least get some stabilization and help you fly it.

Unless there has been other flights that you are not discussing, I think you are moving way too quickly toward forward flight. How much hovering flight have you done to look at the control margins and vehicle behavior? Why haven’t you tested yaw control in a hover before trying to move the vehicle forward? I would think that you would want to understand the yaw controllability before doing anything else.

Good Luck! I hope you are successful.

I Bill, Thanks for your reply. I understand your apprehension but the flight controller has consistently stopped the vehicles motors in mid flight many times, and we are not convinced this has been fixed in the SITL model you helped us with, since this unwanted flight controller behavior is not seen in the simulator. We tried asking the Ardupilot programmers about this problem, but they dont understand why the code does this since it has anti-windup algorithms built into it. As I mentioned, we see the vehicle performing quite well in the flight simulator without a flight controller and after 250 hrs of flying it in the simulator, it seems very easy to fly and control. As you know many helicopters are flown without a flight controller. One second delays in control are also quite common in aircraft and pilots manage just fine. Did you look at the signals I posted of the flight? They seem to show the vehicle is responding well to my transmitter commands. One thing you will see in the signals is that the vehicle pitches forward with Rud or Ail control. This is because when Rud or Ail commands are given, the prop motors tilt, providing less thrust for lift. As the vehicle pitches down, it moves the vehicle forward. This make it difficult to test Yaw when standing still. I think the best thing to try next is to try taking off with the vehicle perpendicular to me and try flying it in a circle around me with a camera in my hat to film the test flight. Flying perpendicular will enable me to easily see the angle of the vehicle and therefore control its forward speed better. Flyng in circle requires only small amounts of Yaw or Al+Elev. Once it is flying well in a circle around me, I can then try giving it a little more Yaw or Ail+Elv to get it to weave in and out as it goes around in a circle. I have uploaded above the only 2 flights we have done without a flight controller. But before we began test the vehicle in the air, I pivoted the vehicle on a bearing on a wooden post connected to the ground, and was able to get it to Yaw very easily. Again, the vehicle Yaws very well but a little slow in the flight simulator. You can also turn the vehicle as a VTOL very easily and more quickly using just using Ail and Elev (bank and yank).
Thanks, William

Your vehicle is inherently completely unstable (and not just a little bit!). To rely on pilot input for manual control of all axes is a fool’s errand. You should be investigating flight controller issues rather than continuing down this path.

Traditional helicopters can be flown without stabilizing hardware/software because they have a degree of inherent stability. Multirotors absolutely do not!

I’m with Bill here, in that you seem narrowly focused on performing flights with forward velocity and turn rate control when you haven’t even truly solved a stable hover yet.

Solve the motor cutout issue and/or find a flight controller that behaves well with your motor controllers first. You seem to have proven thus far that gyro stabilization should be an easy task for a well behaved controller.

1 Like

Hi Yuri,
Did you look at the last flight and flight signals at the end of my post? The vehicle hovered and then flew about 100m before I ran out of field. Why do you say it is very unstable, when the vehicle seems to be responding well to control inputs? Did you see the flight simulation in the first part of my post? The vehicle flies completly under control and can transition from VTOL mode to Airplane mode without difficulty.

Because the vehicle is so large, it’s large rotational inertia slows the vehicles rotational responce, giving time for the operator to make the needed stability corrections. This is not possible in a small model because it’s small rotational inertia makes the vehicles rotational responce to fast for an operator to make the needed stability corrections. So they need a flight controller which is much faster and can stablalize the vehicle.

You continue to solicit feedback and then argue against every valid point made in response. Good luck.