When the autonomous period ends, how do we call out the teleops program we would like to run? I've watched the webinars, and they tell me I need to call out the teleops program at the end of my autonomous code, but how do we do that? Is it as simple as just putting the name of the file at the end of the program, or is there a function we are overlooking?

Sorry if this is not very helpful, but try this link

Change the "Teleop Program Name" in your debug window. A text file is created on the NXT, and the FMS will switch automatically for you at the competition.

Why can't both autonomous and tele-op code be in the same program? The joystick struct has a flag indicating whether the FMS is in autonomous mode or not.

It's the way the field management system works. Even if you choose the same program for "tele-op" as you start for autonomous, during the "pause" period between modes, the FMS will restart your program.

OK, so the FMS will restart the program. If we combine both auto and tele in the same program, then the FMS will restart our single program and it will still work, right?

If so, would we still need to create the configuration file?

There additional discussions on this at http://www.robotc.net/forums/viewforum.php?f=33 but the last post makes no sense. If a single program is acceptable and works, then please post the complete single-program template.

Thanks

We created this single program template which follows all of the rules:

Jeff,

Your code appears to be a good approach to having a single program. Have you verified that it works with an FMS?

Also, have you experienced any problems when using tasks? Not that I am aware of any--we just haven't used yet.

Thanks.

--Bill Wiley

We were one of the teams that were chosen last spring to participate in the beta program and showcase tournament for the Tetrix platform. We have found tasks to be very useful and quite manageable. There are a couple of things that you should keep in mind when using tasks.

1) You can not call the same subroutine from more than one task. This is because all local variables are actually static globals rather than being on the stack.

2) If you have a function that you need to call from multiple tasks you can use the "inline" keyword in the function declaration. That will make the compiler insert the body of the function inline in the caller.

3) You should avoid trying to adjust the priorities of the tasks. Instead, each task should yield the CPU with a wait statement inside any loops. Notice the wait in the main task of my template for an example. Multiple tasks will still function if you do not use wait statements but it is always a good idea but a wait statement will immediately end your current time slice and allow another task to start earlier. Remember that there are bottlenecks when talking to sensors and so on that mean that a while loop can pole them far more frequently than they can update.

4) If you have a critical section you can surround it with HogCPU/ReleaseCPU. Do this ONLY when it is critical. For example if you need to swap two values that are used by a parallel task and want to make sure that the other task does not look at the values while they are changing you should hog the cpu, swap the value and then release the cpu.

5) Don't go task crazy. You should have a good reason for doing things in parallel.

6) Even if the only task you define is task main() there are actually multiple tasks running. The drivers for the various sensors and other hardware elements have background tasks that poll the hardware and update things. That is how the values in the sensor[] array get updated and how changes you make to the motor[] array actuall propagate to the motors.

You should notice that the main task in my template polls the game controllers so you will not have to do that in any other task. The "drive" task can just look at the "joystick" structure without calling getJoystickSettings() becuase it is being done by "main" in the background.

Jeff,

Great info. Thanks.

--Bill