Consistent Encoder RPM Issues

[meltbox360]

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.

[Ether]

Originally Posted by meltbox360

I recompiled WPILib...

See Kevin's recent post:

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

[Kevin Sevcik]

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.

[meltbox360]

Originally Posted by Kevin Sevcik

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.

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.

[meltbox360]

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.

[Ether]

Originally Posted by meltbox360

Should I go and try to smooth it further before attempting bang-bang

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.

[meltbox360]

Originally Posted by Ether

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.

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

[meltbox360]

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.

[Tanaythan]

Originally Posted by meltbox360

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.

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.

[DjScribbles]

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

[nightpool]

Originally Posted by Ether

Indeed. At frisbee shooter wheel speeds, many teams have had excellent results with one-count-per-rev sensors (optical and magnetic). One-count-per-rev sensors don't require changing the FPGA sample ring buffer default size.

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.

[Ether]

Originally Posted by nightpool

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.

At what RPM?

[nightpool]

Originally Posted by Ether

At what RPM?

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.

[Ether]

Originally Posted by nightpool

Around 3600.

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

What's the response time of that Rockwell photosensor?

[nightpool]

Originally Posted by Ether

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

What's the response time of that Rockwell photosensor?

About 1ms IIRC. This is mainly estimates though.