Re: Consistent Encoder RPM Issues
 

I'm back. About to get to testing the code but I recompiled WPILib with the Java code diffs you gave me translated to C++

I will post back as soon as I have a result. I'll also post up what I changed if it works.

Re: Consistent Encoder RPM Issues
 

See Kevin's recent post:

http://www.chiefdelphi.com/forums/sh...8&postcount=28

Re: Consistent Encoder RPM Issues
 

To follow up on my post, the single best reason for pulling out a copy of Counter.cpp and Counter.h is so you can easily stay up to date with WPILib releases that don't affect the Counter class. If you're recompiling WPILib, then you'll have to re-modify it and recompile it every time there's a new release.

Re: Consistent Encoder RPM Issues
 

I was not aware that was possible. Thanks. You would however have to be careful to track any changes in files you pull out to ensure you have the latest version of those files. For example pulling out networkTables I think would have resulted in you not getting some of the updates in the latest release. It unfortunately works two ways.

If you make sure to manage it then pulling out the files id likely the better solution.

Re: Consistent Encoder RPM Issues
 

Wonderful it is fixed. I am seeing jitters of around 30 rpm now. This is absolutely wonderful. Should I go and try to smooth it further before attempting bang-bang or should I dive into that now. Thanks for the help couldn't have done it without you guys!

EDIT: My error is about .5% right now which I believe is good enough.

Re: Consistent Encoder RPM Issues
 

Do not filter the signal going to bang-bang. Bang-bang does not like phase lag.

If you haven't seen it already, you might want to peruse this paper.

If bang-bang doesn't work for you, try Take Back Half.

Re: Consistent Encoder RPM Issues
 

Thank you. I will post back when I have results along with the modified WPILib source files.

Re: Consistent Encoder RPM Issues
 

Looks like a simple way to do it however I am wondering if anyone knows of a simple way in vxWorks of starting a thread that does some task every some miliseconds. iterativeRobot is a little late to switch to at the moment (I think). I know platforms like QNX can do this with timers. Perhaps it is not necessary but it is nice to ensure consistent performance.

Re: Consistent Encoder RPM Issues
 

There is a notifier class in wpilib that you can use. It spawns a new thread every few milliseconds. To reference the code it is used in the pidcontroller class.

Re: Consistent Encoder RPM Issues
 

In my bang-bang controller, I used a task (specifically jankyTask, courtesy of Bob.Wolff in this thread: http://www.chiefdelphi.com/forums/sh...ght=Tasks+in+C)

I setup the SetTargetRPM of our shooter, to use the RPM to compute a target_period, and in the task I read the period from the counter class, and compare it to the computed target period, if the period is above target set the motor to 100%, if the target is below I set 0%. I only call motor.Set if the motor command has changed from the previous run (since the set carries a good bit of overhead).

In addition, I've added some code akin to the take-back-half suggested by Ether. When we trigger our shot, I disable the bang-bang control and set a constant 50% power for a short time; this addition seemed to help our shot consistency, but it's a bit of a hack :)

Edit: I can provide source code if you like, but I didn't want to spoil the fun

Re: Consistent Encoder RPM Issues
 

Indeed. Our team dodged a bullet this year as our physical shooter design made it impossible to put a traditional encoder on and we had to figure out an alternative earlier in the season. It turned out to be very easy to use a normal Rockwell photoeye and a piece of white tape to measure shooter speed. The only biggish change we had to make was our own subclass of Counter to make it work with the WPILib PID controller, but that was pretty trivial, just like 15 lines of code.

The one thing to watch out for is the size of your flag (the tape or what have you). Too small and you might not see it as it flashes past. We had good results with about 30 degrees of coverage.

Re: Consistent Encoder RPM Issues
 

At what RPM?

Re: Consistent Encoder RPM Issues
 

Around 3600. We're probably going to be replacing the 5:1 bb on our shooter with either a 4:1 or a mini-cim though, so I'll update you guys on how that works.

Re: Consistent Encoder RPM Issues
 

That's about 1.3ms (with 30 degree coverage).

What's the response time of that Rockwell photosensor?

Re: Consistent Encoder RPM Issues
 

About 1ms IIRC. This is mainly estimates though.