Got Gyro drift? Try Sensor Fusion !

[Richard100]

Steve - To conduct the calibration, you want to run 'Live', i.e. using a run-button deploy / debug mode, rather than compiling and deploying code to the roboRIO. This simply allows you to interact with the Dialog boxes that I use to prompt the calibration process (if you try to run the code as deployed when MagCal is TRUE then the program will appear to hang while it waits for you to respond to a Dialog box that, well, isn't displayed anywhere). Yes, you request magnetometer calibration by setting MagCal in IMUOpen to TRUE. Whether you use the Demo Project, or move the IMU code within Demo into your robot code, doesn't matter.

To use the IMU on the robot, it is also important that the calibration be performed with the sensor installed, to ensure the robot hard iron effects are compensated for during the calibration process. If you move the sensor, or change the metallic configuration of the robot, a re-calibration is strongly recommended.

The general idea is to set MagCal to TRUE to perform the cal, run the code, execute the cal, practicing the process until you get a good result (referring to the Example Magnetometer Cal Plot), then stop the code. Copy the four resulting magnetic calibration values (Scale & Zero for both X & Y) listed under Magnetometer Cal Results on the IMUOpen Front Panel, to the corresponding Mag Set control input for the same VI. Save this and reconfigure MagCal to FALSE. Now when you run the code (which doesn't need to be 'Live' anymore) the IMU is fully calibrated and you can use the sensor fusion results from the Complementary Filter VI.

Adjust tau mag and tau acc to taste, to balance the fusion.

Some teams (I believe GaCo was one) only used the IMU and this software for it's gyro readings, which is fine if you don't need the benefit of sensor fusion. This still gives you a three-axis digital gyro. In this case, the magnetometer calibration is not required, and you would read your gyro results directly from the IMURead VI. The IMUZeroBias VI provides the circular buffer to constantly calibrate the Gyro while the robot is disabled, which can be useful in mitigating measurement drift.

[sraque]

Originally Posted by Richard100

practicing the process until you get a good result (referring to the Example Magnetometer Cal Plot), then stop the code.

I'm glad you mentioned this because it reminded me of a question I had forgotten. What makes for a good calibration run? I have done a fair number of these with it now, and I have seen quite a few shapes that are not good, so I redo. Slow turn, fast turn, (no wobble/tilt is important I expect), etc?

Thanks!

[Richard100]

"Rotate robot 360 deg in *horizontal plane*. Best data results from rotating *about actual sensor axis*". (Dialog box instruction, * for emphasis.)

Try not to stray from the horizontal plane. Once the IMU is on robot, this is probably easier to ensure, since you're spinning the entire bot on the ground (and the robot wants to stay on the ground).

Don't make a big wandering loop, spin the sensor about it's vertical axis. If the sensor is in your hand (off robot), you would place it flat on a (non-metal) table (and away from metal fasteners - i.e. look under your table!), and simply rotate the sensor in place without 'orbiting' anything. I usually mount the board on a small block of wood with squared-up sides which facilitates experimentation. If sensor is on-robot, stare at the sensor while you manually spin the robot, adjusting it's motion to maintain the sensor over the same spot on the ground, as much as you can - it won't be perfect.

Make a complete 360 degree rotation, it's ok to go over some.

I usually take about 20 seconds to complete the rotation when the sensor is on-robot, the software is collecting data samples during this period. IOW, don't try to go too fast. It's ok to partially rotate and stop long enough to readjust your grip, then start rotating again. The data analysis process is insensitive to this - you'll just see some data concentration on some locations of the data plot.

If you receive an ellipse on the plot, instead of a circle, your sensor is experiencing soft iron effects for which the code does not compensate. Ensure the graph axes are scaled the same (equally sized ranges), prior to deciding that you see an ellipse, because the graph is set to auto range and might visually distort even though it's really a circle. Follow the guidance under the XY Mag Plot on the IMUOpen Front Panel should you get an ellipse.

After trying all these tricks, if you still can't achieve a fairly noise-free circle, try moving your operation to a completely different location. You may be attempting the cal in an Earth field that is disturbed. I had no trouble with the calibration in my stick-framed workshop, but a metal-sided building might disturb the Earth field. (If you have access to an airport, you could perform the cal on their compass rose, as that area is certified to be magnetically clean ... joking - that's definitely going overboard). I don't expect this to be a real issue, just a possibility.

Bottom line is to use the example plot for reference. This gives you a simple way to show you what you're trying to produce. The reference is typical of what I achieve after some practice. Like many things in metrology, technique can influence the result.

[tetris]

Thank you for your answers.

Is it possible to make 3 screenshots of the "context help" in Labview for these 3 Icons?: "WPI_I2COpen"; "WPI_I2CRead"; WPI_I2CWrite"

I need the name and descriptions of inputs and outputs of each icon (example with picture attached).

Thanks a lot, sorry to bother you

Regards

[Alan Anderson]

Originally Posted by tetris

Is it possible to make 3 screenshots of the "context help" in Labview for these 3 Icons?: "WPI_I2COpen"; "WPI_I2CRead"; WPI_I2CWrite"

I need the name and descriptions of inputs and outputs of each icon (example with picture attached).

I think you are still not understanding what you are asking for. The WPI library functions (in the Rock Robotics directory) work with the FIRST-specific FPGA image on a RoboRIO device, which you don't have, and which you almost certainly do not want.

Can we take a few steps back and get a more general view of what you're trying to do? If you're using the NI USB-8451, nothing you read here is applicable.

[tetris]

Hello thank you for your answers....
It is for a school project (engineering master).
I need the screenshot: i have installed labview 2014 and FIRST ( because I have student licence of my school).

Best regards
and Mery christmas

[tetris]

Hello
yes exactly I need the WPI library functions (in the Rock Robotics directory)
Can you send it to me ? Where can I find it? I need to understand the blockdiagramms in order to
adapt the programm with my USB 8451 device.

regards

[jhersh]

Originally Posted by tetris

Hello
yes exactly I need the WPI library functions (in the Rock Robotics directory)
Can you send it to me ? Where can I find it? I need to understand the blockdiagramms in order to
adapt the programm with my USB 8451 device.

regards

If you actually installed the FRC update then you would have these VIs. You could then use those VIs to understand the API that FRC uses so that you can port to the other USB I2C API.

I would recommend installing the "FRC Update".

[tetris]

Thanks a lot yes I did it and it works.
Nice that you help people and thanks a lot jhersh..... because other user on this forum was very unhelpful and not friendly with me!

Happy new year Jhersh and all the best in the new year 2016!!!!
Denis from GENEVA

[juchong]

Hi everyone! I hate to bring up an old post, but I want to post a shout-out to the RoboBees for providing the FIRST community with an elegant AHRS implementation!

As some of you may know, I've been working to improve the software libraries available for the ADIS16448 IMU. I ran across the RoboBees implementation and managed to integrate it into the main IMU code.

Once again, thank you very much for all of your hard work! If you would like to take a look at the code, you can find it on GitHub here.

[Bpk9p4]

Has anyone tried to use this code this year. I used it last year with great success. However i started to add this into my 2016 code and it keeps asking for a FPGA_TypedefDigitalModule.ctl does anyone know where to find this

[PhilBot]

Originally Posted by Bpk9p4

Has anyone tried to use this code this year. I used it last year with great success. However i started to add this into my 2016 code and it keeps asking for a FPGA_TypedefDigitalModule.ctl does anyone know where to find this

NI changed the VI's for several I/O devices this year. In most cases they removed the need to enter a module number, but your old code is still trying to provide one from an enumerated list. But that typedef does not exist any more.

There's probably a faster way, but if you just drill down through the VIs and locate all the ones with errors, you can just delete the "module number" constant that is giving the problem. It's not needed any more.

Phil.

[Richard100]

Bpk - If I remember correctly, you can just delete the reference to the .control in the code and the rest should work ok.

See this for a much more advanced IMU with LabVIEW code The RoboBees are using this one for StrongHold - you might like it.