[BradAMiller]

Originally Posted by The Lucas

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.

We are hoping to do some classes to help start and manage tasks. It will make it easier to cleanly shut down at the end of the program. Teams may also call the VxWorks functions directly if they desire. One of the challenges for teams choosing to use the multitasking features will be managing priorities and doing synchronization. It can get thorny.

So in the library, how can the programmer declare a object/method/function as a separate task (process)?

In VxWorks you just supply a function that runs as the new task and a bunch of parameters that are passed to it. Our class will do the same thing.

How do you set priority among these tasks? Is it an object attribute?
What about inter process communication? A message class?

VxWorks lets you set the priority on task creation and you can modify it with a function call.

No plans right now for messaging or interprocess communication. Good opportunity for a team contribution.

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)?

This is pretty much the same as before - you can read the driver station while disabled. There is a lot of support in the library to help robot programs detect the field state and deal with it.