ROBOTC.net forums
http://www.robotc.net/forums/

Multitasking [sticky] - When and When Not to Multitask
http://www.robotc.net/forums/viewtopic.php?f=1&t=3342
Page 1 of 1

Author:  bfeher [ Wed Jun 22, 2011 1:17 pm ]
Post subject:  Multitasking [sticky] - When and When Not to Multitask

Multitasking is when the robot performs multiple complex behaviors at the same time (simultaneously). If a robot performs behaviors step-by-step (sequentially) then it is not multitasking and should not be programmed with multiple tasks. Let’s look at few examples and determine whether or not multitasking should be used.

A robot drives forward until the sonar sensor sees and object at 30 cm or less away, turns right and stops.

A flowchart of this program would look like this:
Code:
Program starts,
Motors start going forward,
Keep going until the sonar sees something <= 30 cm,
Turn right (right motor negative, left motor positive),
Stop (both motors at 0),
End Program.


As you can see, this program is sequential because each step comes after the one above it. We DO NOT use multitasking in this example. Let’s look at another:

A robot follows a line until it is 20 cm or less away from a basket and then drops a ball into the basket.

A flowchart of this program would look like this:
Code:
Program starts,
Sonar starts checking for objects <= 20 cm away,
Light sensor reads dark:
   Motors turn slightly one direction,
Light sensor reads light:
   Motors turn slightly in the other direction,
Sonar sees the basket <= 20 cm away,
Motors stop,
Arm motor starts and drops ball into basket,
End Program.


This program also runs from top-to bottom, but this time we have a sonar sensor and a light sensor that are checking their values and performing behaviors at the same time.
Should we use multiple tasks here? No because we can combine the multiple behaviors into a single task like this:

Code:
task main()
{
   // do the things in this loop while the sonar sensor is > 30 cm
   while(SensorValue(sonar) > 30)
   {
      // follow line:
      if(SensorValue(lineFollower) < threshold)
      {
         // turn sligtly one direction
         motor[rightMotor] = 50;
         motor[leftMotor] = 0;
      }
      else
      {
         // turn slightly in the other direction
         motor[rightMotor] = 0;
         motor[leftMotor] = 50;
      }
   }
   
   // stop motors and dump ball into basket:
   motor[rightMotor] = 0;
   motor[leftMotor] = 0;
   motor[armMotor] = 25
   wait1Msec(1000);
   motor[armMotor] = 0;
}
 


When multiple behaviors can be combined into a single task, we should always choose to do so instead of multitasking!

When should one use multitasking then? Imagine a program that drives a robot around a room vacuuming up objects while avoiding people. The robot comes with an emergency stop button just incase the systems for avoiding people fail or the robot uprising begins and we need to deactivate our robot quickly (in the real world, kill switches are important for human safety). How would a flowchart for this program look like? It is difficult to make a linear step-by-step chart for this program because it is doing multiple things at the same time. Also, the emergency stop button needs constantly be checking while other behaviors are running because the robot must stop immediately when the button is pressed, no matter what else it may be doing at the time. We need multiple flow charts side-by-side:


Driving flowchart:
Code:
Start program,
Turn on vacuum,
Start driving around,
If sonar sees a person:
   stop motors,
   turn off vacuum,
Sonar no longer sees person:
   turn on vacuum,
   contine driving around,
Loop back to start of program.   


E-stop flowchart:
Code:
Begin loop:
If E-stop button pressed:
End Program.
If E-stop button not pressed:
Go back to top of loop,


The actual program would look something like this:

Code:
task e_stop()
{
   while(true)
   {
      if(SensorValue(e_stopBtn) == 1)
      {
         StopAllTasks(); // this ends the program
      }
      wait1Msec(10);  // this prevents the current task from hogging the CPU
   }
}


task main()
{
   StartTask(e_stop);
   while(true)
   {
      if(SensorValue(sonar) <= 10)
      {
         motor[rightMotor] = 0;
         motor[leftMotor] = 0;
         motor[vacuumMotor] = 0;
      }
      else
      {
         // code for driving around room here
      }
      wait1Msec(10);  // this prevents the current task from hogging the CPU
   }
}


Notice that even though behavior for picking up objects and the behavior for avoiding people are running at the same time, they can be combined into a single task. However, the emergency stop button requires a task on its own that runs in the background while the other behaviors are also running. Also please note the two “wait1Msec” commands that prevent each task from hogging the CPU. If a task doesn’t have any waiting in it, it may hog the CPU meaning that it will not let any other tasks run.

It’s important to remember that task main is the main task of the program and when it finishes execution, all other tasks will be force-quit and the program will end. In our example, task main was always in a while(true) loop and didn’t end until task e_stop stopped all tasks.

This very basic example shows a good use for when to use multitasking, however many very important and dangerous concepts have not been addressed.
I encourage those who wish to know more to research Multitasking (multi threading) in C.


Remember:
99% of all ROBOTC programs can be written without multiple tasks if you combine related behaviors!

and
99.9% of all errors in programs that use multitasking are because of improper use of multitasking!!

Author:  bobatk [ Mon Jun 27, 2011 3:56 pm ]
Post subject:  Re: Multitasking [sticky] - When and When Not to Multitask

The wait1Msec(10) calls here can better be replaced with EndTimeSlice(), which accomplishes the same 'yield the processor behavior' without introducing any delay. Not a huge practical difference in this particular example, but strictly better programming practice for this situation.

Author:  DiMastero [ Tue Jun 28, 2011 5:01 am ]
Post subject:  Re: Multitasking [sticky] - When and When Not to Multitask

Shouldn't this be in the NXT Programming: Tips for Beginning with ROBOTC forum? Well great tutorial anyway :)

Author:  jeremy__ [ Mon Mar 19, 2012 9:09 pm ]
Post subject:  Re: Multitasking [sticky] - When and When Not to Multitask

IMHO, 100% of the time multi-threading can be avoided in RobotC - and if should be.

However, with that said, its much easier to build a poorly designed application that uses many threads than it is to build a solid application that uses one. Since many RobotC programmers aren't professional embeded systems programmers, I would expect a few users opting for the multi-threading route.

I see people using multiple threads as if they were multiple processes - but RobotC does not isolate the two threads and the data they may share which makes it very prone to misuse.

Author:  plopes [ Thu Apr 26, 2012 8:18 pm ]
Post subject:  Re: Multitasking [sticky] - When and When Not to Multitask

I have doubts about time sharing in multi-tasking...

(1)

suppose task1 and task2 having equal and high priority (say 7),
and task 3 having lower priority (say 5);

-> will the former tasks share 100% CPU time (with task main) until they are stopped, and task3 be always waiting for them to stop before running, or ...

-> will they run sequenciallyand in cycle (task main, task1, task2 and task3) each one using its respective time slice, being each slice proporcional to the indicated priority?

(2)

how many clock cyles will each task run?

is a constant, always the same, no. of cycles always being divided by all the running tasks? or does it vary with that no.?

how many are they?


I'd appreciate any help on this!


Thanks!

Paulo
PORTUGAL

Author:  Ford Prefect [ Thu Nov 21, 2013 6:08 am ]
Post subject:  Re: Multitasking [sticky] - When and When Not to Multitask

(question to the RC developers:)

hi,
I'm also curious about some MT details and MT program design, especially how it will be implemented by RC 4.0 for the EV3. So here are my first 3 questions:

1) will a wait state (e.g., 100ms) in 1 certain task provide the whole unused cpu time for different time slices to other tasks or will the computational time be sort of wasted?

2) are sensor values polled just exactly at the time when the polling command of the current program is executed or are all sensors polled by FW background tasks as quick as technically possible and immediately stored to global arrays?
E.g., if there is a i2c sensor which has to be polled just once every 100ms in my program (by a wait(100ms)): will there be a i2c read be executed only once after every 100ms or will the FW poll more frequently than I actually need and thus put a stronger strain on the i2c bus than as it's actually needed?

3) does RC meanwhile support mutexes?

Author:  mightor [ Mon Nov 25, 2013 5:56 am ]
Post subject:  Re: Multitasking [sticky] - When and When Not to Multitask

Quote:
1) will a wait state (e.g., 100ms) in 1 certain task provide the whole unused cpu time for different time slices to other tasks or will the computational time be sort of wasted?

The CPU power goes to another task, if it has something to do, of course :)
Quote:
are sensor values polled just exactly at the time when the polling command of the current program is executed or are all sensors polled by FW background tasks as quick as technically possible and immediately stored to global arrays?
E.g., if there is a i2c sensor which has to be polled just once every 100ms in my program (by a wait(100ms)): will there be a i2c read be executed only once after every 100ms or will the FW poll more frequently than I actually need and thus put a stronger strain on the i2c bus than as it's actually needed?

Depends on whether you are using the built-in drivers or the driver suite drivers. The built-in ones poll at faster intervals in the background, the ones from the driver suite only poll when you tell them to :)
Quote:
3) does RC meanwhile support mutexes?

Yes, it does.

Author:  Ford Prefect [ Mon Nov 25, 2013 6:05 am ]
Post subject:  Re: Multitasking [sticky] - When and When Not to Multitask

that's good to know, thanks a lot, Xander!

Author:  ronaldle [ Tue Sep 23, 2014 10:49 am ]
Post subject:  Re: Multitasking [sticky] - When and When Not to Multitask

Multitasking without just having one CPU can produce complex and error prone code. But with 2 or more CPU we have multiprocessing. To my knowledge, the EV3 only has one CPU and thus, I will always use single threading concepts in the programming of my robots. The only multiprocessing system that I know of is the one produced by Parallax, the Propeller with its Spin software.

Author:  knotian [ Mon Jan 30, 2017 10:25 am ]
Post subject:  Re: Multitasking [sticky] - When and When Not to Multitask

I'd like to resume this subject - since it is a good one.
I am dealing in using RobotC in a 'non-robotic' environment of an automated display.
In this situation there would be multiple sensors and motors ( I plan on using sensor and motor multiplexers also) spread out over the display.
As an example.
There is a task that should start when a certain color coded vehicle stops in front of the sensor. (unloading a hopper into a rail car)
Completely independent of this function a second color sensor will start a multiple switch motors to sort a rail car into a specific track.
Another independent task is to run a conveyor belt when a hopper is full, to load the hopper in the first task. ( Using a touch sensor on a balance beam as a trigger)
Only one task will run at a time, since we need control over the motors.

The list could be continued.
What would be the best program structure to utilize? I was thinking about having the sensors place distinct values into a variable and using a switch structure.

Page 1 of 1 All times are UTC - 5 hours [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/