Help the field crew, reset your gyro in autonomous

[Joe Ross]

In order to keep the matches going smoothly, it's important for your field crew to turn on your robot as soon as it gets on the field. However, it seem that many programs only open the gyro when the program first starts. If the robot is moved afterwards, it will use the power-on position as the starting position, and cause problems. Because of this, some teams are bringing their robot onto the field, then spending a minute lining the robot up, then turning the robot on, delaying the start of the match by the time it takes to line up the robot

There's an easy way to fix this. The first thing you do in autonomous, call gyro reset. This sets the heading to 0 right where the robot is at the beginning of autonomous. You can move your robot while it's on, without affecting the gyro that way. We've been doing this for years, but I've talked to many people at regionals this year that hadn't thought of doing this.

There is one caveat, your robot will need to be still while the gyro calibrates, which is typically 20-30 seconds after power up (if you open the gyro at the beginning of the program).

If you can't implement this in software (or don't want to deal with the caveat above), make sure your field crew knows where the reset button on the cRIO is. After aligning the robot, press the reset button on the cRIO, and it will only take 20-30 seconds to come up rather then the 1 minute or longer that it takes if you power cycle the whole robot. You can also hit the reboot robot button on the driver station to have the same affect.

Good advice! Thanks!

[apalrd]

We had one match at Kettering where our robot spun in circles while looking for the second tube. That was not because the gyro was not reset in the beginning of auto (it is), but because the gyro was moved while determining the centerpoint.

I really don't understand why there is no way, in the WPI library, to force a known centerpoint. It is much easier for the robot to determine it for itself (and it does a good job, averaging 1000 samples to get it), but if it moves, then that is very very bad.

I modified and attached my copy of WPI_GyroOpen to allow me to force setting of the gyro centerpoint. If set it to 0, it will determine the centerpoint for itself, and tell you what it is on the Center output. You can take that, and set it as a constant to centerpoint, so in the future it will use the known centerpoint. It will still find its own centerpoint (takes 2 extra seconds to boot up), but it will use the one you give it instead. I also have several other configuration options brought out to the connector, but in this version they are all set as they are in Gyro Constants. Oh, you can also set the gain in this VI instead of calling another VI to do it.

[mwtidd]

One solution to this is to use a compass, this way even if your team horribly misaligns your robot, you as the programmer can realign the robot for them.

I would never use a compass alone, but I think to use it to zero the gyro at various points of the match would help with the drift and alignment issues.

[Chris Hibner]

Is there a way for us to know in the software if the FPGA is finished determining the gyro bias?

[Joe Ross]

Originally Posted by Chris Hibner

Is there a way for us to know in the software if the FPGA is finished determining the gyro bias?

In LabVIEW, the gyro bias is done in the open, and is blocking. When the open returns, the bias calculation is done. In Java, the gyro bias is done in init gyro, and is also blocking.

[Jogo]

We were out of control a couple matches because of moving the robot while turning it on. This confuses the gyro, because it considers the voltage during this moment an angular rate of zero. As far as I can tell, the only safe work around is to not turn the robot on until it is still.

[Dave Scheck]

Originally Posted by Chris Hibner

Is there a way for us to know in the software if the FPGA is finished determining the gyro bias?

On the C++ side, it takes about 6 seconds from the time the gyro is instantiated to the time that it is done with its calibration. You can actually see the calls to the task wait function in the WPI gyro code. One idea that we have is to turn on an LED after the calibration is complete.

[BornaE]

It would be fantastic if the fms had an initialization mode that runs for 15 seconds before autonomous starts.

This way the gyro and all the other sensors and need standstill calibration can be calibrated in that period.

So the robot can be turned on and any point. when the robots are all ready and aligned, They "start" the match by triggering the init sequence using the fms, countdown 15 seconds and then the match start.


Any comments on this approach for next year?
obviously it cannot be implemented this year.

[The Lucas]

Originally Posted by Joe Ross

There's an easy way to fix this. The first thing you do in autonomous, call gyro reset. This sets the heading to 0 right where the robot is at the beginning of autonomous. You can move your robot while it's on, without affecting the gyro that way. We've been doing this for years, but I've talked to many people at regionals this year that hadn't thought of doing this.

There is one caveat, your robot will need to be still while the gyro calibrates, which is typically 20-30 seconds after power up (if you open the gyro at the beginning of the program).

We have been doing this for a couple years. Last year reset the accumulator and do a little offset logic every 300 disabled loops in C++ (Robot Class similar to IterativeRobot). I am not sure the specifics and exactly what we are doing this year since I didn't write the code.

[MagiChau]

Originally Posted by BornaE

It would be fantastic if the fms had an initialization mode that runs for 15 seconds before autonomous starts.

This way the gyro and all the other sensors and need standstill calibration can be calibrated in that period.

So the robot can be turned on and any point. when the robots are all ready and aligned, They "start" the match by triggering the init sequence using the fms, countdown 15 seconds and then the match start.


Any comments on this approach for next year?
obviously it cannot be implemented this year.

I think putting your code in the disabled loop could possibly work to have this effect?

[Chris Hibner]

Originally Posted by Dave Scheck

On the C++ side, it takes about 6 seconds from the time the gyro is instantiated to the time that it is done with its calibration. You can actually see the calls to the task wait function in the WPI gyro code. One idea that we have is to turn on an LED after the calibration is complete.

We're considering adding a gyro for backup heading. We were thinking of putting in an LED to let us know when the calibration is complete, but we weren't sure if there's anything in LabVIEW that tells us when it's complete (i.e. how do we know when to turn on the LED?). The signal light on the robot won't start flashing until after Begin.vi is finishes, so I'm thinking that once the signal light starts flashing, the gyro calibration is complete. We'll have to test that out at the school.

As a backup, I'm considering doing it the old fashioned way - just reading the analog voltage and doing our own bias and integration.

[JesseK]

The "other" solution to this is to spend less time lining the robot up. Our programmers told me about this, then told me about waiting 20-30 seconds after the robot was turned on to move it, or even place a tube on it. I told them we'd be shooed off the field if we were just standing around waiting for the bot to initialize.

So our drivers eventually got lining up the 'bot down to ~10-15 seconds. Worked well enough for alignment.

[Dave Scheck]

Originally Posted by Chris Hibner

We're considering adding a gyro for backup heading. We were thinking of putting in an LED to let us know when the calibration is complete, but we weren't sure if there's anything in LabVIEW that tells us when it's complete (i.e. how do we know when to turn on the LED?).

Joe mentioned above that the gyro open is a blocking call. Could you wire the output of that (or use one of those fancy flow blocks..I'm a Labview n00b ) to something that activates the LED?

[Chris Hibner]

Originally Posted by Dave Scheck

Joe mentioned above that the gyro open is a blocking call. Could you wire the output of that (or use one of those fancy flow blocks..I'm a Labview n00b ) to something that activates the LED?

Yeah, I know that now - before Joe's answer I didn't know if it was a parallel task.

As it turns out, since the gyro open is blocking, I shouldn't need to do anything. The default code flashes USER 1 LED in PeriodicTasks.vi. PeriodicTasks.vi won't run until Begin.vi completes. So... as long as open gyro is done in Begin.vi (which is where it should be), USER 1 LED will not start flashing until the gyro cal is complete. Yea for simplicity.