Our team in off season programming has discovered what we feel is a bug in the task management software. We wrote a simple program to test tasking. This program simply uses an integer counter to determine when to start and stop a task. The value of the counter is also written to the screen. When we run the program without including "joystickdriver.c", the software runs as expected. If we include "joystickdriver.c" both the main and the secondary task start at program startup. We do not have to actually start the secondary task.

The only workaround we have found is to put a waitforstart() call in both the main and secondary task and make the first executable line of the main task a call to stop the secondary task.

See below for our code

SSI, I'm not sure if you realize that you are going to blast through your main loop and overflow the heartbeat many times per second. So you are essentially starting and stopping the task many times per second. You probably need to add a wait1Msec(1) in the loop.

cu,
Gary

Gary,

Thanks for the reply. Actually the print to the screen slows it down enough to be able to tell what is going on. In actuality this program is useful only to demonstrate the problem. We noticed the problem in a different version of the program. The other version was designed to start the secondary task right after the waitforstart() call. At the time, we had other code in to drive the robot. We removed that code to make it easier to remove the include of joystickdriver.c (ie to eliminate compile errors). If the screen display was not there, then I agree it would probably be tough to catch what is going on. The primary point is that if we have a waitforstart() call as the first executable line in the main, then task1 should not start until the start command is received by the robot. The servo should not be moving while the robot is waiting to start.

Hi,

I checked your code and was able to confirm what you have noticed. However this is far from a bug.

In "joystickdriver.c" there is a line of code near the top:
This is what is causing your tasks to start right away.

However you can't just comment that line out because it serves a very important purpose; it auto starts all of those game control tasks so that the user doesn't have to worry about starting them in their own programs.

An easy solution to this would be to include "StopTask(task1);" at the beginning of your task main. This way, even though in the very first few milliseconds, task1 is being initialized due to the code in "joystickdriver.c", it will immediately be stopped and will not be started again until your code says that it's time to start.

Try adding "StopTask(task1);" at the beginning of task main and see if it helps.

bfeher,

Thanks for the reply. I was poking around in the joystickdriver.c file this morning also and found that line. The comment indicates that it is just for the tasks listed, apparently it is for all tasks. Does RobotC have a way to only autostart specific tasks? Unfortunately, the work around you suggested is not quite enough. As I stated in my original post, we had to place a waitforstart() in both the main and the secondary task to prevent servo movement. Given a more complicated secondary task, your solution may be enough. Since our first executable statement is basically a command to move the servo, the servo is able to move before the main is able to stop the task.

Obviously, the best solution would be for the joystickdriver.c file to only autostart it's requied tasks.

This discussion has brought up another somewhat related question. When RobotC stops then restarts a task, does it truly stop the task and then restart it from the beginning or does it merely suspend the task and then re-enable it? Most of the time, it probably won't be a problem if a task is suspeneded vs. stopped and restarted, but with our luck we would create a routine that it would make a difference.

When you stop a task, it is stopped, not put to sleep. So restarting it would be like it was started for the first time. Remember that functions in ROBOTC are not re-entrant, so it is up to you to make them thread safe.

As for autostarting tasks, I believe there is a pragma for that. However, it doesn't allow you to specify which task to autostart as far as I am aware of.

- Xander

As a possible compromise, you could test commenting out the autostart pragma in JoystickDriver.c and then adding some code at the beginning of your main task that would individually start the necessary task(s) in JoystickDriver?

If it works, then it could be refactored some so that the FTC template would include a call to a new startTasks() function in JoystickDriver.c as part of the existing initialize() function.
This seems preferable to breaking the tasks model (requiring teams to remember to stop their tasks before they start them).

Of course I prefer the idea of enhancing the autostart pragma to only start certain tasks better.

Xander,

Thanks for the information regarding stopping and re-starting tasks. That was the answer I was hoping for. Also, thanks for all the work you do on the third party drivers. They have been very useful (although I would love to have access to the code to see if it is possible to tweak a few things, it would be great to be able to float the DC motors individually or at least by motor controller).

IOjec,

We will try that to verify what you suggested although I am sure that it would work. When we did not include the Joystickdriver.c file, everything worked as expected. I agree, it would make more sense to put the start tasks in the initialize routine. Of course, it would be even better if RobotC could be modified to add an optional parameter to the task definition. If the parameter was present and true, the task would autostart. If the parameter was not present or false, then they would not autostart.

Thanks again all.

I'd like to chime in here on the side of not having such a thing as an "autostart" pragma. There are way too many problems, not the least of which is what you are seeing here, where simply including a module breaks other modules.

Another big problem is "in which order should these tasks be started?" That's a huge problem that simply doesn't exist when tasks are started explicitly only when they are needed.

I'd recommend getting rid of "#pragma autostart".

cu,
Gary

Good points.
A flexible system for auto starting would almost need a deployment descriptor level of detail (start these tasks, with these priorities, in this order, etc.). For the target audience of ROBOTC, that seems impractical (to me at least) and is likely why they attempted a simplified approach (start everything).

I agree then that the best approach may just be to remove the autostart pragma and allow tasks to only be started/stopped programmatically.
For FTC and the background tasks in JoystickDriver.c, I think adding default code to start the tasks in the FTC template is a reasonable solution. We already require students to import JoystickDriver.c and to manually get the latest joystick state; both which are already done for the students in the FTC template. With that in mind, adding something to start the tasks in the template wouldn't seem too disruptive or confusing to me.

There was a bug in the "autostarttasks" pragma that has just been fixed for the 2010-11 season release. It was incorrrectly being applied to all tasks instead of just the tasks in the file containing the actual pragma

Dick, sounds like that will work for us.
Thanks for the update.

This sounds like it will take care of our problem.

Thanks again for a great product. We definitaly believe RobotC helped us get to the winning alliance at the World Championship.

David