Quote:
Originally Posted by BradAMiller
There are many ways of solving your issue with time-based algorithms like PID integration. One is to use the Notification class that will periodically call some function in your program. You can, for example, request notification every 20ms and do the PID calculations there. Even though it is not a true hardware level interrupt routine, the function can get the precise time and easily apply the appropriate weight as it's integrating the error value. There are many additional mechanisms that could be used for solving the same problem.
|
This touches on my primary curiosity:
How will the library implement multitasking and scheduling?
I think this the most significant change in the new system and the real challenge in an RTOS. There is a conflict between ease of programming (learning curve) and advanced functionality. I can see a need to abstract this issue away for the basic users who do not use utilize the CPU enough for it to be an difficult issue. However, the user with heavy vision processing (multi target tracking) and multiple PID loops will need low level access to the scheduling features to ensure deterministic performance.
So in the library, how can the programmer declare a object/method/function as a separate task (process)?
How do you set priority among these tasks? Is it an object attribute?
What about inter process communication? A message class?
Also since Day 1 I have been curious about how the disable/autonomous states will work across the control system as a whole. Specifically, can the driver station communicate with the cRIO in disable mode(as so many teams use to select auto modes)?
Thanks for the info
Brian