Control loop deadzone

[DiseqC]

Hey,
First of all thanks for the code and for the documentation on the website.
I used it for inspiration :)

During testing I noticed a peculiarity that might be causing severe stability problems of the control loop.
The way you apply for instance
m0 = throttle + pid_pitch_out ;//+ pid_yaw_out;
directly to
update_motors(m0, m1, m2, m3);
along with
#define PITCH_PID_MIN -200.0
#define PITCH_PID_MAX 200.0

kept me thinking how your ESC behaves. Mine actually has a lower and a higher boundary (between 1060µs and 1800µs) where it actually drives the motors. Anything lower than 1060µs will result in no motor movement at all while anyhting above 1800µs will be full throttle.

Anyways, applying your control loop to my ESCs I immediately noticed that this introduces a fairly huge deadzone, in between which there can't be any motor rotation because mX (0,1,2,3) is tipping from let's say 1060µs to -1060µs. This deadzone, from a control theory point of view, introduces a non-linearity to the system which fights your goal of a stable loop.

To overcome this I simply wrote a function like update_motors(m0, m1, m2, m3); that accepts a number from 0 t0 100 (%) (float/double) and maps it to the valid microseconds range of the ESC (integer).

Maybe your ESCs behave the sameway, this would explain the "dancing" quadcopter video you show on your website.

[benripley]

Thanks DiseqC,

The problem with the dancing was due to the fact that the servo library only updates the motors at 50hz which is way too slow. I've had others mention that when they replaced this code with their own, the dancing issue is eliminated. I haven't had time to bring this project back out but I'll update this when I can test that out.

[DiseqC]

Hey Ben,

Yes this was a side issue I also had. Since I use the MKR1000, which is a pretty new arduino for Internet of Things, I was able to crank up the PWM speed to 400Hz. Things go much smoother then. I doubt however that this cures everything. The bottleneck, at least for me, is the gyroscope which can output yaw pitch and roll information at merely 100Hz. So even if I run my PID at 400Hz it won't help because the reference I let my controller rely on is to slow. I believe there could be some way to predict upcoming samples given one has more insight in the dynamics of the system. Commonly known as Kalman filtering.