The Picture above is of my FlameWheel 450 with one added propeller motor Unit. It is for testing the feasibility and potential value of providing 4 opposed motor propeller units for providing position control instead of copter pitch and tilt. For testing purposes the horizontal motor / ESC is controlled manually from a separate receiver channel controlled by an analog "dial" on the transmitter.
Oliver Seeler and I are both pursuing the possibility of providing a more stable multicopter platform by separating the stability control of the copter from tilt and pitch based position control. Oliver is using a Hex Flamewheel with a setup very similar to the above at the moment.
This Blog is an outgrowth of a Forum item started by Oliver under "Aircraft platforms" entitled "The Witch Gets a Broom".
First test flights are complete on both of these copters and some significant data has been learned.
On Oliver's Hex considerable thrust was required to move the copter horizontally even at a slow pace. On my copter a very small horizontal thrust (< 1/3 throttle) moved the copter smoothly at a slow walking pace and my Quad's motor thrust is tiny in comparison with Oliver's Hex.
Oliver's Hexacopter's center of gravity is considerably lower than mine due to tall landing gear, a camera mount and GoPro camera but his horizontal motor and prop unit are mounted in the same location as mine. This means that the horizontal props center of thrust is considerably further above Olvier's Hexacopters CG than is true for my Quad.
From this result we have concluded that it is very important to have the horizontal thrust line aligned closely to the copters center of gravity. Failure to do so induces tilt which the stability mode of the APM counters by applying opposing vertical thrust, doing a surprisingly good job of cancelling out the horizontal thrust. My copter as seen above does not have this problem and requires very little power to smoothly produce horizontal flight.
Also, Oliver's Hex has the prop mounted in a pusher mode and on my Quad it is mounted in tractor (puller) mode. It appears either mode can be made to work satisfactorily. I was concerned that mine in tractor mode would have the horizontal prop wash interfering with the copters downward prop wash and might induce instability. At the power levels tried so far, no negative effect is observable and transition to and from horizontal flight is very smooth and without tilt.
My conclusion from the results achieved so far is that using a horizontal propeller for position control actually does make more stable flight possible with little or no pitch or roll of the airframe. I will continue to test in this configuration at higher power settings to insure stability is not significantly degraded.
But I am also beginning work on a setup that will place prop motor units between each of a Quads 4 vertical thrust rotors.
The intention of this configuration 4 x 4 is that the 4 horizontal motors will completely take over horizontal position control.
The existing APM programming and the Vertical thrust motors will be responsible for stabilization, altitude control and the yaw or horizontal orientation of the air frame. This way only balanced symmetrical vertical thrust on the air frame is required to adjust altitude and yaw and the only asymmetrical thrust is in direct response to outside forces trying to pitch or tilt the air frame. Basically it's entire vertical thrust resources are used keeping it level and there is no purposely induced tilt or pitch as is conventionally necessary for position control.
Control for the 4 x 4 unit will necessarily be more involved as it will be desirable at a minimum to produce differential control of all 4 props using a stick. This means that zero thrust of all 4 motors would be at "stick center" position and pushing in any direction would produce differential activation on one or 2 motors in that direction producing a horizontal displacement similar to what is done now with a quad copter using the APM.
This is not achievable from a transmitter directly and requires at least translation of stick center to = zero throttle on all four motors.
My initial solution to this will to be to either use an auxiliary (in addition to the APM) Arduino processor to take normal stick input servo data and translate it to the controls for the 4 motors or I may attempt to simply incorporate the control into the APM if my programming capabilities and available resources prove adequate to the task.
The hardware part is easy, the programming part, less so.
Oliver and I very much welcome and would like to solicit your comments, thoughts and contributions on this project, and if somebody with more APM programming experience than I would like to jump in there, please feel free.
Keep in mind, the silly thing in the picture actually works and there is no perceptible air frame tilt or pitch when you use the horizontal motor to move it.
This is a new kind of aircraft which so far appears to be feasible and also that it might have some really significant advantages and capabilities.
Current Design Above.
Comments
Ahhh... Cool :)
Hi Flying Monkey, That was my original plan too, but there is a significant problem.
The problem is that the 4 motors go from zero to full with zero in the center and there is no way on a single transmitter stick to do that so it would still involve a separate control board to interpret normal pitch and roll stick input to translate to 4 motors throttles each zeroed from the stick center.
Basically two full range servo inputs to 4 throttle outputs each with a 2 to 1 multiplier.
That would give you full range proportional control and there are servo to servo controller boards that could probably handle this, but it is a considerable extra effort which would not carry over to the final configuration.
The APM effectively does that (and a lot more) for the vertical motors.
Effectively, what you suggest is what I am doing now with the single added motor and assigning an additional analog channel to the motor.
I have taken multiple test flights and so far behavior is very smooth and slight dip forward when given immediate full throttle on horizontal motor simply confirms necessity to have the horizontal motors thrust line in line with the CG of the copter.
Ideally I would like to be using a copter with the vertical motor prop units a bit further apart so that the prop wash from the horizontal thrust motors could not interact with the down thrust from the vertical motors although the tests I have performed so far do not seem to produce visible negative effects.
Thanks for the input, I may still go that route, partly because it would simplify the tuning process later but also because I would like to work with some of the simple servo to servo controllers as well.
The way I would test this, for the first test would be to remove the "computer" from the equation and see what the dynamic forces do. Like, using your apm, or any FC with auto-level and simply switching it on and not touching the pitch/roll sticks. Then have a 2nd 2.4ghz receiver controlling the four "tug boat" motors (what do they call those?) and simply having a 2nd person using their pitch/roll sticks to control those motors to move forward, rearward, left and right. Use this to see what happens, just like your experiment that showed where the thrust line to CG needed to be in the Z axis. Get it working solidly Then start integrating the position control motors into the apm control loop having a solid understand of the forces, and effects during maneuvers.
Hi Patrick, very much appreciate the response.
As I understand it on aircraft, contra rotating props were originally introduced on high speed fighters as a way of dealing with the problems that were encountered when the blade tips exceeded the speed of sound. The main reason faster fighters like the Spitfire had short straight ended props was in and attempt to keep blade tip speed to below the speed of sound which induced vibration and resulted in vibration fatigue prop tip failure.
But short propellers are intrinsically less efficient than larger diameter ones.
Contra rotating props were introduced to assist with this problem and also to counteract severe torque problems on the vertical stabilizer especially during takeoff of heavy powerful single engine military planes.
Increased efficiency was a bonus result of being able to redirect and make use of the tangential air stream produced by a single propeller. Under the circumstances where the prop diameter is fixed an additional counter rotating prop can produce up to 20 percent increased efficiency, but if the prop diameter can be increased without running into turbulence problems (usually associated with the speed of sound) simply making the prop larger will increase efficiency as well and modern aerodynamically efficient propellers designed for a specific speed range are considerably more efficient than the old symmetrical designs in any case. Basically as I understand it the largest practical diameter well designed prop on our multicopters is probably at least if not more efficient than the best designed contra rotating or (coaxial) setup.
One additional thought, coaxial / contra rotating plane props generally have a rear propeller with a very different design and pitch from the front propeller to take better advantage of the high speed and rotating air from the front one.
However, my concern wasn't related to a simple contra rotating setup, it was related to yours in particular where the two 15 degree offset motors would produce a net 30 percent offset of the prop wash streams and my consideration was that under those circumstances there might be induced interference, higher losses and potential turbulence at various speeds. The fact that this does not seem to be the case is excellent.
In fact if the losses are not very large (< 20 percent) for your setup I can see it has enormous potential. I for one would very much like to know the comparative efficiency versus an identical symmetrically coaxial X8 copter.
If I, as originally intended, simply broke the problem out to an auxillary processor, I might have been able to get by without decoupling for flying around manually in a simple stabilize mode as the stabilize is intrinsic to the APM and simple proportional control of the 4 motors with zero at stick center should have moved it around OK at low speeds and acceleration rates anyway, with the APM still maintaining stability, but horizontal position control being entirely under separate manual control.
I have decided for several practical reasons to not attempt that method and am going to use the APM for control from the start and am going to proceed as Randy suggests above.
That will decouple from the beginning. My plan is that a transmitter switch/channel will shift from normal roll and tilt flight and reassign the roll and pitch stick to proportionally controlling the 4 horizontal motors only while the Normal Stabilize and Rate functions and PIDs will continue to control roll and pitch to keep the copter level.
My hope anyway, greatly appreciate any input on execution or alternate ideas though.
Randy, thank you very much for the informative and useful input.
I will definitely look into the Simon K ESCs, I understand they are fast response in any case. Fast reverse on a brushed DC motor is easy, just reverse the polarity and apply as much current as you can without exceeding the motors or ESCs ratings. On brushless it is more complicated and even sensing speed it ispossible to apply current in a way that reinforces it continuing to go in the same direction (can't tell the difference in actual motor direction). Generally on a brushless setup you need to sense direction in addition to speed for instant reverse and I am not sure that the ESC's / Motor hall devices on our RC stuff are adequate for that. It is also a complex algorithm. Still you could have forced braking, sense stop and then apply maximum acceleration in the other direction and that would be a lot faster than what I have seen so far in cars and boats.
I have already decided to go straight to APM control of the 4 motors, since it is really the only hope of achieving integrated control and I was thinking that APM output channels 5 - 8 would be the logical ones to use since they are the ones that would be used by an Octcopter and so should be compatible with PWM.
I greatly appreciate and will definitely use the information in your last paragraph which zeros in on the functions and modifications that I need to address. nav_roll and nav_pitch seem like exactly where I need to start, this info truly saves me hours of wandering around in the code.
One of the toughest things in dealing with the APM is it's enormous sprawling software and correctly ferreting out where the actual critical thing is that needs to be changed in order to accomplish a given result.
I have been updating the Arducopter Wiki periodically and one thing I would like to do when I am more familiar with the APM software is to produce a comprehensive flow chart for it. (Right now way too daunting).
Thank you again, hope you don't mind if I you ask a question or 2 as I try to get this to work, I will try to keep it to a minimum.
Gary,
Curiously, the wiki about contra-rotating propellors mentions improved efficiency and increased noise. In practice the sound is different but the noise level is certainly not excessive, and while I'm pretty sure that the bottom props operating in 'second-hand' air do not help efficiency, there seems to be no problems at all due to interference or turbulence.
As to the decoupling, you will also need it if you want to take advantage of the additional 2 DOF. It should not be too difficult, certainly not compared to the code that performs the actual stabilization. Randy provides some pointers above. I intend to start with stabilize mode (case ROLL_PITCH_STABLE) first, though. The part of control_in below a threshold will be sent to two virtual output channels, the part above to roll/pitch, starting with a low threshold to avoid unforseen weirdness.
For my setup, I've derived a class from AP_MotorsMatrix that takes two more virtual rc channels as input and mixes them into the 8 motors.
Gary,
I think the simon k firmware has a car mode that allows you to reverse the thrust. I haven't actually tried it though and it may suffere from the same issues as you're seeing with other ESCs. Certainly an instantly reversing ESC is important for when we get to handling a motor failure on a hexacopter.
Getting arducopter to use the additional motors for position control is a bit tricky. It's possible of course though...what you need to do is divert the nav_roll and nav_pitch variables and make them output to channels 5 ~ 8 which you would attach to your extra motors.
The exact point where the nav_roll and nav_pitch are sent to the roll/pitch stabilize controllers is just below "case ROLL_PITCH_AUTO:" in the update_rollpitch_mode function here. You could write a function which takes that nav_roll and nav_pitch (which are numbers between -4500 and 4500) and translate it into a pwm and send it to the motors using something like this:
APM_RC.OutputCh(CH_5, 1500);
If anybody does know of a lightweight (<20 grams) reversible brushless ESC of at least 10 amps please post it here. There are boat and car/truck ones, but the ones I have found are all too large and incorporate heavy heat sinks.
Another issue that I have seen even with the car and boat ones is that they do not instant reverse, rather they wait till the motor comes to a stop in the initial direction then there is a short latency then they start up in the opposite direction. For copter use, instant reverse would be an important feature. For brushless motors, instant reverse can certainly be accomplished, but the ESC's / Motors we use in our hobby may not have enough sensors or smarts to actually determine motor direction and might therefore be incompatible with an instant reverse feature.
One thing mentioned in Jake's video is that this design is being used with a HobbyKing board that only incorporates gyros for keeping the platform level but does not have accelerometers which could act to counter the applied external thrust.
This is certainly an issue with my APM based system but at the slow acceleration rates I have been using so far it does not appear to be a problem.
At faster or higher performance levels it may be necessary to interact with the APM's programming to counter its accelerometer based stabilization response.
Thank You Jake, Great Video
-
1
-
2
-
3
-
4
-
5
of 5 Next