Got Gyro drift? Try Sensor Fusion !

[PhilBot]

Hi

On your DEMO Block Diagram you show connecting the VIN pin on the Adafruit board to the +V of a DIO channel.

I'm assuming this is because the power pin on the RoboRio's I2C port is rated at 3.3V and the 10DOF board inputs are VIn or 3.0 V. So you opted to power the raw VIN with 5.0V

However, this means splitting the cable into two connector areas.

Reading the spec on the Adafruit page,

https://learn.adafruit.com/adafruit-...nnecting-it-up

.. it looks like we should be able to power the board from the I2C power pin.

Is there another reason for not taking this simpler wiring approach?

It says:

----------------------------------------------------------------------------
3V3 Setup

If you are using an MCU or board with 3V3 logic (instead of the 5V logic used by the Arduino Uno), you can still power the 10-DOF with the VIN pin or you can use the 3Vo pin, which will bypass the on-board 3V3 regulator and level shifting:

Connect Vin or 3Vo on the breakout to the 3.3V supply on your target MCU
Connect GND on the breakout to GND on the target MCU

Like other breakouts on Adafruit, the 10 DOF Breakout is fully level shifted, and you can safely use it on 3V3 or 5V systems.
----------------------------------------------------------------------------

[Richard100]

Phil - I did opt to power the board with 5 volts. I have not conducted any testing with the 3.3 volt I2C supply, although I suspect it will work fine and does present a simpler wiring situation.

[Eric_Puccio]

I am a bit lost and in need of help. I have been helping my team with their programming for a few years now and I can get all of our needs met and then some. We are trying to step it up and do field oriented drive for our mecanum wheels this year. I have read this thread 3 times over and looked at the download for the roboRIO more than once. Can someone please explain (or provide an example) how to integrate the download into our team code so that we can use the output of the 9DOF chip as our gyro input. everyone I have asked says to look up this thread.

I may just be not seeing a forest through the trees here.

Any help you can provide would be greatly appreciated in this last build week.

[Richard100]

Eric - I would recommend running the IMU Demo vi first, to get familiar with the settings, operation, and calibration. You will want to clearly understand how to set the loop timing, how it affects both the IMU readings as well as your other code. You will also want to understand how to set the two 'tau' values to tune the complementary filter performance.

Once you understand how it works, there is an example on how to integrate it into your robot code within the IMUOpen vi. Look at the LabVIEW Block Diagram of the IMUOpen vi ... scroll down to where there is a large note section describing how it works. To the left of the note section is the example on how to implement these IMU vi's into your code. There is one piece of code that goes into Begin, and another that goes into Periodic Tasks (AKA Timed Tasks). [They both have a Disabled Structure wrapped around them so they won't execute, as they are only there to illustrate implementation.]

Copy this example code into your Robot Project Begin and Periodic Tasks, and remove the Disabled Structures. If the IMU Demo worked on your roboRIO, this should also work. Take either the X/Y/Z Gyro output of the IMURead vi, or the Roll/Pitch/Yaw output of the Comple Filter vi as your sensed values, depending on what you're trying to achieve (sensor fusion or just using this code to read the Gyro.)

Understand that this sensor fusion uses the Magnetometer to stabilize the drift associated with the Gyro's Yaw - which is what you'll use for a field-oriented drive. If you haven't much experience with a Magnetometer, I would also recommend you initially start by simply getting your field-oriented drive working with the Z-output of the Gyro (pre-sensor fusion). Then ensure you actuate all robot mechanisms (especially your drive system) to verify the Magnetometer readings are not affected (significantly). Any significant field disturbance will otherwise directly affect your field-oriented drive performance, until resolved. It can be challenging to maintain constantly clean readings of the Earth's field on an FRC-bot ... your issue mitigation options are IMU relocation, magnetic shielding, or clever use of when you take a Mag reading. (Most teams that report on CD, indicate that they only use the Mag to get an initial bearing during Disabled Mode, when the bot is largely powered down, and then live with Gyro drift during the match). From the code documentation:

'The Mag cal values are strongly a function of where the sensor is located on the robot, and what is installed nearby, so it's important to recalibrate fairly often, certainly after relocating the sensor, and again after the robot is completely assembled. Be sure you actuate all motors and mechanisms to test for interaction with the Yaw indication, which uses the Mag. Be aware that another robot that comes close to the Magnetometer might disturb the local magnetic field enough to cause error in Yaw.'

Bottom line - the Mag is not a slam-dunk sensor for an FRC-bot, it requires (very) careful integration. The referenced code can be used to produce Gyro Yaw readings that are independent of the Mag, but will have some drift. Pitch and Roll can be drift-free with sensor fusion, and are independent of the Mag.

[Eric_Puccio]

Thank You for the very quick response. I must have missed these notes it in my reviews of the code. I will read the notes in IMU Open vi and try again.

[Richard100]

This just in ... Here's an update to the roboRIO IMU code to fix a bug in the IMU Open vi. The bug affects the Rate Gyro operation by causing it to be set up incorrectly. This bug ONLY affects the newer AdaFruit 9 and 10 DoF IMUs, that have the L3GD20H Rate Gyro chip (purchased after Oct 2014).

I'm attaching the entire Project update, but if you like you can just make the change, (highlighted in the attached PNG Image file), in the code you may have already downloaded.

[Eric_Puccio]

Thank you for all the help. I am 99% of the way there.

I got the Demo to work, and i integrated it in my code with no issues when i run code via fast deploy (run Robot main) it makes me do the calibration on the first run. However i cant get it to work when i do a build and deploy to run via WiFi or FMS. Any suggestions?

[Richard100]

Eric - The IMU Open vi (in your Begin) has a Boolean input labeled "MagCal" ... set it to False.

This tells the IMU Open to skip the Magnetometer calibration process, which uses dialog boxes to gate the data collection sequence. I suspect that the dialog box is hanging your code (since there's no way to answer it when you deploy code).

If you're using the complementary filter for fusion, you'll need to calibrate the Mag, and then transfer the cal values into Mag Set cluster for the IMU Open. Once this is completed, you would turn off the MagCal input (it's not automatic, sorry) - this would be the competition mode, when you are using deployed code.

If you're not using the fusion filter, just leave MagCal false.

Hopefully that will fix it ...

[Richard100]

The issue previously reported that the roboRIO can not read multiple I2C devices (like an IMU) when using the MXP I2C bus has been resolved in the mandatory FRC update 2015.1.0 (LabVIEW WPILib changes: Fixed artf4003: multiple I2C devices don’t work on MXP).

Download and install the update (from the link on the LabVIEW FRC 2015 Getting Started page). The released RoboBees IMU demonstration code has been tested against this update and will now work correctly when the IMU is connected to the I2C bus on the MXP. You can use either I2C bus now, On-Board or MXP. This provides a means to employ two IMU's, if required.

[PhilBot]

I'm experimenting with this code and the Adafruit 10DOF board.

I have it all wired up and I'm watching the displays on the demo VI.

On the pitch/roll/yaw dials I'm seeing proper action on the RED arrows, but little activity on the grey arrows.

From the comments I expected both color dials to more or less follow each other with variations from drift. But the grey dials never get far from zero.

Is this expected with an "out of the box" VI configuration.

Phil.

[Richard100]

Phil - The issue you're describing can be caused by the programming error I identified in post #21 of this thread - if you're using one of the newer IMUs (purchased after last Oct). You can either download the corrected project file, or simply make the change illustrated in the code image attached to that post.

Another cause of deviation between the rate gyro and it's fusion (the grey & red needles, respectively) can be over-ranging the rate gyro by rotating it faster than the range it is set to. You won't damage the sensor but will miss some angular displacement reporting while beyond the set range. This is easy to do when the IMU is off the robot (say, rotating it in your hand).

I suspect that the problem is the the first thing, though, since you describe the grey needles as not moving at all. Both needles should track out of the box, within a tolerance affected by the quality of the calibration process, and assuming the sensors are not over ranged.

If you haven't already, try the code update and let us know if that resolves it. Let us know if the symptom persists and I'll look around for another cause.

[PhilBot]

Originally Posted by Richard100

Phil - The issue you're describing can be caused by the programming error I identified in post #21 of this thread..

Thanks, that fixed it.

I thought I had downloaded the latest version... but clearly I hadn't.

Question...
Does resetting the gyro during operation upset the sensor fusion math? It doesn't seem to, but I didn't want to assume.

Phil.

[Richard100]

Operationally re-setting the rate gyro does not upset any of the fusion performance. The reset simply zeros the degree displacement accumulator (in software) ... so it works just like the analog rate gyro reset you're probably accustomed to. Reset at will.

The fusion algorithm uses the gyro rate (in degs/sec), not the gyro displacement (in degrees), to do it's magic, which is why there's no operational impact to the reset.

Zeroing (resetting) the gyro displacement is, of course, different from zeroing the actual gyro rate (resetting the zero rate bias) - the latter only occurring during the calibration process embedded in the IMU Open vi execution. I'm assumming you're referring to former 'type' of reset, using the IMU Reset vi.

[PhilBot]

So.. Loving the ADAIMU code. Thanks.

Have a problem. If the robot is being moved during startup, the Gyro gets a bad cal.

I see where you make two attempts, but the problem could last longer then that, and I'd realy prefer not to hold up the begin code too long.

I put a filter on the angular rate and check it in Disabled.vi

If it get too large (more than 0.1) I want to do a recal.
Easy with the analog gyro.... Can't figure how to do it with your IMU code

I tried just redoing the open... it failed, looks like coms doesn't like two opens.

There doesn't seem to be an IMUclose.vi

What is the best way to initiate a re-cal, or restart of the IMU?
Don't need a recal on the magnetics, just the gyro.

Phil.

[PhilBot]

While waiting for an educated reply, I generated a patch that seems to work. I created a IMUrecal.vi that I can call when I see a large drift while disabled.

It's taken from the original OPEN vi. I'm not sure if it's correct, or if I'm accessing the devref correctly, but it seems to be doing the job.

I keep the devref in a global, and just re-write it with the updated cal values.

Any good?

Phil