Hello everyone, I’d like to ask the experts here for some advice. My dual-motor coaxial rotorcraft keeps tipping over during takeoff; I’ve tried adjusting various parameters but haven’t seen any improvement. Could you please take a look and see if there’s an issue with my parameter settings? I’ve uploaded the video and logs here.
Access to your data on Google Drive needs a own user account. Please change the access rights
I’m sorry, I’m not very familiar with Google Drive yet. I’ve already changed the permissions, could you please check if it worked? I’m worried you still won’t be able to access it, so I’ve uploaded it to MEGA Drive separately.
At least your servos are inverted compared to what the craft needs.
This is clearly seen on your last video. Your first stick move is pitch forward, and your gimbal moves towards you, which acts as if you requested pitch backward. Same for roll.
This is most likely not an incorrect RC setup, since the machine does the same incorrect gimballing in the first video. At 16:13, the machine is clearly pitched backwards, but it also gimbals towards where it is going to fall, which accelerates the flip.
A quick solution would be to invert the signs in software, either by:
SERVO1_FUNCTION = 35SERVO2_FUNCTION = 36
or by:
SERVO1_REVERSED = 1SERVO2_REVERSED = 1
which in Coax do the same thing.
Your other problems might also be poor control authority both due to a small moment arm (distance between the effective gimbal center and the center of gravity) and a small gimbaling angle, but as of now this is speculation, and I may need to know more about the machine.
(As you can probably guess from my profile’s picture, I have some experience with coax copters).
Thank you very much for your reply. I feel that my orientation settings are correct, since my gimbal is installed upside down. I did try changing SERVO1_FUNCTION = 35 and SERVO2_FUNCTION = 36 to reverse the orientation, but the gimbal still tipped over during the test flight. Regarding your question about “poor control due to a smaller gimbal angle,” I don’t know how to adjust the parameters to increase the gimbal angle. I would greatly appreciate any suggestions you could give me. Thank you.
I have uploaded the logs and video of this test here, hoping that everyone can help me analyze the problem.
At least the signs are correct with 35 and 36. If you check the 14th second of the last flight video, you will see that the motor is gimbaled tip to the right, with the general force direction in red, and the correction force in blue that, when applied under the CoG, turns the machine upright - assuming it’s flying, of course.
There is a thing that your landing legs tend to get stuck in the “ground” and can even possibly prevent the machine from taking off if at an angle. Ironically, the same force that would make the machine upright makes it more difficult for the legs to disengage. Some ball-shaped smooth endpoints will probably help. Alternatively, one can take off in a sharper way, but obviously the pilot should be quite confident, which is not easy to achieve when doing it first few times.
There are few questions that may help to give a better advice:
- What is the powertrain (motor/prop/battery/ESC)?
- What is the weight of the machine?
- Where is the center of gravity? These machines are quite sensitive to how close it is compared to the vertical center line, and prefer the CoG to be higher above the ground (above the gimbal mountpoint actually) for the gimbal to have a better authority.
- What is the maximum angle the gimbal can operate at? And is this particular gimbal design something set in stone for some reason, or is it adjustable?
1 Like
Thank you very much for your reply. I have already installed the smooth parts on the landing gear.
The power system consists of:
AEO CRM2208 1600KV motor
Feiying Jialufeilong 30A ESC
8040 propeller blades
4S 2300mAh battery
The aircraft weighs 743g.
I’m not quite sure how to determine the center of gravity, so I’ll describe my setup with a picture.
I set SERVO1_MAX=2000 and SERVO1_MIN=1000, and now the gimbal’s working angle can reach about 35°. After testing, the aircraft still cannot take off. I don’t know if it’s a PID issue.
I may need to consider changing the aircraft’s structure.
You have not configured the battery sensors, so I cannot see whether the current and voltage are within accessible/sane limits. (Please do, this would make your life easier. Ideally, the current sensor should be calibrated, but with three IMUs on the flight controller you probably have a decent sensor in the set)
From what I can find over the internet - assuming I interpret this correctly, because the documentation is scarce and even AEORC themselves are not clear whether they give measurements for one propeller running or for both - the motor is kind of designed for 3S but (assuming the datasheet is for both motors running) provides barely enough thrust to lift the machine under this voltage. When working with 4S, it might have enough thrust to lift off (assuming it does not overheat) provided the battery does not sag a lot - which it obviously can do. (And you have some cosine losses too…)
35 degrees for the gimbal should give enough room for control, provided there is enough moment arm. For which I am unsure. The battery weight may be just about the same as the weight of the gimbaling system with the motors and propellers, by the looks of it, so the CoG may be just a cm or two above the gimballing point. Landing legs may take this down even further. Together, this produces almost no control authority for your gimbal.
The sufficiently good way to measure your CoG is to rotate the machine 90 degrees to the side, then to pick it by two fingers on the left and right and to find the position where it does not want to rotate. My blind guess is that it’s roughly where the “flight control system” points, or just a bit higher. Your aim is to make it as distant from the gimbal upwards as possible - only then you’ll have enough control authority.
A dirty way which may enable first flights is to raise the battery higher, perhaps by installing a carbon rod and attaching the battery to it. Yet another effective way is to make the gimballing assembly as light as possible (within structural constraints of course).
1 Like
Thank you very much for your patient guidance. I have made the adjustments you recommended, and the aircraft is now able to take off, but the flight is unstable. Consequently, I adjusted the ATC_RAT_RLL_D and ATC_RAT_PIT_D parameters:
When ATC_RAT_RLL_D and ATC_RAT_PIT_D are set to 0.0001, the aircraft cannot fly stably.
When they are set to 0.0002, flight performance improves slightly, but the motors overheat. I am unsure how to proceed with further tuning. I have provided a video and the log files here; could you please offer some advice? Thank you.
Congratulations on the first take-off and a successful landing!
The thing to know about this machine is that pitch and roll are controlled by servos, while yaw and thrust are controlled by motors - so if motors overheat, the chances that it is caused by D-terms on pitch and roll are extremely small. (Technically, not zero, there is a path via throttle mixer, but most likely it’s something else).
In your case, I believe the motors may be hot because you have a large D-term on yaw but no D-term filtering. The rule of thumb is, whenever you have a non-zero ATC_RAT_*_D for some axis, you also should have a non-zero ATC_RAT_*_FLTD. (The defaults are zero for both). You have ATC_RAT_YAW_D = 0.01 and the zero FLTD. Please set ATC_RAT_YAW_FLTD to the same 23 you have elsewhere as the first safe step. Based on the logs, the yaw D-term contributions are not exceedingly large, so you may want to leave the D value as is for now.
(The other reasons for the motors to become hot is that they work harder than designed or do not have enough cooling. Remember, you are running a motor designed for 3s with a 4s battery. So if you still have too hot motors after the changes above, this might be just it.)
The pitch and roll control is by servos. I believe by an excessive D-term you can break the servos on a machine like that. The current plots and behavior suggest to me that you have a lack of the P-term in both axes, first and foremost. I would start with setting all of the following:
ATC_RAT_PIT_PATC_RAT_PIT_IATC_RAT_RLL_PATC_RAT_RLL_I
to about 0.13 (that is, 2x of the existing value, and keeping I terms the same as P terms) and test again.
Last but not least, you have a lot of vibrations on pitch and roll, with yaw only slightly better. Depending on the IMU you are looking at, you get numbers ranging from 15-20 (quite bad) to 30-40 (unacceptable). What is more, all these vibrations seem to get into your control loop and consume a decent amount of control bandwidth. For instance, the P-contribution plots are “fat” in the peaks, they are clearly subject to all these vibrations:
Some of these vibrations might be due to the motor vibrations passed on via too large D-terms, some may be mechanical frame resonances. You need to enable some kind of noise profile logging (either batch logging (Measuring Vibration with IMU Batch Sampler — Copter documentation) or IMU raw logging (Raw IMU Logging for FFT Analysis — Copter documentation) - all FCs can do the former, the powerful ones can do the latter).
You may also want to reconsider the way the flight controller is mounted. Different flight controllers have different recommendations about that. Also, you may want to look closely on how vibrations are transmitted over your frame and over your wiring, some loose wire can occasionally introduce lots of chaos.
Search for the documentation on your ESCs for whether they can provide good RPM telemetry in some way, so that you can perform filtering based on that telemetry. If these are incapable, you will likely need to configure FFT-based filtering.
(You see, when you manage to get off the ground, all the fun actually only begins…)
Thank you very much for your patient guidance. I used the second method you suggested (raw IMU data records for FFT analysis) to collect noisy data, but I don’t seem to have found much noise. I’m wondering if my settings are incorrect. Could you please take a look? Thank you.
First, you had both batch logging and raw logging configured for use, which is not recommended for performance reasons. If the system can do raw logging, it is usually recommended to turn off batch logging.
Second, your plotting defaults are apparently a bit funny - because when I opened your log in Filter Review, it showed both pre- and post-filters, and the results were quite typical for a noise profile:
From this, I can see that there is some distinct propeller noise with harmonics (the 2nd peak and all higher peaks too), but also some other source which may be something within the frame (the 1st peak, which is a bit lower than half the 2nd peak and not so concentrated).
Also, I see that the vibration levels are much lower than in the previous test, and the propeller frequency is also a bit lower. This is either you had a good job at improving dampening and at making the machine lighter - or that you were not flying during the test. My experience with similar machines suggests it’s the latter. If so, a good idea would be to get airborne to get a better understanding of the actual noise profile, because the inertia moments of the machine on the ground are very different from the ones in the air.
But before the next flight, please fix the filters. Your notch filter is currently misconfigured, it does not do any useful job, see the figure above where the notch harmonics are plotted using vertical lines. With INS_HNTCH_REF = 0, they are essentially static notches pointing to a random place. If I remember correctly how these are configured, you may try these values:
INS_HNTCH_OPTS = 2(multi-source; supported for throttle-based notches since 4.6, should be better because of two propellers)INS_HNTCH_REF = 0.32: this is the average output throttle in the latest logINS_HNTCH_FREQ = 145: this is the approximate 2nd peak location in the latest logINS_HNTCH_BW = 50: 1/3 of the above (we use multi-source, so less than 1/2)INS_HNTCH_FM_RAT = 0.5, so that it can continue filtering when descending
But you’ll likely get better results from using an FFT-based notch (INS_HNTCH_MODE = 4), again, this needs to be configured correctly together with the entire FFT subsystem.
1 Like