"Now I am undergoing a project in which a ADIS16405 IMU is used on a easystar based UAV, as you mentioned, the EMI problem caused by the elec motor is quite obvious. May I know that according to your experience, commonly what methods can be used to effectively reduce the EMI problem (My initial plan is to use some aluminum foil and glue them outside the foam part holding the elec motor, is it proper?)
Many thanks in advance for your help."
Let me start by saying that the ADIS16405 looks like a great sensor for heli usage. Analog Devices makes high-quality gyros, it has been my experience that their gyros are practically vibration immune, which is needed for a heli. Also, helis can benefit from magnetometers.
But you mentioned that you are working with an EasyStar...with fixed wing aircraft such as the EasyStar, you do not need magnetometers. All you need are gyros, accelerometers, and a GPS, which are not prone to interference from magnetic fields. So, I would suggest using something without magnetometers.
However, if you have some good reasons why you want to use magnetometers, such as detecting wind direction, you have to be concerned with interference with the magnetometers.
Regarding interference to the magnetometers, the main issue is magnetic fields caused by the motors and power wires. Since they are mostly steady magnetic fields, it is not easy to shield them from the magnetometers. You cannot shield the magnetometers, because they have to sense the earth's magnetic field. In my opinion, the best you can do is to keep the magnetometers as far away from the motors and power carrying wires as you can. One of the first things you will want to do is to see how much interference you are getting.
You asked me a question about how to get position and velocity information at high bandwidth. Here is a link to a recent post on the subject. The method is really simple. You start with accurate attitude estimation, so you have the rotation transformation matrix. Then, transform the accelerometer information from body frame to earth frame and account for gravity. Integrate the acceleration to get velocity, integrate again to get position.
Of course, there will be errors that quickly grow. The solution to that is to use the GPS information to provide drift compensation. Simple proportional negative feedback will do the trick, if you inject it into the correct places in the calculation. Use the velocity error in the earth frame to compensate the acceleration. Use the position error to compensate the lock.
The result is that you will have a high bandwidth estimator of velocity and location.
Many thanks for your kind patience. If not bothering you too much, could you give me some suggestions on the following questions?
I accidentally find that I have two versions of “dead-reckoning.c”, which are both downloaded from the same link in your post. The more complete one includes GPS_filter_gain, and settings for HILSIM. Could you suggest me which one is more suitable?
I am a hardware guy so it would be really appreciated if you can explain a bit on some code:
a) RMAX, after my checking, is 1, may I know the meaning to define it?
b) Similarly, the meaning of defining MAX16?
c) For the two versions, DR_filter_gain is different, may I know why?
d) DR_period is also different (I can understand 40/GPS_rate, but don’t understand 40/GPS_rate +4 (in the simpler version)?
e) By my understanding, from the first beginning, IMUvelocity and IMUlocation are continuously updated with 40 Hz. Although we can get info from GPS, this info is only for correction purpose. That is, in real flight control, only the trimmed IMUvelocity and IMUlocation are used. Am I right?
f) In your post, you mentioned that the GPS latency is considered in the algorithm. Is it the processing when HILSIM == 0? This is a very important step in practical implementation, right?
I actually want to implement this algorithm only between the adjacent GPS updates. Once I got the update (NED-based velocity and location), I would like to reset these values as the starting point of next slot (200 ms, considering the 5 Hz UBX gps unit)? Do you think it is a suitable way for the implementation? I indeed need the experts’ suggestion.
Truly sorry for putting so many questions. I will summarize this post, your answer, as well as my later experience (particularly in practical implementation) and share with guys here.
No comments yet!
You need to be a member of DIY Drones to add comments!