[NotInControl]

Originally Posted by Ether

In the code you posted, sampling the counts every 200ms and dividing the difference by the difference in time produces a speed signal which is the average speed over the past 7.7 revolutions...

Thanks for clearing that up. Agreed,It's lag due to the derivative of one timestamp. In my case its 200ms. If using the 1MHZ timer at best it would be 1e-6 seconds, which would be nice if I can get it to work using your suggestions.

Originally Posted by Ether

The default value in WPILib is to set up the FPGA to return the elapsed time between the most recent 2 counts (i.e. N=1). Have you ever changed that default value? If not, I can understand why you couldn't get it to give you a clean signal at high speeds.

I have not, for Java the function which configures the counters averager is not part of the API so I have to re-compile the WPIJ library. I have not gotten around to it yet, but it is on my to do list to play around with it after we bag the robot. Right now the default is 1 from the counter class.

this.m_counter.writeTimerConfig_AverageSize(1);

Any recommendation for a new averaging value?

Originally Posted by Ether

The speed signal comes from the sensor on the robot, not from the Driver Station. The only time the 20ms would come into play is when the driver changes the speed setpoint, which is typically a step change, not something that's continuously changing every 20ms.

Not correct, the code is set up so that the periodic functions (i.e autonomous periodic or teleop Periodic waits for a new driver station packet before executing. So any code within these blocks will only run once every new DriverStation packet which is 20ms. If you have code which samples your signal at 10ms, but then only drive your motor in the teleopPeriodic block, you are wasting half of your calulcations because they are not being used to command the motor. The 20ms comes into play anytime you have code within any of the periodic blocks. Its a Pitfall.

If you want to run your motor faster than 20ms, you must place the drive code in a different loop, thread, etc that does not wait for new DS packets.

Here is a snipit from the WPI Library showing the wait:

        if (nextPeriodReady()) {
          getWatchdog().feed();
          FRCControl.observeUserProgramTeleop();
          teleopPeriodic();
          didTeleopPeriodic = true;
        }

      }

      this.m_ds.waitForData();
    }
  }

  private boolean nextPeriodReady()
  {
    return this.m_ds.isNewControlData();
  }

Originally Posted by Ether

You've got that backwards. I'm not ignoring inertia, I'm depending on it. Inertia plays a critical role in making bang-bang speed control work cleanly. Bang-bang speed control likes a high inertia load, a fast control loop, and low phase lag in the speed feedback. Compared to the approach you are using, GetPeriod() gives a smaller phase lag for the same signal-to-noise. And bang-bang code is so simple that it's not a problem to run it at 10ms. It also has the fastest spinup and recovery time.

You are taking what I said out of context. The statement of inertia and bang-bang control were totally separate. I was simply stating that performing calculations at such a fast rate (i.e 10ms) may be unnecessary because there are other factors to be aware of... such as if your going to be calculating a signal every 10ms, make sure you run in a separate loop from the periodic functions, or else your control gets chopped to 20ms, and you loose half of your calculations instantaneously... secondly the inertia on your motor might not allow the motor to react within 10ms, so commanding it every 10ms is unnecessary. Essentially... when considering the physical constraints, it may reduce your need to calculate control signals at such high rates, and maybe slower rates are just as exceptable because your motor can only react in 50ms, or 100ms.

Originally Posted by Ether

GetPPCTimestamp(). It's not nanosecond but it's better than millisecond.

Not available on Java. The timer class in Java has getFPGATimeStamp() (returns ms) and getUsClock(), although the UsClock is deprecated I am not sure why.