Hi Mark,
I have made a test of the vehicle on the bench, vehicle pivoted at Pitch CG, with INS_Log_Bat_mask=1. I balanced the vehicle for a while at about 30% throttle. Below is the log file:
There is definitely some noise at the 150Hz in the IMU Gyro x. This is clearly wrapping around and appearing as low freq noise that is getting picked up at the ~1Hz vehicle oscillation frequency. This will clearly get worse at hover which is at 70% throttle. This is probably what is causing the set point drift I am observing. What is your opinion?
Yes, I thought I did and that is what I wrote above. It is easy enough to check. Just load the log file in MP and read the parameters. But I sent you a picture of X Gyro FFT and it clearly shows there are signals at 150Hz and beyond.which are aliasing to lower freq that are very likely getting into the system oscillation frequency.and exciting the oscilator.
Maybe the batch logging feature is broken in version 4.0.9
Try flashing the latest stable version and see if you get ISBH and ISBD records in the log.
In any case, the gyro and accelerometer sample rate for the orange cube is >= 1KHz, so the Nyquist frequency will be a minimum of 500Hz
Also, it’s the gyro rate which is critical for angular rate stabilization, and Nyquist for the gyros is >= 1KHz.
I tested the vehicle with the old software (plan 4.0.9) which yielded an good flight before. The vehicle seemed to lift off well, stabalized nicely, but something happened and the vehicle crashed. Can you look at the log file and see what happened? Was it an oscillation in pitch, operator error, or something else?
At this point, I’d recommend that you enlist the aid of a skilled test pilot.
My guess is that you have marginal control authority at hover throttle, and none below that, which makes it very difficult to achieve a stable hover.
your gains are still really far too high, your machine is all over the place with the throttle fluctuating wildly, your gains are something like i would put on a 1000mm hex not a 15ft long car.
Blue = Throttle
Red= Pitch
Green = Desired Pitch (Elev stick)
Yel = Font Right motor
Mustard = Back motor
There is ~1 sec delay in Elev to Vehicle pitch probably due to large rotational inertia of vehicle
There is a 1/4 sec delay between Front and Back motor signals - so large Elev stick and throttle changes can cause pitch changes.
So from my understanding so far, the vehicle flew fine until I made a sudden throttle change reacting to a 1deg pitch fluctuation (probably setpoint drift). The large throttle change caused the delay in the motor signals, causing the vehicle to pitch down even more. Simply making less radical stick and throttle commands will enable to vehicle to fly much more stable.
Does anyone know why their would be a 1/4 sec delay between the front and back motor signals? Can this be improved?
thats not the problem, the problem is your gains, you keep looking for a problem that doesn’t exist. it was never flying fine… you have blamed the pid controller, you have blamed ardupilot, you have blamed thrust scaling, you have blamed the gyro, you have blamed the filtering, but you never listened to what I said in the very first post LOWER THE GAINS!
set them to
Q_A_RAT_PIT_P: 0.3
Q_A_RAT_RLL_P: 0.3
Q_A_RAT_YAW_P: 0.4
Q_A_RAT_PIT_I: 0.15
Q_A_RAT_RLL_I: 0.15
Because your machine is so heavy with large spinning propellers it has a lot of inertia and gyroscopic stabilisation just from its weight and the propellers spinning, so it doesn’t take a lot to stabilize it.
The red arrows show the front motor signals arriving first followed by the back motor signal. Since the thrust is decreasing, the front motors reduce thrust first causing the vehicle to pitch forward (seen in red Pitch signal)
The green arrows show again the front motor signals arriving first followed by the back motors. Since the thrust is increasing, the front motors increase thrust first causing the vehicle pitch up (seen in red Pitch signal)
So this clearly shows that large changes in motor signals are causing the vehicle to pitch, but not small changes.
Because your PIDs are so high the machine is massively overcorrecting causing the oscillations that you are seeing, on a smaller machine it would be oscillating at a much faster rate but because you have the inertia and gyroscopic effect from your propellers its essentially getting damped down to 1hz
what your seeing as delays is actually the pid controller going from one extreme to the other.
Pitch pivot bench test confirms huge changes in pitch (up to ~5 deg) with changes in throttle (Throttle max ~30% limited by bench test), even if thrust changes are done gradually. Gradual thrust changes in flight are intuitively compensated with elevator stick commands. But rapid changes in thrust produce huge changes in pitch that will surprise a pilot and this was the reason for the crash. Here is the log file of the test, Pitch: P=1.0, I = 0.02 (origional PID valuse us in last flight test)
It appears that because we are using different motor/ESC/props for the front and back motors, the Ardupilot firmware is not able to change the thrust equally for both motor types, for changes in throttle. This probably has to do with the fact that we cannot linearize the Throttle vs thrust curve for both types motor systems. Ardupilot is not setup to handle our motor configuration. To fix this problem, the Ardupilot software will probably have to be changed. What do you think? Does everyone agree with my analysis? Does anyone have any other ideas?
Increase the I gain to 0.3, it should help it level faster. was this log on a test stand or a hover?
its very difficult to see what its doing when you are constantly throttling up and down. try and keep the sticks still so I can see what the flight controller is doing vs the inputs your giving it, all we want it to do is hover without shaking, nothing more, once we can get it to do then we can move forward.
Comparing the logs its an improvement, they are tracking the throttle input much closer.
the lines are smoother, you don’t have as extreme movements in the motor outputs.
Increase Q_A_RAT_RLL_D and Q_A_RAT_PIT_D to 0.05 it should help stop it overshooting because your machine is so heavy there is a lot of mass to slow down.
it also looks like your test stand is not level so it’s constantly trying to correct the roll.
I am testing the vehicle on the bench. The wheels front wheels are currently damaged from the last flight. Also,.I am.apprehensive to test it again with this pitching with thrust problem.
Regarding the bench test log Wich I just posted, I typically place a wooden board under the vehicles CG balance point and fire up the motors and see how well it balances on the wooden board. This is how I tuned the PID values orrigionally. Here is a picture of the pivot board I use:
you are not going to get accurate results using your bench testing. you need to hover test it, it doesn’t have to be far off the ground, just a foot or 2 is enough. All we want is for it to hover without shaking nothing more, then we can look at pitch instabilities. The problem is your looking at this all as the same problem when you actually have several problems that need to be dealt with one at a time. there is no point worrying about pitch instabilities when its incapable of even hovering.
In the last test I posted, I was specifically testing the induced pitch with throttle changes. That is why you see the throttle change so much. This test clearly shows the pitch changing radically with throttle changes. I tested both with the old orrigional PID values used in the flight test I posted yesterday and the values you suggested. Both are clearly causing huge changes in pitch with changes in throttle.
You can see from the flight test that there is serious ground effect until the vehicle is at least a yard high. Testing it in hover is not a good idea until the cause of this pitch change with throttle is corrected.
