Alex
  • Male
Share
  • Blog Posts
  • Discussions (40)
  • Groups
  • Photos
  • Photo Albums
  • Videos

Alex's Friends

  • Zubax Robotics
  • Usman Qayyum
  • Wojciech Batog
  • Andrew Tridgell
  • Dilan
  • Jean-Louis Naudin
  • Stephen Carlson
  • Robert Krogh (hooks)
  • Jose Julio
  • William Premerlani

Alex's Discussions

 

Alex's Page

Latest Activity

Alex commented on Emlid's blog post Tuffwing integrates Reach RTK, gets 4cm precision without GCP
"Fantastic results. Thanks for the 100% transparent sharing!"
Nov 1, 2016
Alex commented on VGR-Systems's blog post Thrust vectoring coaxial Drone Update
"Impressive work!! Thanks for the generous sharing. Two newbee questions: 1. How to change the heading of the camera (I think the CR motor keep constant zero yaw torque)? 2. Not possible to use PX4 to replace the openpilot FC? Thanks! Alex"
Aug 16, 2016
Alex commented on DroneRanger's blog post Post Flight Log File Web Application
"Cant wait to test it!"
Jan 4, 2016
Alex commented on Andreas Habit's blog post Pixhawk vibration dampener.
"Also it would be great to see the logs."
Apr 23, 2015
Alex commented on Andreas Habit's blog post Pixhawk vibration dampener.
"Really interested in the dxf file. Possible to share? Thanks"
Apr 23, 2015
Alex commented on Zubax Robotics's blog post Zubax GNSS positioning module - GPS/GLONASS + Compass + Barometer + CAN
"Interesting product, I will buy one for testing as well. Can brothers who also bought and tested this unit provide any positive/negative feedback? Would be really appreciated to see it. To ZR Team, wonderful work! One suggestion: if you can…"
Nov 18, 2014
Alex commented on Usman Qayyum's blog post PID position Controller for Arducopter with VICON Measurements!
"It would be really appreciated if you can share your code with me! Very interested on this implementation!"
Sep 7, 2013
Alex commented on Usman Qayyum's blog post PID position Controller for Arducopter with VICON Measurements!
"Awesome and congratulations!"
Sep 7, 2013

Comment Wall (5 comments)

At 10:47am on December 6, 2009,
T3
William Premerlani
said…
Hi Alex,

You wrote:

"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."

Alex,

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.

Best regards,
Bill
At 9:02am on May 29, 2011,
T3
William Premerlani
said…

Hi Alex,

You said you had a question. What is it?

Bill

At 6:29pm on June 1, 2011,
T3
William Premerlani
said…

Hi Alex,

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.

Best regards,

Bill

At 11:28pm on June 12, 2011, Alex said…

Hi William,

Many thanks for your kind comments. I am reading your post in detail right now. Will go to realize the code in this week and let you know my result then.

May trouble you a bit more in the implmenentation procedure if you don't mind.

 

Have a nice day!

 

Best regards,

Alex

At 12:33pm on June 13, 2011, Alex said…

Hi William,

Many thanks for your kind patience. If not bothering you too much, could you give me some suggestions on the following questions?

  1. 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?
  2. 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?

  1. 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.

Best regards,

Alex

You need to be a member of DIY Drones to add comments!

Join DIY Drones

 
 
 

© 2017   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service