I made some logs about a strange behaviour with Heli_Dual.
It is about of basic control allocation, so the copter is not really relevant (it’s a chinook-type built of Trex450-s with H3 swashplates and a Pixhack, arducopter 4.0.6).
In order to locate the problem all the special features were deactivated (H_DCP_YAW=0, H_YAW_SCALER=0), and the yaw axis tunable parameters were zeroed out.
So one can concentrate on the pitch inputs only. No other input is applied in the two logfiles, only pitch. No servo is reversed.
Arming, Stabilize mode. Nose is elevated two times (green ATT pitch 0=>20deg). During nose-up the front collective is lowered by the stabilisation (RC_OUT C1,C2,C3 1500=>1400). This is OK.
Positive pitch is applied, two times again (red ATT desPitch 0=>40deg)
Front collective is added (RC_OUT C1,C2,C3 1500=>1600). This is OK.
The copter is rotated by 90deg (ATT yaw 200=>280). This could be a wind gust, turbulence, small collision, or short assymetric motor torque or other major disturbance in the air.
Then the nr.2 is repeated: positive pitch is applied (red). But instead of collective increase, the swashplate is now tilted (RC_OUT C1up C2down, C3constant). This is a roll input, as it would be in ‘simple’ mode.
Then the nose is elevated again. The stabilisation in the frame coordinates is correct: the front collective is lowered.
My first tought was, that somehow the ‘simple mode’ is unintendently active. But it seems to be more complicated as the next logfile shows.
If i know well, a new user is not allowed to attach documents (the two logs and parameter files) and can paste only one picture. so i will continue in a new part soon.
Second logfile: ATC_ANG_YAW_P is set back from 0 to 4. No other change, all the ATC_RAT_YAW gains are still zero. Then and the same procedure is made as in the first log.
After the 90deg yaw rotation the pitch input now results in something really strange, see RC_OUT C1,C2,C3. This cannot be explained by a ‘simple’ mode.
And the problem does not disapear if the copter is rotated back.
Summary:
the stabilisation in frame coordinates is always OK. But the reaction to pitch/roll pilot inputs can be corrupted by some troubles with the yaw axis (turbulences or poor yaw tuning, etc).
Maybe a yaw=>pitch/roll ‘feature’ is still alive in the background. Does somebody know which one could it be and how can it be deactivated?
@perwollf Laszio,
Welcome! I am the code maintainer for traditional helicopter frame which includes the dual heli. I am not sure what you are trying to learn about the code. Stabilize mode is a very complicated mode. The aircraft is controlled in the earth frame so it you were to pitch 5 deg nose down and the yaw the aircraft, it wouldn’t yaw about the main rotor shaft. It would yaw about the earth Z axis. If you want to verify the control outputs based on pilot input, then use acro mode and zero all rate PID Params and the angle P params. Then set the rate VFF params to something like 0.1 and test each axis. That should tell you what the dual heli mixer is doing.
If you explain the purpose of your test then I might be able to help you. Unfortunately this code is very complicated but it works fine.
Dear Bill, thank you for the answer. I am surprized about ‘stabilize’ in the earth frame, even if it is mentioned in the documentation.
I never heard of a manned vehicle where the pilots pitch control inputs can result in purely roll control actuator movements, just because something on the yaw is wrong.
And even with UAV i am afraid of situations where this concept will make some failure cases only worse: corrupted pitch/yaw commands because of problems on yaw axis.
I has surely a lot of advantages, otherwise it wouldnt be in ardupilot since many-many years. But for experimenting with some new vehicles i would feel much safer in a robust mode, something between ‘acro’ and ‘stabilizing’. Some self leveling, but the desired pitch,roll, yaw sould remain as in the classical euler angle definition, in every crazy (or even crash) situation.
Maybe there was arleady some requests about such a robust mode between ‘acro’ and ‘stabilize’?
In the meantime i tested this with a conventional 450 single heli and the result is the same: after an unintended 90deg yaw motion the pilots pitch inputs are resulting in roll control movements.
This single heli is flying normal , so the concept is OK and has surely its right to exist. I dont want to put this in a question, just asking if an additonal more robust mode wolud make sense for new experiments. Acro with its RCAH would be one solution but is hard to fly…
What you have to realize is that this flight control system uses a command model which generates a target response from the pilot input and then the attitude and rate controllers drive the aircraft to the target response. What you tried to do with your experiment is an unrealistic test with a properly tuned aircraft. Acceptable yaw deviations from the model are limited so that you should never see just pure roll motion to a pitch deviation. The yaw angle P term is used to compute it and it is typically around 10 degrees. So if the yaw was to deviate more than 10 deg, the target response is dragged with the actual heading so they are never more than 10 deg from each other. I understand your concern but stabilize is very reliable.
What kind of experiment are you doing? Acro does have a auto leveling feature. You can read about it here. It is called acro trainer. Be sure to read the part of that wiki on traditional helicopters. For traditional helicopters, a virtual flybar feature was added that leaks off the attitude hold feature to make it fly more like a flybarred heli.
I really think you want to stick with stabilize but it depends on your experiment.
Regards,
Bill
Dear Bill, then i will stay in the stabilized mode. My experiment is similar to this one:
Such concepts have one major mechanical problem: yaw inputs are causing very high internal forces. In order to get yaw torque , one rotor has to tilt to the left, the other to the right. So one is fighting against the other. In single heli the rotor fights only against the aircrafts inertia when roll is applied, not against a fixed frame (let say that the tandem frame is not rolled during the yaw).
Because of this the rotor head and/or blades must be very flexible with tandem helis. With all of its disadvantage. Or one has to limit the yaw inputs, and it flies like an old elephant(in yaw). But even then, fast stabilization by the controller can lead to dynamic yaw inputs, for example dcp to yaw feed forward mixing.
Unfortunately all modern helis are really stiff, so I can imagine that a lot of cool tandem projects suffer mechanical problems because of this high internal forces. Earlier or later will something fail.
I am testing the following: the connecting bar has a very low torsional stiffness so the two frames can easely twist easily along the x. The controller is mounted in the middle, so it is not strongy effected by this motion.
With this concept very high yaw inputs are possible, and the advantage of stiff rotor heads can still be used.
In forward flight the situation is similar to single helis: Each frame rolls to the side of the backward rotating blades. In our case some yaw is needed to compensate this.
Yes I was wondering how effective yaw control was with the tandem or side by side configurations. In full scale aircraft, they allow the rotors to tilt through flapping hinges on each blade. Therefore it is much easier to tilt the thrust vector and minimize the torque on the fuselage.
Be careful in doing this. The rotor systems have frequencies where exciting them could cause the rotor system to couple with the aircraft structure. If you are familiar with ground resonance in full scale helicopters, then this is a rotor mode that you could encounter in your experiment. I once tried to build an RC V-22. My first design resulted in very large oscillations in the rotor systems in the opposite directions. The lead-lag mode of the rotor systems was coupling with the tube that connected the two rotor systems. here is a link to a post where I talk about the issue in more detail.
Surprisingly until now no strong resonance occured. It would be fatal because the rotors are overlapping and not sychronized, with only around10cm height separation. The torsion bar has a lot of damping (opened aluminum U bar with squeezed-in wood insert), this may help a bit as long the resonance doesent developed fully out. Additional the rotors have different head speeds. But all of this is only trial and error, no calculations or theory behind it…
Hello Perwolf,
I have been flying my two tandems with 2 x 1.60m and 2 x 1.80m rotors with Ardupilot for a long time without any problems.
However, I have never dealt with the diagrams on the memory card. I have set them according to the default in the wiki, and they fly.
However, if I understood correctly, your rotors are not running synchronously and have different speeds. Of course, that doesn’t work. And you have 2-blade rotors, which is more sensitive anyway. With 3-blade rotors there are actually no vibration problems.
The tube that is soft in torsion is also not good. The tilt of the rotors at yaw may only come from the blades or joints, not from the mechanics.
If I set the H_DCP_SCALER to “0”, I have no pitch deflection.
It doesn’t look so bad on the video after all. With a reasonable mechanics it will work.
Hello Holger,
good to hear about flying your tandems with Ardupilot and no problems! I suppose you use some very flexible rotorheads, maybe that one from Vario, specially for tandems?
Using the memory card is easy. If you dont want to deal with signals and diagrams, you can simply replay your flight as a video. Then you see your RC stick inputs and the aircraft reactions on it. In my case mostly the other direction: my panic reactions to the aircraft movements https://ardupilot.org/dev/docs/common-uavlogviewer.html
It works. All the ‘crazy’ things (overlapping rotors at different speeds, flexible frame, stiff DFC rotorhead) are part of the experiment. DFC would never really work with tandems… exept mine
It is not for beautiful flying but only for experimenting. Here are some pictures even if i am not really proud of it. It is just a fast experiment, everything is bolted, glued together. And i have no time for it (job + homescooling).
The aluminium tube is really flexible. In the following picture it is twisted only by the weight of the helicopter:! flexible_|666x500
My son just made a video about a short flight in the living room, but I cannot put it in here. It is an 8MB .mp4, maybe an admin can give me the permisson for posting it here.
