[Bryan Herbst]

The good news is that the WPI Library is all open source, so you can look at all the bits and pieces to find many of the answers to these questions.

You can find the source code at usfirst.collab.net.

Originally Posted by David Lame

I understand the basics of how FMS interacts with the robot. It calls the init function when it enters a new phase, and it calls the periodic function periodically while in the phase. I've read that it calls the periodic function every 10 milliseconds, but I don't know if that's correct, and I've never timed it.

There isn't a set rate at which the periodic methods are called.

If you open up the IterativeRobot class, you will find that there is a big infinite loop that checks which state the robot is in, and calls the appropriate periodic method whenever nextPeriodReady() returns true.

As per the documentation on that method, this happens whenever a packet is received from the driver station, which should be about 20ms (50Hz).

Originally Posted by David Lame

Now what I'm wondering is what really happens if you do things that take up a lot of processor time, or perhaps just clock time.

For example, if you write in teleopPeriodic()
{
Thread.sleep(15);
}

when will the next call be made to teleopPeriodic() be made? 15 milliseconds after the last one? 25 milliseconds?

Assuming the robot received a driver station packet during that 15ms that your code was sleeping, it will be called again immediately (well, as soon as execution can iterate through the control loop again).

Note that the DriverStation instance used by the RobotBase to update your robot polls for updates in a separate thread, so sleeping in your code won't delay any incoming packets from the DS.

Originally Posted by David Lame

And then there are threads. There are certain things that come up that I know must be multithreaded behind the scenes. (E.g. PIDControllers)

Can I set up my own threads? There's a control loop that I am thinking about using, but 10 milliseconds between updates is too slow. If I just launched a thread to take care of that, could I update it much faster?

Yes you can create your own threads. Just as you would in any other Java program, you can simply create a new Thread object and call start() on it.

As to whether you can make it update much faster- maybe.

First, I urge you to consider the physical limitations of your robot. Even if your code is attempting to do something every 1ms, can your robot physically do anything meaningful in that time?

Second, your motor controllers have technical limitations as well. Here's the Talon SRX documentation. The default control frame period (i.e. the maximum rate at which it accepts new input) is 10ms (see section 20.6), and the smallest you can go is 1ms. However, going down to 1ms increases CAN bus utilization by 15% (see section 16.23). There are tradeoffs to consider here.

You also have to consider RoboRIO CPU usage- the faster one thread is updating, the slower another thread is updating. Watch your CPU utilization carefully to make sure you aren't starving more important threads of resources.

Originally Posted by David Lame

And loops? What if I code an infinite loop in autonomous.

autonomousPeriodic()
{
while (2+2==4)
{
System.out.println("I am still in autonomous");
}
}

Will that mean that it will run forever, and teleopInit() will never be called?

Yes that code will run forever.

Note that motor controllers may have certain safety features enabled (see here). In addition to individual speed controller watchdogs, there is a system watchdog that will disable all output if it doesn't get feed for 125ms.