View unanswered posts | View active topics It is currently Tue Oct 21, 2014 1:11 pm






Reply to topic  [ 9 posts ] 
Multitasking [sticky] - When and When Not to Multitask 
Author Message
Site Admin
Site Admin

Joined: Mon Jun 08, 2009 4:50 pm
Posts: 70
Post 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!!

_________________
Bence Feher

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

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


Wed Jun 22, 2011 1:17 pm
Profile
Rookie

Joined: Sat Nov 27, 2010 1:44 am
Posts: 34
Post 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.


Mon Jun 27, 2011 3:56 pm
Profile
Expert

Joined: Wed Jun 30, 2010 7:15 am
Posts: 181
Post 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 :)

_________________
leonoverweel.com


Tue Jun 28, 2011 5:01 am
Profile WWW
Rookie

Joined: Mon Mar 19, 2012 6:00 pm
Posts: 6
Post 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.


Mon Mar 19, 2012 9:09 pm
Profile
Rookie

Joined: Fri Aug 03, 2007 9:28 pm
Posts: 7
Post 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


Thu Apr 26, 2012 8:18 pm
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post 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?


Last edited by Ford Prefect on Sat Nov 23, 2013 1:56 pm, edited 2 times in total.



Thu Nov 21, 2013 6:08 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3225
Location: Rotterdam, The Netherlands
Post 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.

_________________
| 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]


Mon Nov 25, 2013 5:56 am
Profile WWW
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post Re: Multitasking [sticky] - When and When Not to Multitask
that's good to know, thanks a lot, Xander!

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Mon Nov 25, 2013 6:05 am
Profile
Rookie

Joined: Tue Aug 19, 2014 12:15 pm
Posts: 5
Post 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.


Tue Sep 23, 2014 10:49 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 9 posts ] 

Who is online

Users browsing this forum: No registered users and 2 guests


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:  
cron



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