Tuning ArduIMU
In my latest flight test with the ArduIMU, I found that I probably need to tune it a bit. First of all, the data:-
http://vimeo.com/10887900
My preliminary observations are that the output converges onto the accelerometer settings too quickly. This in-spite of the 1G vector magnitude guard in the code.
Can someone explain to me the relationship between the Ki and Kp to the tuning. I have some idea of what they do but am not sure how they interact with each other.
Thanks,
Daniel Wee
http://vimeo.com/10887900
My preliminary observations are that the output converges onto the accelerometer settings too quickly. This in-spite of the 1G vector magnitude guard in the code.
Can someone explain to me the relationship between the Ki and Kp to the tuning. I have some idea of what they do but am not sure how they interact with each other.
Thanks,
Daniel Wee
Replies to This Discussion
-
Permalink Reply by Doug Weibel on -
Ki and Kp are integral and proportional gains for the drift correction PID controller. Increasing Kp will cause a faster response, but if too high will produce oscillation. Ki will tend to reduce steady state error, but again too much will cause oscillation
-
Permalink Reply by Daniel Wee on -
Hi Doug,
If you take a look at the above video - you will see the problem I am having. The IMU responds quite well to temporal changes but it gravitates towards the accelerator during a sustained turn. I'm trying to adjust it so that the IMU will be less reliant on the accelerometer.
If I understand what you are saying correctly, then I will need to reduce Kp (since a faster response may rely on accelerometers) and reduce Ki (since steady state error relies on accelerometer output to correct?).
I am also surprised that the accelerometer magnitude guard is not as effective as I had hoped during sustained turns. Could you take a look at the video and let me know what you think needs to be changed?
That said, the IMU performance in rolls was superb.
Daniel
-
Permalink Reply by Ryan Beall on -
I'm not real sure what your OSD is actually displaying? I looked like you had the IMU oriented wrong or I just wasn't understanding the osd output. Is the bar susposed to follow the horizon? If so it seems like your imu is in backwards. I could probably point you in a better direction if I knew what I was looking at.
In this instance, I think the accelerometer deweighting is working fine but it would for sure be all messed up if you mounted it backwards. IE front was the back and back was the front.
right wing down is positve roll if that helps. If that's how you have your osd set to display then bounce back some more info and I'll see if I can help
-Beall
-
Permalink Reply by Doug Weibel on
-
I could use the same explanation of the video as Ryan...
The characteristic you are describing sounds like a fault in the centripetal correction rather than the accelerometer based drift correction. Which gps are you using?
-
Permalink Reply by Daniel Wee on
-
The IMU is correctly oriented and you do see that it tracks somewhat - for example during the rolls. It's just not tracking very well. The horizontal line should follow the horizon and does so for a while. But shortly thereafter, the line gravitates to the accelerometer values.
Yes, I agree that something may be wrong with the centripetal correction. The IMU is operating in a pure 5DOF mode - no GPS. I do not need yaw correction.
Daniel
-
Permalink Reply by Ryan Beall on
-
The GPS provides two things: a reference vector to stabilize yaw drift as well as provides the velocity vector for centripetal compensation.
The primary reason these cheap imu's are successful is because they are coupled with an external speed reference (ie gps) to estimate the centripetal acceleration. If you don't have this or it is operating poorly the accelerometer de-weighting will be the only thing keeping it strapped to reality. Unfortunately, it can't do it by itself. You have to have the centripetal compensation from gps!
You can alternatively use airspeed but the arduimu isn't really setup for it. Add a GPS and fly the stock code. I would bet you get the results you are looking for.
-Beall
-
Permalink Reply by Ryan Beall on
-
I didn't think it was this sensitive but you can even see it when you taxi in your video. The solution rolls when you yaw the plane to taxi. This is a perfect example of centripetal acceleration falsely moving the solution.
-Beall
-
Permalink Reply by Daniel Wee on
-
Hmm... that's what I was hoping to avoid. I'm trying for the best possible purely inertial solution. What I am doing now is to improve the accelerometer de-weighting by calibrating the accelerometer more precisely and also making the de-weight exponential rather than linear. Hopefully this will yield better results.
As an aside, is the GPS code setup to deal with upside down flight? Ie. does the frame of reference change when flying upside down.
Daniel
-
Permalink Reply by Loris on -
Hi,
You need a speed estimation to remove centripetal acceleration. If you don't have a GPS you can add a pitot tube or simply estimate the speed with the throttle. That is what I made on a flying wing and it works fine.
Loris
-
Permalink Reply by Daniel Wee on
-
I am aware of that, but as I said before - the idea is for a purely inertial solution. Typically, in a situation like this, an estimator would rely on the gyro data more until the accelerometer becomes reliable again. This is what the Accel_weight should be doing but for some reason, it isn't working. I have refined this a bit more and hopefully tests will yield better results.
There are many situations where a GPS is not an option, such as in submersibles. I do believe that this can be accomplished without GPS augmentation and that really is the challenge here - optimizing the inertial aspects of the estimator.
Daniel
-
Permalink Reply by Loris on
-
Hi,
In submersibles they know their speed. There are too much noise on gyros and accelerometers to estimate the speed. Even in commercial IMUs it is impossible.
If you want to make long turns you will need a speed estimation. For short turns maybe you can try to rely more on gyros but it would be difficult because of the gyros noise.
Loris -
-
Permalink Reply by Daniel Wee on
-
Loris,
Do you happen to have any test data that can put some numbers to this? I am hoping that the noise is Gaussian in nature and will be good enough for the gyro to hold an angle for up to 15 to 20 seconds. I think that's more than reasonable. Static test data I have shows that this is actually quite possible so I am curious as to why you make that particular statement that it is impossible.
The whole idea of using accelerometers in conjunction with gyros with an optimal estimator is precisely to make such a thing possible. Typically a Kalman filter (or EKF or some similar variant) would be used. The fusion of the data allows for the long term performance of the accelerometer to be used with the short term reliability of the gyro.
So my question is if you are stating this with some sort of authority, or experimental data, or merely just anecdotal opinion?
Thanks,
Daniel -
Top Content
Groups
-
ArduCopter User Group
476 members
-
ArduPlane User Group
299 members
-
ArduCopter (traditional …
77 members
-
ArduPilot (legacy) User …
77 members
-
Moderators
50 members
-
ROS User Group
31 members
-
Team Prometheus
11 members
© 2012 Created by Chris Anderson.
