Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Correct. However, for LabVIEW it's much easier than the C version I posted. You don't need much in Begin.vi other than wire a FALSE into the visitedEnabled global (if you choose to make it a global - we make it global because we use it in a few places).

Download "The Secret Book of Labview v1.0" here and go to page 25 (page numbered 20, page 25 of the PDF) and try to implement the "boxcar filter" - that will be your moving average that you need for your bias calculation.

I don't have the code in front of me, but it's either 5 or 10 ms. We've been doing most of our control code in a 25 ms loop, but we have one really fast loop just for this.

Correct

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Although I have never done this before, I would imagine this only holds true for LabVIEW users. One of the benefits of Java and C++ is that you can change pretty much any of the high level code in the WPILIB. In this case, just extend the gyro class and rewrite whichever part of it calculates the bias.

Edit: There is a convenient int in the Gyro class (Java) called m_center. All you would have to set that variable to voltage of the analog channel at the start of the match. Unfortunately it is set at the default access level without a modifier method, so you would have to extend the gyro class (or just make a slight modification to your version of the WPILIB).

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

It's not quite so easy (in Java at least). The method that calculates the gyro bias is private, so it can't be extended. You have to patch WPILib.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

As I said in my edit, you don't have to modify that code. Just overwrite the m_center variable at the start of the match. Good catch though.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Kind of, but that's not really how the gyro works under the hood. The FPGA onboard the cRIO has a hardware accumulator which can integrate a signal coming from the ADC at a specific sample rate. This is used for the gyro as the timing is really precise and fast. In software, there is a memory mapped interface to the FPGA used to configure and view state on the various subsystems (accumulators, counters, etc.). The code in initGyro does the following:
1) Reset and init an accumulator on the channel the gyro is plugged in to.
2) Wait 1 second
3) Turn on the accumulator
4) Wait 5 seconds
5) View the 'value' of the accumulator (a 64b long) and the count of samples taken to get there.
6) Find the average voltage per sample, set that as the new 'center' for the accumulator.
7) Reset the accumulator

When you ask for an angle reading, it just reads the current 'value' out of the accumulator and scales it to a human understandable value.

m_center holds a local copy of what got written into the FPGA's accumulator as the 'center'. It is just a cached value used to convert the last few average samples on the ADC to a measurement with correct units in getRate. (Remember, the accumulator is doing the heavy lifting for measuring position). Writing to m_center won't really help here.

I don't know why WPILib chose to wait for 5 seconds to denoise the sensor. It seems like this can be done in WAY less samples (like, 10ms).

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

So long as you put your subclass in the edu.wpi.first.wpilibj package you should be able to poke around at the accumulator object, so you can just build a new init method. Which is dumb.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

I don't think drift is all of the problem. This year we used the KOP gyro for autonomous. Drift is no problem for this short period. Back in 2012 we never got an acceptable field centric working. 2 weeks ago the programming team developed field centric code again. Put it on the robot with the kop gyro and with some adjustments in code it works fairly well. Most of the testing was done at low velocity checking rotations and stuff. Yes, there was drift but, not excessive. Would be fine for a 2 minute match. Last wed. The drivers tried the field centric code and when the robot is driven hard the the way swerve should be, The gyro goes nuts. Large 10 15 20 30 40 degree swings in 10 to 15 seconds in both rotational directions. The drivers where practicing figure eights. Had to put robo centric back on for the rest of the night. This has to be some thing other than drift. Acceleration affecting the gyro rate? We have some other digital gyros to test. Just have to figure out and program them into the c-rio. We need a rock solid orientation to use field centric in competition. Is this a swerve issue, how do other teams do it.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Could the gyro have been saturated?

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Just to pile onto a thread that was once about mecanum robots.

The LabVIEW WPILib code is just as open as C++ and Java, and is in fact even easier to modify or use as a template to write your own stuff.

By the way, it is highly likely that the WPILib code will be modified to incorporate better calibration for 2015. The implementation in WPILib is simple, but not entirely incorrect. If your team relies heavily on the gyro, you can better characterize your sensor and customize the calibration to your setup.

Greg McKaskle

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Yes, that's a real thing. I remember seeing a value of 0.2 degrees per second per g of acceleration. That doesn't sound like much, and a properly mounted yaw rate sensor with good mechanical isolation shouldn't give you significant problems. But remember that vibration is also detected as acceleration, and it's possible that having the sensor rigidly mounted to the robot frame can yield false readings when the robot is in motion.

Consider also the possibility that you have an electrical issue. Signal noise picked up from motor wiring on the gyro analog signal will be accumulated as errors in the gyro angle. Make sure your sensor wiring is not running alongside power wiring.

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Is there an easy way to do this in LabVIEW?
Or do I have to put something in auto and tele that wires true to the visitedEnabled global?

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Like this:

Actually, we usually just wire a TRUE constant into visitedEnabled in Teleop and our Auto code. That makes it much easier.

(EDIT: Sorry for the issues. The site is having attachment problems. I should be able to post it in the morning unless the site problems persist.)

Re: Penalizing mecanum wheeled robots durring alliance selection.
 

Here we go: