Good evening,
I have to do some kind of platform to stabilize a camera using an arduino UNO, a servo motor and an MPU6050.
I manage to make sure that the "camera" stays upright but I have to improve it thanks to the use of a PID.
I did some research on the internet to get this code, but I really do not think it is correct. I have to test the stabilization for Ki = Kd = 0, then Kp = Kd = 0 and finally Kp = Ki = 0.
I do not understand what to put as value in "setpoint"
Could you enlighten me?
thank you in advance
PS : Sorry for my english i'm french ^^
Setpoint is where you want the camera to point. Roll setpoint is almost always going to be zero. Pitch will start out at zero but may want to pitch up or down later.
PID changes the output to make the input closer to the setpoint. Making your setpoint 90 in a range of 0 to 180 is the same as making it 0 in a range of -17000 to +17000.
Since you never change setpoint, the platform should not move after it has found the setpoint, so there is no angle to be higher or lower.
and use the angle produced to generate a servo counter torque. One will find that accelermoeter angles alone are a bit shifty so one may want to calm them down by adding in a "arduino complementary filter" (do a search on those words to get a whole lot of thing do possibilities). Complementary filters worked well when I used them to help maintain a stable X/Y platform.
I would suspect torquing the servo in one degree increments may not be enough granularity so one can use micro seconds to torque the servo.
Let's say the range of the servo in uSeconds is 500 to 2500 which would give 2000uSeconds for 180 degrees, divided up and that is 11.11 uSeconds per degree. Now you can torque partial degrees.
If you want even more granularity you can use an ESP32 where clock ticks are used to torque the servo. It equates out to ~3 clock ticks = 1 uSec. Of course this granularity would be beyond the capability of the servo response range.
I, also, think that to use something more filtery, like a MahonyQuaternionUpdate on an Uno would be a bit much with all the floating point math needed.
Idahowalker:
One can take the readings from a mpu6050 accelerometer do a bit o math on the readings to get angle, like so [Complementary filters worked well when I used them to help maintain a stable X/Y platform.
I would suspect torquing the servo in one degree increments may not be enough granularity so one can use micro seconds to torque the servo.
Let's say the range of the servo in uSeconds is 500 to 2500 which would give 2000uSeconds for 180 degrees, divided up and that is 11.11 uSeconds per degree. Now you can torque partial degrees.
If you want even more granularity you can use an ESP32 where clock ticks are used to torque the servo. It equates out to ~3 clock ticks = 1 uSec. Of course this granularity would be beyond the capability of the servo response range.
I, also, think that to use something more filtery, like a MahonyQuaternionUpdate on an Uno would be a bit much with all the floating point math needed.
Okay thanks, for my angle i have
Gyr_rawX=Wire.read()<<8|Wire.read();
Gyr_rawX = (Gyr_rawX/32.8) - Gyro_raw_error_x;
Gyro_angle_x = Gyr_rawX*elapsedTime;
.
.
.
Acc_rawX=(Wire.read()<<8|Wire.read())/4096.0 ;
Acc_rawY=(Wire.read()<<8|Wire.read())/4096.0 ;
Acc_rawZ=(Wire.read()<<8|Wire.read())/4096.0 ;
Acc_angle_x = (atan((Acc_rawY)/sqrt(pow((Acc_rawX),2) + pow((Acc_rawZ),2)))*rad_to_deg) ;
Total_angle_x = 0.98 *(Total_angle_x + Gyro_angle_x) + 0.02*Acc_angle_x; //Filter
[\code]
Is this ok ? With "total_angle_x" when I test in practice it works properly.
But I do not understand how to modify the range of the servo ...
MorganS:
What's the mechanical layout? It seems like you are only testing one axis for now. Keep the other one locked and approximately vertical at all times.