Sort by time | Sort by thread (beta)

Link to this comment:

Share to:

All Comments (42)

Sign In or Sign Up now to post a comment!
  • I'm experimenting with 3-axis magnetometer to get orientation and speed. Basic idea is to read x-y-z field strengths relative to North Pole to determine orientation and reading magnetic flux on the sensors to determine velocity.

    Would like to hear your opinion on that.

  • A single orientation solution cannot be found, there will be infinite solutions represented by all orientations achieved when rotating the sensor around an axis aligned with the direction magnetic flux. See my paper by following link in video description.

    I don’t see how you can determine velocity from a homogonous magnetic field unless you are inducing current and limit your system to 1DOF which would be impractical.

  • These very basic graphics were created in 2D with a C# form. Check out the open-source x-IMU GUI [Google it] for far better 3D graphics using open GL.

  • What software I can use to view data in real time on the pc and make that animation?

  • great video!

  • @SebMadgwickResearch It makes sense, but again, how much damage the orientation suffers if I don't trust enough my accelerometer to correct gyro drift? Regarding your experience, do you think there is a "tunning sweet spot" or another level of intelligence is need to switch tunnings during execution time?

  • Incorporating an on-line tuning mechanism or 'adaptive gains’ will have obviously benefits but may represent a significantly more complex and less transparent system. I think most situations require only one-off tuning and for your efforts to be focussed on individual sensor calibration.

  • If a linear acceleration is applied to some direction (besides gravity direction) during some time, how much damage the orientation estimate suffers during that acceleration?

  • It depends on the algorithm tuning. You would tune 'how much you trust' the gyroscope. More trust (low gain) would mean that translational accelerations would have less effect on the orientation.

  • Thanks, now I understand everything.

  • Sorry, but a have another question. Why do you need the accelerometers? I mean, I thought that the gyroscope could do total orientational tracking.

  • I suggest you read the report linked in the video description.

  • So, with thE wii motion plus you can do this right?

  • Yes

  • So, the Yaw accumulating problem means that the thing won`t recognize the slowest Yaw movement I can do?

  • It will 'recognize' all movement. As with any real-world sensor, an IMU with provide a measurement + noise. In the cause of integral drift in the yaw axis, the ‘+ noise’ is a random walk governed by the noise (or quality) of the gyroscope.

    If your movement is very slow then it will still be measured ('recognize') it just may be too small in magnitude relative to the noise to observed.

  • @SebMadgwickResearch thank you for the answer, I needed it. And just one more last question for curiosity, are this sensors inside the famous Wii remote?

  • I believe it uses the ADXL335 (analogue accelerometer) and an Invensense digital gyroscope for the Wii motion plus.

  • @SebMadgwickResearch Then, the technology in that thing (the wii remote) can do the same than what you show in the video?

  • Hi,

    Excellent work. What type of filtering did you do for the roll and pitch axes? Did you apply a simple complementary filter or something a little more advanced? Stability looks great.

    Also, I had the problem of not being able to compensate for yaw either. I considered compensating for it using a digital compass, but it was only ever effective in the x-y plane relative to the surface of the Earth.

  • You should take a look at the report linked to in the video description.

  • What Graphics Library do you use??? in Visual Studio???

  • None, in this video I just draw three 2D lines.

  • Ok , but what library or Language do you use???

  • C#

  • Ok...but how do you draw the 2d lines...can you post some line codes?? thanks

  • See video description for link to source code.

  • Could you tell us how can you acquire the angle, I mean, the formula that you use to convert the ADC in an angle??? thanks.

  • At no point do I use angles. The algorithm uses quaternions only. You can find the answer to your question very quickly with Google.

  • HEY GREAT WORK

  • Hello sir i gone though your demo code, i find there bias and gain (a_xBias = 32634.2779917682, a_xGain = -0.00150042985864975) how these values were assign. If bias is 0g value then for a 10 bit ADC how it can be around 32k it must be 1024 maximum. and sir how u find gain. Plz reply soon sir

    deepak

  • I use a 16-bit ADC, therefore bias ~32768. For a description and source-code on my calibration method, search for the string "I have attached 2 MATLAB files" in the Sparkfun forum. URL = forum dot sparkfun dot com

  • Hello, I'm working on UAV application and trying to use your filter for IMU. Thank you very much for sharing your paper and source code, great work! I had few questions, though. As it wasn't clear to me what accelerations are being input to the filter. Are they just the bare readings from IMU(relatively to g) or they indicate rate of change of angles in the accelerometer reference frame? Another question is how to determine gyroscope measurement error gyroMeasError in your code. Thank you again!

  • The accelerations used (a_x, a_y are a_z in my report/code) are those directly measured by the accelerometer; the units (e.g. m/s/s or g) are inconsequential as the vector (a = [a_x a_y a_z]) is normalised by the filter.

    'gyroMeasErro'r "represents the estimated mean zero gyroscope measurement error of each axis" [section 3.6]. This is to be estimated by the designer. Typical values may range between 2 and 30 (deg/s), dependent on the accuracy of the gyroscope calibration.

  • nice, but it doesn't uses adlx335 in the application you shown, i want to make a human arm motion tracking system should i use the same imu. I have doubt over ADLX335 as it comes only 1 mode i.e +-3g will it be adequate for my application as, in all the publications i have through they uses a low-g accelerometer(<=2g)??

  • I anticipate that +-3g will be sufficient. You must consider the duration of accelerations >3g and the filter convergence rate due to measurements of gravity. For example, in this video the convergence rate is ~3 deg/s - therefore aworst case scenario accelerometer error lasting 0.5 seconds would result in a peak orientation estimate error of 1.5 deg.

    It is common to assume that a human is unable to engage in large accelerations for more than a few fractions of a second.

  • If you move the sensor slower, do you still have accumulating errors? In other words, is the sensor not 100% accurate, or are you just moving faster than the data acquisition rate can handle? I'm looking to build something that can be used in the real world and obtain accurate yaw readings.

    Thanks for sharing this vid!

  • The accumulating error around the axis parallel with gravity (yaw) occurs through the integration of errors from a number of sources. Moving the sensor faster provokes: LF sensor noise (i.e. gyroscope bias drift), calibration errors (gains) and errors due to the frequency response characteristics of the HP and LP filtering.

    The inclusion of a magnetometer can be used to overcome an accumulating error in yaw. See my video: An efficient orientation filter for MARG sensor arrays...

Loading...
Alert icon
0 / 00Unsaved Playlist Return to active list
    1. Your queue is empty. Add videos to your queue using this button:
      or sign in to load a different list.
    Loading...Loading...Saving...
    • Clear all videos from this list
    • Learn more