Help the field crew, reset your gyro in autonomous

[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.

[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.

[Vikesrock]

I just had a thought that I figured I would throw out there.

What about using a Driver Station input to trigger the Gyro Open in Autonomous Disabled? Then the gyro bias can be calculated during team introductions.

[boomergeek]

This is an important issue as more teams are using the gyro.

We are thinking of adding a relatively quiet but noticeable buzzer that will turn on for 8 seconds- the last 2 seconds we will use to initialize the gyro.

If the field crew is moving the robot when the buzzer sounds, they know they have a few seconds to stop moving the bot- if they don't, they at least know that they should reset the cRIO.