paper: Shooter Wheel Speed Control

[Ether]

Reading the encoder with the getrate from the labview getrate ntroduces a large amount of noise that counteracts any positive effect from the bang-bang (for us). What you suggest is how we started out, and there's a huge amount of error (+/-100rpm).

We'll play around a bit more at 10ms using our own rate calculation and not the FPGA. Perhaps that will improve our results.

I think there's a misunderstanding. When I said "read encoder counts from FPGA" I meant read the counts, not the rate. Then use those counts to compute the rate.

The important thing is to do the steps, in this order, one after the other, in the Timed Structure, at 10ms, with no other code in the structure:

1) read encoder counts from FPGA¹

2) use those counts to compute speed; do not filter²

3) send either 0.0 or 1.0 to motor controller³ depending on whether the unfiltered speed from step 2 is above or below the setpoint. no slew rate limiting (no voltage ramping)

... Then, if the above works, try using the GetRate() like Chris suggested, even if it's noisy²:

1) use GetRate() to get speed; do not filter²

2) send either 0.0 or 1.0 to motor controller³ depending on whether unfiltered GetRate() speed is above or below the setpoint. no slew rate limiting (no voltage ramping)

¹ read encoder counts using Encoder::Get() or Counter::Get() methods in the Encoder or Counter classes, respectively

² you can filter the speed signal for display purposes or to control other logic like when to shoot etc, but do not use filtered speed for the bang-bang logic for this test

³ try to send the motor command as directly as possible to the motor controller, bypassing as much overhead as possible which might introduce lag. disable "motor safe" and any other overhead in library code which sends the 0.0 or 1.0 command to the motor controller.