Quote:
Originally Posted by ozrien
We could have baked in a thread task into the CANTalon class, but I thought this would be a simple way to ensure there are no reentrancy or other thread-related issues without requiring much more testing/complexity.
I also did not want teams scapegoating a talon thread as the reason why their heavily threaded FRC program is not working or why their CPU utilization is high.
Additionally we did not want to assume what the correct frequency to call was, however the function itself is pretty fast (does not considerably block).
This could change in the future. I figured only advanced users would use motion-profile, and most users would use motion-magic since you don't need to create a profile by hand (instead you set PIDF gains and cruisevel/accel to quickly get motion control).
|
Thanks for the quick reply. Would this even have to be baked into the class? Would it be possible to do this logic entirely on the talon? Maybe then the API would be something like:
Code:
_talon.setMotionProfileUpdateRate(int ms) //tells the talon how frequently to process its motion profile buffer.
_talon.startProcessingMotionProfile() //tells the talon to start processing its motion profile buffer.
Then we could use _talon.getMotionProfileStatus(_status); to determine if the MP has finished running.
One of the Talon's greatest advantages is the parallel processing it brings to FRC. If I could give a talon a MP, tell it to follow it, and check back in to determine when its done, I'd be sooooo happy.