Putting my head into the damn wall with this aircraft. I’ve tried plane, with Q-plane/tail sitter, and currently trying to hammer the copter firmware but getting nowhere. It’s a bicopter but vanes under for control not moving the motors themselves. I can get roll control with the motors but pitch/yaw sometimes works, or only one vane will move. Really frustrating. Also, since it’s setup as a tail sitting do I need to mount the cube on its edge, or do I “trick” the cube during calibration to make it think it’s sitting on its tail while it’s actually sitting level. I’m so confused and frustrated with this build since there seams to be almost NO documentation for bi-copter. ANY help would be greatly appreciated! @RandyMackay
Hello there! I am now building a technically similar vehicle, so let’s suffer together!
This evening I have tried the Quadplane configuration, and it even managed to arm few times. However, similar to you, I did not like the experience of pretending that it is actually a special plane, and for some reason AHRS behaved in a very unstable way. (And yes, it even tasted my blood, which is the first vehicle that did it).
Tomorrow I will be testing the bicopter part of the Copter firmware (FRAME_CLASS = 10). Despite that it is supposed to have tilted rotors, I believe we may have some positive experience using flaps as well.
Three important things to note:
-
The direction of propeller rotation is different for Copter (the right one is clockwise) and for Quadplane (the right one is counter-clockwise). This is for good reasons actually, since these choices simplify coordinated turns for the default flying modes (for Quadplane it is the plane-like flying). However, this made me somewhat frustrated when I was thinking, for some reason, that Quadplane is the only way to go.
-
The center of mass of a flapped vehicle (like ours, but also for coaxial copters which I also build) shall be sufficiently high above the flaps! Otherwise the lever is too small and the control authority is very weak. Your battery shall be put way higher, and in particular above the flight controller. Tiltrotors have similar, but even more convoluted problems.
-
It is important to note that the forces which the flaps apply are just a fraction of the thrust. Hence, if you apply thrust gently to raise the vehicle just above the ground like you do with a quadcopter, it has very little attitude control and is quite likely to crash. You have to push it hard (which does not simplify test flights, I know). This also seems to apply to all flapped vehicles and tiltrotors, although the latter might do something with that by using extremely aggressive tilting at small thrust.
While the former point is a (reasonable though) peculiarity of Ardupilot, two latter points are fundamental properties of the vehicle design, and the firmware cannot really cope with that.
That was a violent RUD at the first attempt to takeoff, apparently for the lack of structural strength… Hope for better luck (and better design) next time 
Well, that’s a shame but I’m not sure I have seen a Bicopter fly with good stability. It’s kind of the Balance Bot of Copter.
I think I will nevertheless try at least one more time since the way it broke does not seem to be fundamentally related to bicopters in particular. A better frame, made of carefully designed carbon parts, will hopefully tolerate more tests.
I build a bicopter for experiment, maybe you can change the distance between Aileron and propeller longer. please check my video https://youtu.be/b6kmu4EyTxA?si=oqmbkr-7XrUzbu-l
. In my another experiment ,even Aileron
eron is horizontal , bicopter is controllable with enough yaw torque. I am building hybrid VTOL,this experiment is for tilt structures under hovering maybe you are interested in the hybrid you could check my YouTube other videos.
Since that post I have rebuilt that craft two times, the second time in carbon fiber, then performed (but not completed) some tuning, then I had to move to another country - so this bicopter is now attracting attention of customers in a small drone shop, I believe.
What you are saying is (almost) right, increasing the distance between the lift center point on a flap and (the horizontal axis passing through) the center of gravity will increase pitch authority. This does not apply to yaw authority, where the force arm is the distance between the (roughly) center of the flap and the center of the vehicle (that is the vertical axis passing through the center of gravity).
I wonder why in your design the normal position of flaps is perpendicular to the airflow, this seems counter-productive, and you seem to be unable to control pitch properly.
thank you for your reply. Your bicopter relies on flap as the primary control surface in all scenarios, so your yaw tuning is more difficult. Because the flap perpendicular to the horizontal plane will produce very large wind resistance when cruising. So my suggestion to you is to lengthen the distance from the flap to the rotor. After watching your two videos below, I think you can reduce the area of the flap while lengthening the length of the moment arm.
However, my tilt aileron is parallel to the horizontal plane on the cruise. The primary surface of cruise is elevon, and the tilt aileron is only used as the backup control surface for pitch and yaw in cruise mode, in case elevon fails. When the primary surface can stabilize the aircraft’s level, the tilt aileron only acts as a wing to provide cruise lift. In VTOL mode, it only serves as the primary surface to provide torque to maintain aircraft hovering. The bicopter is part of my aircraft’s VTOL, the other part is a fully functional fixed wing with elevons.
if you are interested in hybrid VTOL, maybe we could have a shot together. here is the render animation for VTOL .Because the computer performance is too low, the rendering effect is not so gorgeous. Please do not mind.
I am not sure I am building anything like that anytime soon (e.g. definitely not before next year). My research time in flying things is now completely booked with three different single-axis copters (singlecopters and coaxcopters), and my real life will require most of my time.
Yaw tuning was not quite difficult, and from 2024 I can say that it ever had problems mostly because I did not turn the YAW_FLTE off: the error filter is relevant when the yaw axis is controlled in a multicopter way, but not if like that. Some idea for how it may affect the yaw on flapped things is in this video:
On the bicopter, pitch was actually the main problem. Increasing the distance could be possible - not the distance between a propeller and a flap, of course, but rather the distance between a CoG and a flap, which can be easier by mounting the battery higher or using a bigger battery. But it seems that there were also some problems in the control code: the frame code is in AP_MotorsTailsitter.cpp, and this code is largely for working with Plane, which manages output scaling with throttle by itself. As a result, servo outputs are not scaled correctly in the bicopter mode, and whenever you have throttle down - which you would often do when flying FPV in manual modes - you are essentially screwed.
For your design, I’ve got the idea, mostly, but you still need to have some pitch authority in the VTOL mode, which with your current servo maxima you don’t seem to have.
EDIT: Well, not like that: you have some pitch authority when moving flaps around the horizontal position, but you lose efficiency here - and if you only can move flaps from the vertical position to the horizontal position, then you cannot apply pitch in one of the directions. Theoretically, you can balance your CoG in such a way that the “neutral pitch” is non-vertical, but this position changes with throttle, so it would be nightmare to tune.
Probably, setting the limits further apart so that the servo goes closer to ± 90 degrees rather than the standard ± 45 may combine the benefits of both schemes in the same assembly, but it might require some support from the code as well (e.g. VTOL is allowed -45 to +45 degrees, whereas the wing is allowed 0 to 100 degrees, or something like that).
I realized that there are two reasons why the mono copter is more likely to crash when taking off:
1.The ground effect is too strong for the copter. This can be verified by suspending the bottom of the copter. For example: laying a net on the bottom, or providing a take-off bracket like the Space-X Falcon rocket, but additional auxiliary devices will eliminate the advantages of the mono copter’s compact size;
2.flap cannot provide an accurate pid maintenance level for mono copter. Ardupilot’s algorithm cannot be optimized for a certain type in order to be compatible with different vehicles. It may be a good idea to rewrite the pid algorithm. I am not good at algorithm programming, so I cannot provide support for you. .
You mentioned raising the battery installation height, but I don’t think so. The tailsitter’s sensitivity to the center of gravity is already difficult to control, and moving the center of gravity and lift farther away makes it even harder to control.
No matter what your design or my design, the fundamental reason is that the pid control algorithm is not dedicated. That’s why I asked in the AP discord R&D group if anyone would be willing to build together. You mentioned that the problem of insufficient pitch torque was misled by my animation, because the animation was simple. My design is derived from omniplane and tailsitter. The original omniplane tail rotor is similar to your mono copter. The rotor blows the elevator and rudder to generate torque to control the yaw and pitch.
When my aircraft switches modes, the push rotor and elevon are jointly controlled with the RIM fan and tilt aileron. As you said, this is a huge challenge for pid tuning, so I published the design in the hope that there will be more Big teams work together.
Maybe you can also try RIM fan. I am very optimistic about the prospects of RIM fan in aviation. However, I feel that your 3D printer cannot produce a RIM fan with sufficient strength, which may require a CNC machine.
Sorry, but the more I read your posts, the more I see that, in attempts to give advice, you do not understand what I am saying, what the challenges of my machines actually are (or were), and maybe some laws of physics as well. You seem to throw in random ideas and pretend that they are correct, but you provide no support for them, and in some cases (like with control algorithms) you don’t have any idea for how things work (as you claim), but still behave very confidently.
There are of course fundamental issues with PID control, and better control may be achieved using specialized model-based algorithms. However, either of my machines is far away from hitting the limits of what is possible with PIDs, and with regards to PID control I don’t see more problems with flaps than with motors - assuming one controls forces, like Ardupilot normally does, and not just servo outputs. It is exactly why Ardupilot has separate code for different frames, and not just mixer tables like Betaflight - so that the right things can be controlled. At some places there are known problems, but this does not mean these problems extend beyond these points.
Good luck with your project anyway.