Hmm...How can I respond quicker to encoder input?

[SteveJ4564]

I've been searching the forums to get some insight into this problem, but haven't found a good solution yet.

We have a catapult system that is driven with a couple CIM motors, gearboxes, chains, and there's a rotary encoder on one of the gearboxes. Right now we have Jaguars driving this mechanism, with electronic braking enabled.

The concept is to apply full power to the catapult arm and accelerate the ball up until we reach a predetermined encoder count, which is the desired release point for the toss. A simple bit of Java code just watches the encoder and when the count has reached or exceeded the target count, set the motor speed to zero. By adjusting the target count, we can change the launch angle of the ball. Simple...

What we're finding is that the Java code is not running quick enough to keep up with the rapid arm movement. The control loop is running around 15ms, but at that rate the arm can move several degrees beyond the targeted stop before the code even notices it.

As a possible solution, I'm thinking of running a scheduled timer thread that does nothing more than watch the encoder count and stop the motors as appropriate. Would scheduling that to run once every millisecond be practical in the Java/cRIO environment?

Maybe there's a much smarter way to watch the encoder count and stop the motors. What other approaches might work?

Thanks for your thoughts.

Steve

[Ginto8]

If you're running your loop in teleopPeriodic(), your latency will probably be closer to 20ms (that's the default period). However, making a higher-frequency loop with a TimerTask is definitely feasible. 1ms, I'm not sure of, but what I'd do is bring it down to 10ms, then 5ms, and see how the CPU usage is affected (you can check that with the DS Log Viewer). As long as you stay below ~80%, you should be fine. You could push it higher if you're certain there won't be any occasional peaks that take up that 20%.

[Joe Ross]

The fastest you can change the PWM value going to the jaguar is 200hz.

Rather then doing everything in code, can you add a mechanical stop?

[Jared]

Originally Posted by Ginto8

If you're running your loop in teleopPeriodic(), your latency will probably be closer to 20ms (that's the default period). However, making a higher-frequency loop with a TimerTask is definitely feasible. 1ms, I'm not sure of, but what I'd do is bring it down to 10ms, then 5ms, and see how the CPU usage is affected (you can check that with the DS Log Viewer). As long as you stay below ~80%, you should be fine. You could push it higher if you're certain there won't be any occasional peaks that take up that 20%.

We used a TimerTask for our shooter control last year, and decreasing the loop time definitely made the shooter more responsive. As long as what's running isn't too complicated, you should be able to get the loop time down to 5 ms.

If you wanted to go even faster, you could make a new thread and call thread.yield(), so that it runs as fast as possible, without affecting your other threads.

[SteveJ4564]

Great feedback...thank you all.

I'll head down the TimerTask route. I might swap out the Jags for Victors, since the stated response time is quicker. As long as the response time is at a consistent rate, then we'll be able to consistently target a point to initiate a stop.

We will definitely have a physical stop, so the arm will not travel beyond design limits. Ideally, it will stop electronically, before it slams into the hard stop .

[RufflesRidge]

Originally Posted by SteveJ4564

I might swap out the Jags for Victors, since the stated response time is quicker.

According to what?

[Ether]

Originally Posted by Jared

you could make a new thread and call thread.yield(), so that it runs as fast as possible, without affecting your other threads.

Out of curiosity, does anyone know what the context switching overhead is for each of the 3 FRC supported languages?

[Alan Anderson]

Context switching speed is practically irrelevant for LabVIEW, as the language is parallel by nature. I can't think of a good reason for running something in a separate thread.

[yash101]

If I'm not mistaken, you also have the problem that the motor controllers don't have too high of a refresh rate (for what you want to do). I think you may find it better to do a mechanical stop to give the code some time to refresh.
You can move the stop with some window motors because they have a high torque and are worm-gear powered

[cmwilson13]

use can for the jaguars and use the on board position control on the jaguars