RPM calculator

[cooltext]

I have the AS5030 rotary encoders and I was trying to find a way to calculate the RPM of our shooter motors with it. Does any one have any idea how to do so? I tried the counter class but I am having trouble selecting the

AnalogTriggerOutput.Type triggerType to use and how to calculate what voltage limits I should use for kTypeState.

Also how could I make it so it had a very small sampling time like .1 of a second?

[dbeckwith]

Try just using the Encoder class. That should have everything you need. Just make sure you use setDistancePerPulse() with the right units and you can get the speed (this class gives speeds in units per second, not minute, but you can always scale it).

[Joe Ross]

Try just using the Encoder class. That should have everything you need.


The AS5030 is not a quaderature encoder. It won't work with the encoder class.

[joelg236]

The AS5030 is not a quaderature encoder. It won't work with the encoder class.
And what would you suggest then? That was not helpful.

[Ether]

And what would you suggest then? That was not helpful.

Well, it helped him avoid wasting time going down a rabbit hole.

A bit of advice, if you are open to it: as a newcomer you might want to be a bit more respectful, especially with people like Joe who have helped countless people over the past 10 years.

[cooltext]

Thanks for your replies, but I was just wondering if anyone had any ideas for the RPM issue?

thanks
Dimitir

[Ether]

Thanks for your replies, but I was just wondering if anyone had any ideas for the RPM issue?

You could try opening the P1 solder bridge and connecting the JP3-1 Cos signal to DIO and use the Counter class. Not sure if that would work. Has anyone tried it?

Or you could use a sensor more suited to your purpose.

[ProgrammerMatt]

The encoder class works with both i belive..
if so

Encoder myencoder = new Encoder(#);

myencoder.getRate();


the the rate works off ticks per secound you need to scale it down.

[dbeckwith]

The encoder class works with both i belive..
if so

Encoder myencoder = new Encoder(#);

myencoder.getRate();


the the rate works off ticks per secound you need to scale it down.

No, I think Joe is right. The Encoder class is for quadrature encoders which use two signals, and this encoder the OP is trying to use only has one signal and if I'm not mistaken produces a different type of signal (the way it counts rotation is different). It's unfortunate that there's no built-in FRC class for those encoders though.

[Ether]

According to the operation manual for the AS5030 adapter board, if you open the P1 solder bridge you can access cos&sin quadrature signals at JP3 pins 1&3. Not sure if the WPILib Encoder class will work with those waveforms without some signal conditioning. Has anyone tried and succeeded?

[Ether]

You could try opening the P1 solder bridge and connecting the JP3-1 Cos signal to DIO and use the Counter class. Not sure if that would work. Has anyone tried it?

Apparently someone has tried it, and was successful. See Post#3 in this thread:

https://decibel.ni.com/content/thread/11955

[ProgrammerMatt]

Does it output analog or digital? if its digital try using the Counter class, if its analog then use something like

int count
if(encoder.getVoltage() >"voltage when ticked") {
count = count + 1; // or count ++;


P.S i would think it is digital but if its not try that /\

[mwtidd]

Get rate is not ideal.

We store a last time variable.

Take counter.getdistance / (current time - last time)

Then reset the counter.

You will get a much stabler speed this way

[ProgrammerMatt]

Get rate is not ideal.

We store a last time variable.

Take counter.getdistance / (current time - last time)

Then reset the counter.

You will get a much stabler speed this way


this is straight out of the encoder class

* Get the current rate of the encoder.
* Units are distance per second as scaled by the value from setDistancePerPulse().


its practically the same as current time - last time

[Ether]

...its practically the same as current time - last time

GetRate() computes the rate based on the elapsed time of a single encoder pulse (the most recent one).

This is manifestly not the same as the computing the rate using delta counts since the last sample and dividing by the elapsed time since the last sample, for sample periods on the order of 20ms and encoder pulse periods associated with shooter wheel speeds.

[Brian Selle]

To calculate the delta time in Java do you use System.currentTimeMillis() before or after getting latest count or is there a better timestamp that is associated with the time the encoder count value was actually taken?

[Ether]

To calculate the delta time in Java do you use System.currentTimeMillis() before or after getting latest count or is there a better timestamp that is associated with the time the encoder count value was actually taken?

If you are using a 360 count per rev encoder on a wheel spinning at, say, 4000 rpm, and you are sampling at roughly 20ms, then the delta count per sample would be 480. One count out of 480 is 0.2% so you probably don't need to worry about that.

I suppose you could put the code to grab the encoder count and the system timer in a critical section to prevent getting swapped out between the two operations.

[Brian Selle]

I meant to ask if System.currentTimeMillis() is the best time source -or- is there some other timeStamp to use?

[Ether]

I meant to ask if System.currentTimeMillis() is the best time source -or- is there some other timeStamp to use?

Don't know about Java, but in C++ there appears to be a nanosecond timer in WPILib:

/**
* @brief Gives real-time clock system time with nanosecond resolution
* @return The time, just in case you want the robot to start autonomous at 8pm on Saturday.
*/
double GetTime()
{
struct timespec tp;

clock_gettime(CLOCK_REALTIME,&tp);
double realTime = (double)tp.tv_sec + (double)((double)tp.tv_nsec*1e-9);

return (realTime);
}

[Brian Selle]

Excellent! In the WPILib I just found:

Timer.java

/**
* Return the system clock time in seconds. Return the time from the
* FPGA hardware clock in seconds since the FPGA started.
*
* @return Robot running time in seconds.
*/
public static double getFPGATimestamp() {
return Utility.getFPGATime() / 1000000.0;
}

Utility.java

/**
* Read the microsecond timer from the FPGA.
*
* @return The current time in microseconds according to the FPGA.
*/
public static long getFPGATime() {
return tGlobal.readLocalTime();
}

Thanks!

[nickpeq]

I generally use System.nanoTime() for anything in Java. It's overkill, but I've never found a reason NOT to use it.
You could measure the dT that it takes to get the latest count and see how negligible it is. (or isn't)