Configure Timers

[Ether]

Originally Posted by NotInControl

I do not see an attachment with your post so it's hard for me to say how my definition lines up with US Digital

I my haste to be responsive I forgot to attach it. Here it is. It's just a screenshot of a portion of page 1 of the E4P datasheet, which is available here.

So I am going to assume that the 500 PPR Cytron that you mentioned is actually a 500 CPR (using the US Digital and GrayHill definitions of CPR).

You said you were controlling 2300 rpm wheel speed with that 500 CPR Cytron encoder, but you didn't mention how you were decoding the signal, so it's not clear how many counts per rev you were getting. I'll just assume for the moment that you were using 4X quadrature decoding, so you'd be getting 2000 counts per rev.

You said you were polling the counts and computing the speed every 200ms. 2300 rpm is 7.7 revs every 200 ms. That's 15,333 counts every 200ms. So it's no wonder you are getting a clean speed signal: you are averaging the elapsed time of 15,333 counts to get your speed. That introduces lag. Lag in the sensor signal is generally not a good thing for closed loop control; it limits how fast you can make the response without causing oscillations.

Consider what would happen if you did this: use only one channel of the encoder, and configure the FPGA to count only the rising edges of that channel and to report the period based on the elapsed time between the 126 most recent counts. You would use the GetPeriod() method of the Counter class to get the period. The FPGA polls for rising edges at ~153KHz, and uses a 1MHz timer to measure the period. At 2300 rpm you should get single-digit rpm jitter with this setup, and with only 1/4 of a rev lag instead of seven and a half revs. You could ask for speeds at a 10ms rate and get a fresh reading each time.

With a clean, noise free speed signal with minimal lag (as described above) it becomes possible to use a bang-bang wheel speed control algorithm. That provides the fastest spinup and recovery times. The code is so simple that it can be run at 10ms without sucking up CPU time. No tuning is required, and the iteration rate of the control algorithm can be quite sloppy without affecting the control.

Here's a link to the use of micro-second timer to measure the exit speed of the frisbee from the shooter. A highly accurate feedback signal of frisbee exit speed would make it possible to tune the shooter wheel speeds to maintain consistent frisbee speed.

It's getting late and this post is getting too long. We can talk about the other stuff later if you want.

[NotInControl]

Originally Posted by Ether

I my haste to be responsive I forgot to attach it. Here it is. It's just a screenshot of a portion of page 1 of the E4P datasheet, which is available here.

Thanks. So yes My PPR definition is equivalent to US Digital's CPR definition.

Originally Posted by Ether

So I am going to assume that the 500 PPR Cytron that you mentioned is actually a 500 CPR (using the US Digital and GrayHill definitions of CPR).

Correct.

Originally Posted by Ether

You said you were controlling 2300 rpm wheel speed with that 500 CPR Cytron encoder, but you didn't mention how you were decoding the signal, so it's not clear how many counts per rev you were getting. I'll just assume for the moment that you were using 4X quadrature decoding, so you'd be getting 2000 counts per rev.

Correct, I am using 4x decoding

Originally Posted by Ether

You said you were polling the counts and computing the speed every 200ms. 2300 rpm is 7.7 revs every 200 ms. That's 15,333 counts every 200ms. So it's no wonder you are getting a clean speed signal: you are averaging the elapsed time of 15,333 counts to get your speed. That introduces lag. Lag in the sensor signal is generally not a good thing for closed loop control; it limits how fast you can make the response without causing oscillations.

I think we both agree the hardware is counting all of the pulses with a max rate of 153 kHz. Lets assume for a second that the count was a continuous analog signal. I am simply sampling this analog signal every ~200ms and then calculating the velocity between the two points.

Sampling the signal does not provide any lag. If we were to place the analog signal over the sampled version, all of the peaks would line up.

I am introducing lag when I calculate the derivative of the signal in order to get velocity. Furthermore, I am introducing is a small bit of error, because I am approximating the derivative of the signal between the two points with a straight line, but that is standard procedure when performing discrete differentiation, and its a small error I can tolerate within my robust control.

As for the lag, my speed signal lags my position signal by ~200ms in this example. However lag is present for any discrete differentiation. You will always lag by at least one time sample. Even using the FPGA when calculating the rate you will need to wait at least one time clock (granted the time clock is much smaller, so lag is less, but below I will explain why I believe 200ms is tolerable.

note: I choose to run my loop at 200ms, I can run it much faster with approx +/- 6-10 rpm hits which is still acceptable for my control algorithms. It is less than 1% of my top speed.

So that covers lag, and no matter If we use a millisecond timer, or have a nano timer, I can't get rid of lag as long as calculating velocity. I can shorten my sample time in order to reduce lag. I do not understand what you mean by average, because the points are not being averaged. Can you elaborate?

Originally Posted by Ether

Consider what would happen if you did this: use only one channel of the encoder, and configure the FPGA to count only the rising edges of that channel and to report the period based on the elapsed time between the 126 most recent counts. You would use the GetPeriod() method of the Counter class to get the period. The FPGA polls for rising edges at ~153KHz, and uses a 1MHz timer to measure the period.

I have never been able to get a clean signal from the period() function. This is what lead me to write my own software rate function. Last year for our 2012 robot, I counted using on rising edges only on a 256 PPR encoder and saw RPM spikes of +/- 50 RPM in some instances. It wasn't something I could tolerate. So my solution was to average the data, and I averaged the last 10 samples to get a better signal.

I know other teams have also experienced similar issues, and in one Post, I read that NI recommends setting an averager on the FPGA using its API.

I haven't looked into why the getPeriod() function produces a signal so noisy, but I suspect it is because FRC chooses to do division in software instead of hardware, and divide by a constant number, however, that code can be delayed in software causing the division to be inaccurate. FRC has had trouble producing a clean getPeriod() signal for years.

Originally Posted by Ether

At 2300 rpm you should get single-digit rpm jitter with this setup, and with only 1/4 of a rev lag instead of seven and a half revs. You could ask for speeds at a 10ms rate and get a fresh reading each time.

With a clean, noise free speed signal with minimal lag (as described above) it becomes possible to use a bang-bang wheel speed control algorithm. That provides the fastest spinup and recovery times. The code is so simple that it can be run at 10ms without sucking up CPU time. No tuning is required, and the iteration rate of the control algorithm can be quite sloppy without affecting the control.

Simply using the getPeriod() method won't help because I don't think it will produce the clean signal you mention, without averaging (which introduces lag), for reasons I have mentioned above and what we have personally experienced.

But my original question was why do you think a millisecond timer is not good enough accuracy for FIRST, and what is driving you to higher accuracy requirements than a millisecond timer.

Seems like you would like to do bang-bang control. And typically, bang-bang has oscillation around its setpoint because you just have on off control so in order to remedy this oscillation, you wish to sample as fast as you can, and update the control law quickly so that you could reduce oscillation.

But a couple of things here, why do i need to ask for a speed signal every 10 milliseconds? The Driver Station Packets are sent every 20 milliseconds, so any calculations done faster than that, are simply being thrown out and not making its way to the robot. Unless you run your code in a different thread that runs at a faster loop than teleop Periodic for example. Is this what you are assuming?

Secondly, You are ignoring inertia and coulomb friction. Unloaded my motors can react quickly, where it makes sense in doing calculations rather quickly. However, once I start adding inertia to my motor, I.E arms, gears, wheels, its reaction time reduces drastically. So even though you are calculating a command signal every 10ms, or 20ms, those signals are not actually moving the motor, because the motor with inertia has a reaction time of say 50ms or 100ms. For a shooter wheel its reduced when your at speed, but for position control, you must always overcome coulomb friction every time you start up. Why calculate a signal every 10ms when your not using it? My drivetrain doesn't react in 20ms, I wish it did however .

As for the control of bang-bang, It is a good way to control velocity of the wheel for its simplicity, but you need to manage the oscillations around the setpoint. A better method might be to use a simple proportional controller to reduce oscillation, but then you must deal with steady-state error. Going to PID means you must deal with integral windup and derivative noise. Every control method has its pros and cons for the applications.

But how fast is a fast recovery? And if you are sampling every 10 milliseconds, why do you need a timer that has better resolution than 1 millisecond?

If I can have a bang-bang which recovers in hypothetically 1ms but oscillates around its set point so much that back to back shots vary, vs a PI controller which takes a little longer to get up to speed but is stable around its set point, which is the better controller?

Further more, what is the point of doing all that work, at that fast of a rate, if the mechanism I have feeding the shooter can only send a disc though it every 500ms at best or every 1 second on avg? See where I am going?

To each is his own. We use a PID class that finishes computation in 1-2ms. using the system clock and provided recovery times just under 1 second last year, and about 2.5 seconds from stop.

My opinion is nothing I have seen thus far in FIRST requires a faster software timer, especially since everything we do has an end result to move some physical mass, which couldn't react faster than milliseconds anyway.

I would love a nanosecond timer but its more of a want, I don't see the requirement for one.

Originally Posted by Ether

Here's a link to the use of micro-second timer to measure the exit speed of the frisbee from the shooter. A highly accurate feedback signal of frisbee exit speed would make it possible to tune the shooter wheel speeds to maintain consistent frisbee speed.

Would be interesting to see if teams actually do this on the fly. This problem is not completely controllable since you are not actively controlling all variables which control muzzle velocity. Compression, surface friction, and wheel contact time all play a huge role in muzzle velocity, but you would only be controlling wheel speed. Furthermore, there is some point you reach diminishing returns, because the faster your wheel, the lest time they are in contact with the disc, so less energy is transferred.

[Ether]

Sampling the signal does not provide any lag... I do not understand what you mean by average, because the points are not being averaged.

Averaging causes lag. Speed is your process variable, not counts. 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, not the instantaneous speed at the moment of sampling. It's effectively a low-pass filter, which introduces lag. That average speed lags the instantaneous speed, if there was any acceleration taking place during the past 200ms.

If instead you use the WPILib GetPeriod() method, this happens:

1) the FPGA returns the elapsed time (measured with the FPGA's 1MHz clock) between the most recent N+1 counts detected, then

2) WPILib divides that elapsed time by N.

You can then use this in your code to calculate speed. Using this method, you don't need to average the speed over seven and a half revolutions to get a clean signal. One-quarter of a revolution will given you a clean speed signal, with less phase lag.

I can shorten my sample time in order to reduce lag.

Sure you can. But your computed speed will get noisier, due to the 1ms resolution of your timer and the discrete nature of the counts.

I have never been able to get a clean signal from the period() function.

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 haven't looked into why the getPeriod() function produces a signal so noisy

I have. At high speeds with many CPR, the FPGA 1MHz timer and 153KHz polling frequency aren't fast enough to measure the elapsed time between just 2 counts without introducing excessive jitter. That's why you need to configure the FPGA to return the elapsed time between the N+1 most recent counts, instead of the most recent 2 counts, when using an encoder. If you use a one-per-rev counter, the FPGA default value N=1 works well.

why do i need to ask for a speed signal every 10 milliseconds? The Driver Station Packets are sent every 20 milliseconds, so any calculations done faster than that, are simply being thrown out and not making its way to the robot.

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.

As for the control of bang-bang, It is a good way to control velocity of the wheel for its simplicity, but you need to manage the oscillations around the setpoint.... You are ignoring inertia

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.

I would love a nanosecond timer

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

[Joe Ross]

Originally Posted by Ether

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

I haven't been able to find that implemented in java.

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

[Ether]

Any recommendation for a new averaging value?

edited excerpt from one of my earlier posts:

...use only one channel of the encoder, and configure the FPGA to count only the rising edges of that channel and to report the period based on the elapsed time between the 126 most recent counts (i.e. set the FPGA averaging to 125 samples). You would use the GetPeriod() method of the Counter class to get the period. At 2300 rpm you should get single-digit rpm jitter (+/-3rpm) with this setup, and with only 1/4 of a rev lag instead of seven and a half revs. You could ask for speeds at a 10ms rate and get a fresh reading each time.

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.

I thought that went without saying.

You are taking what I said out of context.

Not intentionally. I was responding to what I thought you were saying. My point was: with enough load inertia and a fast enough execution cycle, you won't have the oscillations you seemed to be concerned about with bang-bang. Once you've got something working, you can slow the execution rate down if you like, but bang-bang is so short and simple it shouldn't be a problem to run it fast (unless there's excessive overhead in Java to do so).

GetPPCTimestamp(). Not available on Java.

I'm not a Java guru. Can't you write a short assembly routine and ask the Java VM to run it using JNI?

[sjspry]

I generally don't go and make my own spoon before I go to eat some soup.

That being said, I have tried to strongarm the Squawk VM running on the cRIO. An instance of Timer will handle execution of all of its TimerTasks. If you want, you can make instances of Thread and run them asynchronously from the main robot code. I would point out that you can't really guarantee the length of a timeslice unless you have ring 0 privileges. In this case, you could argue ring 0 privileges are JVM-level, but the JVM has a lot of overhead (compared to modern ones). I would say a timeslice of less than 15ms will be impossible to guarantee.

And everyone seems to bring up JNI. Has anyone who says that actually tried to use it? It'd be even harder on something like a FIRST-compliant cRIO, where you have huge restrictions on what you can do with the thing (not saying it'd be impossible, but more of a pain than usual).

[Ether]

Originally Posted by sjspry

That being said, I have tried to strongarm the Squawk VM running on the cRIO. An instance of Timer will handle execution of all of its TimerTasks. If you want, you can make instances of Thread and run them asynchronously from the main robot code. I would point out that you can't really guarantee the length of a timeslice unless you have ring 0 privileges. In this case, you could argue ring 0 privileges are JVM-level, but the JVM has a lot of overhead (compared to modern ones). I would say a timeslice of less than 15ms will be impossible to guarantee.

What is the context for the above? Are you just sharing some thoughts, or are you responding to something somebody posted in this thread?

[sjspry]

I'm trying to say that this whole argument is basically futile because of the lack of control you have over the JVM and its scheduling. What control you do have you can not apply to the precision that is wanted.

Most tasks should be run by a Timer as TimerTasks. If you want to try to run something faster, use a Thread, but you will not be able to guarantee execution timing.

[Ether]

Originally Posted by sjspry

I'm trying to say that this whole argument

Which "argument" are you referring to? There are many different things being discussed here; many of them are not rendered pointless by your scheduling comment.