View unanswered posts | View active topics It is currently Sun Dec 21, 2014 9:30 pm






Reply to topic  [ 13 posts ] 
Possible bug in task management 2.03 software 
Author Message
Rookie
User avatar

Joined: Mon Feb 23, 2009 12:40 pm
Posts: 27
Post Possible bug in task management 2.03 software
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

Code:
#pragma config(Hubs,  S1, HTMotor,  HTServo,  none,     none)
#pragma config(Motor,  mtr_S1_C1_1,     LeftMotor,     tmotorNormal, openLoop)
#pragma config(Motor,  mtr_S1_C1_2,     RightMotor,    tmotorNormal, openLoop)
#pragma config(Servo,  srvo_S1_C2_1,    StandOffServo,        tServoNormal)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

#include "JoystickDriver.c"  //Include file to "handle" the Bluetooth messages.

task task1()
{
    while (true)
    {
      servoTarget[StandOffServo] = 180;
      wait10Msec (50);
      servoTarget[StandOffServo] = 1;
      wait10Msec (50);
    }
}

task main
{
    waitForStart ();   // wait for start of tele-op phase
    int heartbeat = 0;
    int started = 0;
    while(true)
    {
        heartbeat++;
        nxtDisplayCenteredTextLine(3, "%d", heartbeat);
        if ((heartbeat > 10000) & (started == 0))
        {
            started = 1;
            StartTask (task1);
        }
        if ((heartbeat < 0) & (started == 1))
        {
            started = 0;
            StopTask (task1);
        }

    }
}


Mon Aug 09, 2010 7:52 pm
Profile
Expert

Joined: Mon Mar 15, 2010 4:24 pm
Posts: 124
Post Re: Possible bug in task management 2.03 software
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


Mon Aug 09, 2010 8:24 pm
Profile
Rookie
User avatar

Joined: Mon Feb 23, 2009 12:40 pm
Posts: 27
Post Re: Possible bug in task management 2.03 software
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.


Mon Aug 09, 2010 9:26 pm
Profile
Site Admin
Site Admin

Joined: Mon Jun 08, 2009 4:50 pm
Posts: 70
Post Re: Possible bug in task management 2.03 software
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:
Code:
#pragma autoStartTasks        // Automatically start this task when the main user program starts.

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.

_________________
Bence Feher

Undergraduate Intern - NREC, Robotics Academy
ROBOTC - Testing/Documentation/Developer

Computer Science, Japanese, East Asian Studies
University of Pittsburgh, Konan University 甲南大学


Tue Aug 10, 2010 10:17 am
Profile
Rookie
User avatar

Joined: Mon Feb 23, 2009 12:40 pm
Posts: 27
Post Re: Possible bug in task management 2.03 software
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.


Tue Aug 10, 2010 9:09 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3297
Location: Rotterdam, The Netherlands
Post Re: Possible bug in task management 2.03 software
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

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Wed Aug 11, 2010 1:22 am
Profile WWW
Expert

Joined: Mon Oct 27, 2008 9:59 pm
Posts: 139
Post Re: Possible bug in task management 2.03 software
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.


Wed Aug 11, 2010 1:29 pm
Profile
Rookie
User avatar

Joined: Mon Feb 23, 2009 12:40 pm
Posts: 27
Post Re: Possible bug in task management 2.03 software
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.


Wed Aug 11, 2010 6:17 pm
Profile
Expert

Joined: Mon Mar 15, 2010 4:24 pm
Posts: 124
Post Re: Possible bug in task management 2.03 software
SSI wrote:
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.

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


Wed Aug 11, 2010 10:29 pm
Profile
Expert

Joined: Mon Oct 27, 2008 9:59 pm
Posts: 139
Post Re: Possible bug in task management 2.03 software
Gary Samad wrote:
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".

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.


Thu Aug 12, 2010 9:07 am
Profile
Creator
Creator

Joined: Fri Feb 09, 2007 9:21 am
Posts: 615
Post Re: Possible bug in task management 2.03 software
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


Fri Aug 20, 2010 4:42 pm
Profile
Expert

Joined: Mon Oct 27, 2008 9:59 pm
Posts: 139
Post Re: Possible bug in task management 2.03 software
Dick, sounds like that will work for us.
Thanks for the update.


Sun Aug 22, 2010 9:37 pm
Profile
Rookie
User avatar

Joined: Mon Feb 23, 2009 12:40 pm
Posts: 27
Post Re: Possible bug in task management 2.03 software
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


Thu Aug 26, 2010 7:34 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 13 posts ] 

Who is online

Users browsing this forum: BurningLights and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  



Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.