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