Configure Timers

[Phalanx]

We're trying out JAVA this year on our Robot after using Labview the last few seasons (not ask)...

In Labview we use the Configure Timer VI's to set the number of samples for averaging when using encoders or counters for speed control.

We can't seem to find the equivilent Method Call in JAVA.
Anyone know if this exists or do we have to write our own averaging?

[Phalanx]

Never Mind. Found my answer. Not available in C++ and JAVA.

http://www.chiefdelphi.com/forums/sh...7&postcount=24

[Ether]

Originally Posted by Phalanx

Never Mind. Found my answer. Not available in C++ and JAVA.

http://www.chiefdelphi.com/forums/sh...7&postcount=24

Read this follow-up post:

http://www.chiefdelphi.com/forums/sh...3&postcount=29

It's not hard to do. A fairly simple change to the WPILib source code.

[Phalanx]

Thanks Ether. We'll look into modifying the encoder and/or counter class(s).

[sjspry]

You can use the TimerTask and Timer class, like we are doing. It will fire off a TimerTask's run() method every x milliseconds.

[Ether]

Originally Posted by sjspry

You can use the TimerTask and Timer class, like we are doing. It will fire off a TimerTask's run() method every x milliseconds.

Just curious: Have you ever measured the scheduling jitter? e.g. add code to toggle an IO pin at the start of the run() method and look at the pin on a scope.

[NotInControl]

Originally Posted by Ether

Just curious: Have you ever measured the scheduling jitter? e.g. add code to toggle an IO pin at the start of the run() method and look at the pin on a scope.

I have, and the worst I have seen is 2 ms of jitter, measured on the cRIO using the System Timer. This was both running at a 40ms period and a 100ms period, where the run() method had a 1ms calculation time.

So for example, if I was running something with a 40ms period, It would actually run between 38 - 42 ms, but for the most part the cRIO was pretty good about keeping it constant 40.

All of the threads I run on the robot use the TimerTask class. The timer task does not preempt the running thread, if they are at the same priority so keep that in mind, it will affect your thread execution.

[Ether]

Originally Posted by NotInControl

The timer task does not preempt the running thread, if they are at the same priority so keep that in mind, it will affect your thread execution.

Two questions come to mind:

1) Do you put code in each of your threads to monitor throughput margin and re-entrancy ?

2) Are there other scheduling options in FRC Java which will provide concurrent processing of same-priority threads ?

[NotInControl]

Originally Posted by Ether

Two questions come to mind:

1) Do you put code in each of your threads to monitor throughput margin and re-entrancy ?

Yes, I do, it is not necessary, but I just do out of habbit for all my embedded projects.

Especially when I run embedded code on an operating system that doesn't guarantee timing, I always put code in in there to monitor the execution of each state.

Unfortunately, the SwawkOS doesn't support :

System.nanoTime()

so timing is only good to the millisecond from:

System.currentTimeMillis();

but milli second accuracy is good enough for anything we will need to do in FIRST for sure.

Originally Posted by Ether

2) Are there other scheduling options in FRC Java which will provide concurrent processing of same-priority threads ?

When you use the TimeThread task, it doesn't run automatically, you need to create a separate scheduler which runs the task based on the periodicty set.

Something like:

		
this.executor = new java.util.Timer();
this.executor.schedule(new MyTimedTask(this), 0L, this.period);

There are different types of properties you can set on the scheduler. By default the scheduler doesn't preempt the running thread so lets say you kicked off a TimedTask thread, and then you entered this block of code after:

while(true)
  system.out.println("Hello World");

running as fast as it could, you would see that your timer task would not run at your set period, it would only get to run, between timesclices of the while loop that the cpu was free for an instance of time.

However, for JavaFRC you can use other properties of the Timer Task to control your concurrancy. For example you could use the scheduleAtFixedRate method of the TimerTask, which i believe does preempt the running thread to try and guarantee execution. (I never tested it however).

The better way to do it in a normal J2ME project would be to set the priority of all of your threads. Using the Thread.setPriority() and Thread.getPriority() functions and the Thread.xxPRIORITY static fields. You can have up to 10 levels of priorities. Where Higher priorities will pre-empt lower ones. However these methods are not supported by Squawk JVM for FRC, and all threads in FRC Java are created with the same NORMAL priority.

The best way to do it JavaFRC would be to avoid the need for preemption and try to ensure your code is optimized and runs in a period that is reasonable so that the CPU can be shared between all normal priority tasks. If all of your JavaFRC threads have relatively small execution times compared to its period, (and they should), then all your threads should have enough access to the CPU to run within its within its periodicity.

Java VM in general is not a real time OS, so timing is never truly guaranteed, no matter what we do. Most of the inconsistencies arise when you have threads that are relying on preemptive behavior, instead of cooperatively giving up CPU time.


Hope that helps,
- Kev

[Ether]

Originally Posted by NotInControl

milli second accuracy is good enough for anything we will need to do in FIRST for sure.

Thanks for your informative post. Let me take issue with the point above.

It's not good enough for accurately measuring the speed of a frisbee-shooting wheel using the counts/time method.

It's not good enough to measure the linear speed of a frisbee as it exits the shooter on your robot.

[NotInControl]

Originally Posted by Ether

Thanks for your informative post. Let me take issue with the point above.

Your very welcome!

Originally Posted by Ether

It's not good enough for accurately measuring the speed of a frisbee-shooting wheel using the counts/time method.

I am not sure what you mean by this. This is a "Too each his own" problem. How accurately do you think you need to measure the speed of a wheel? And what would happen if you were off by a couple RPM? Can you over come this by other robust code?

I come from the defense world where if timing is inaccurate people could loose their lives. We obviously don't have that problem in FIRST was my point and I believe our problems in FIRST can afford less accuracy in our software timers, which was the point I was making.

I have never observed good performance from the default encoder rate method but I have written my own encoder Rate codes with performance of +/- 3 rpm without averaging samples, where loop times were ~200ms, and that is way better than I need it for anything I need to do with a shooter wheel. What is your desired accuracy that calculating the speed of a wheel using time measured in milliseconds is not allowing you to achieve? What is driving this accuracy?

Here is some psuedocode from my 2013 robot giving the performance I stated above with a 500PPR encoder @ 2300 wheel speed. It is a class which extends the encoder, which is why it uses Super.

	public double getRPM()
	{
		
		//getRate
		timeNow = System.currentTimeMillis();
		countNow = super.get(); //calls encoder.get method
		rate=(countNow-countBefore)/(timeNow-oldTime); //counts per millisecond
		oldTime=timeNow;
		countBefore=countNow;

		//return average
		return rate*1000*60/PPR; //... rpm
	}

Originally Posted by Ether

It's not good enough to measure the linear speed of a frisbee as it exits the shooter on your robot.

Again how accurately do you need to measure this?

System.currentTimeMillis() is a software timer. To measure linear speed of the disc you need something which can provide you external readings first. If you had for example two IR line sensors in the path of the disc a set distance apart. Saved the time each IR sensor was crossed by the disc and then calculated the Velocity using distance over time, your saying the accuracy you would get from that wouldn't be good enough because the time measured was in Milliseconds? Not good enough to accomplish what exactly?

[Ether]

Originally Posted by NotInControl

my 2013 robot giving the performance I stated above with a 500PPR encoder @ 2300 wheel speed

What brand and model encoder is that?

[NotInControl]

Originally Posted by Ether

What brand and model encoder is that?

That response didn't really answer my questions above. But to answer yours information on the encoder in question can be found here:

http://www.robotshop.com/productinfo...-38&lang=en-US

It is an encoder I like to use on my personal projects. It won't be the final encoder we use on our Robot this year. The final encoders we use this year will be a GreyHill 256 PPR.

Hope this helps,
Kev

[Ether]

Originally Posted by NotInControl

That response didn't really answer my questions above.

In order to prepare a thoughtful analytical response, I needed to gather some technical information to clear up some ambiguities in your post.

But since you're in a hurry, I'll just ask you for clarification instead of taking the time to research it myself.

When you use the term PPR, what do you mean by that? Do you mean the same thing that US Digital does (see attachment)? Or do you use the term PPR to mean what US Digital calls CPR?

GrayHill specs their encoders in CPR, not PPR, and they define CPR the same way that US Digital does.

So is your "256 PPR" GrayHill encoder 256 CPR or 64 CPR?

And is your "500 PPR" Cytron encoder 500 CPR or 125 CPR?

If you don't have this info, I will respond to your post without it, but my response will be in generalities and therefor less useful I would think.

[NotInControl]

Originally Posted by Ether

In order to prepare a thoughtful analytical response, I needed to gather some technical information to clear up some ambiguities in your post.

But since you're in a hurry, I'll just ask you for clarification instead of taking the time to research it myself.

Not a problem, I am not really in a hurry, I am just curious, and as build season winds down your insight and viewpoint may show something we are overlooking when solving this problem, or an oversimplification we are applying which may be inaccurate for some reason.

I believe I have all bases covered but I won't know for sure until you share your perspective and reasoning. But I do appreciate you taking the time to formulate a complete answer... so thank you.

Originally Posted by Ether

When you use the term PPR, what do you mean by that? Do you mean the same thing that US Digital does (see attachment)? Or do you use the term PPR to mean what US Digital calls CPR?

GrayHill specs their encoders in CPR, not PPR, and they define CPR the same way that US Digital does.

So is your "256 PPR" GrayHill encoder 256 CPR or 64 CPR?

And is your "500 PPR" Cytron encoder 500 CPR or 125 CPR?

If you don't have this info, I will respond to your post without it, but my response will be in generalities and therefor less useful I would think.

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 however,

When I use the Term PPR, as in Pulses per revolution, I mean it in terms of the square wave being generated. A Pulse in my definition is a complete rising edge, width, and falling edge.

Therefore, if you are counting all rising and falling edges, a single pulse produces 2 counts.

If the encoder is quadrature, there are two digital outputs each generating its own pulse. Therefore if you were to count all rising and falling edges from a quadrature encoder, each pulse would return 2 counts but you have 2 pulses to deal with so the total is 4 counts.

So in my definition, a quadrature 500PPR, can produce 2000 counts per revolution when counting all rising and falling edges on both channels.

I believe GreyHill defines this as Cycles Per Revolution (CPR) which is another term used in industry but means the exact same thing as my PPR. I avoid using CPR because unless you are intimately familiar with the definitions you may confuse CPR to mean "Count Per Revolution" (or at least I would, and that is completely wrong).

So the GreyHill 256 Cycles Per Rotation encoder I mentioned would produce 1000 counts per rev if you were counting the rising and falling edge of each signal. or as I call it 256 Pulses per revolution (On a Single Channel).

Does that clarify things and answers your question?

Hope that helps,
Kev