I am new around here and found the search for topics quite confusing so i did the best i could to find out if this topic has already been covered and i am sorry if i´m repeating something already discussed.
I´ve being building a HexaCopter for about a year and already tested every aspect and "piece" of the puzzle and all parts of the code that seemed blury for me in the past. Some still are, but so far i´ve managed to make each part work.
Now is the time to finally put everything together. Right now i am trying to stabilize the Roll axis, as if i am able to do that successfully i beleive all the rest is covered.
I´ve built a testing platform for that as you´ve probably have seem before made by other people, and i am finding it extremely hard to tune the PID and make it stable.
Here´s a video of how it is now.
I am using this IMU:
With this Kalman filter:
And this PID library:
The "Input" is the output from the Y axis of the IMU Kalman Filtered data, the "Setpoint" is a value where my platform is leveled in reference to the ground, and the "Output" is currently mapped to 900ms - 1300ms range to control the ESC´s that control the motors.
As you can see in the video, i can´t get it much more "stable" then that, and currently it´s even more unstable. Too many overshoots and undershoots and i´ve played A LOT with the PID gains so far. Nothing seems to work.
I wonder if i am doing something wrong and if all the people out there that has built tri-copters, quad-copters, hexa-copters and so on, are doing. Their platforms seem A LOT more stable and robust. Even if i manage to get ir leveled it seems that no way it will be robust enough to be able to compensate for high winds or other sudden external disturbances.
Can someone please help?
Replies
Only just joined DIY Drones, so apologies for tardy reply.
I expect you know that the overshoot is due to the mechanical inertia of the arms.
Once the error correction signal has been sent to the ESCs, and (say) one motor has speeded up (the other slowing down), the arm starts to move back toward level, but doesn't stop as the motors resume normal speed, so the arm overshoots.
The only thing that I know of to combat this is to take gyro readings continually to determine the speed of the arm approaching level, then apply motor speed changes (in this case slowing one and speeding up the other) earlier if the arm rotation speed is higher.
So, in effect, the motors anticipate the arm getting level before it actually gets there.
Hope this make sense :)
Ron