|
Page 1 of 1
|
[ 10 posts ] |
|
Multitasking [sticky] - When and When Not to Multitask
Author |
Message |
bfeher
Site Admin
Joined: Mon Jun 08, 2009 4:50 pm Posts: 70
|
 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: 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: 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: 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:E-stop flowchart:The actual program would look something like this: 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 |
|
 |
bobatk
Rookie
Joined: Sat Nov 27, 2010 1:44 am Posts: 34
|
 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 |
|
 |
DiMastero
Expert
Joined: Wed Jun 30, 2010 7:15 am Posts: 181
|
 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 |
|
 |
jeremy__
Rookie
Joined: Mon Mar 19, 2012 6:00 pm Posts: 6
|
 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 |
|
 |
plopes
Rookie
Joined: Fri Aug 03, 2007 9:28 pm Posts: 7
|
 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 |
|
 |
Ford Prefect
Guru
Joined: Sat Mar 01, 2008 12:52 pm Posts: 1030
|
 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 |
|
 |
mightor
Site Admin
Joined: Wed Mar 05, 2008 8:14 am Posts: 3654 Location: Rotterdam, The Netherlands
|
 Re: Multitasking [sticky] - When and When Not to Multitask
The CPU power goes to another task, if it has something to do, of course  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  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 |
|
 |
Ford Prefect
Guru
Joined: Sat Mar 01, 2008 12:52 pm Posts: 1030
|
 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 |
|
 |
ronaldle
Rookie
Joined: Tue Aug 19, 2014 12:15 pm Posts: 37
|
 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 |
|
 |
knotian
Rookie
Joined: Thu Aug 20, 2015 10:12 am Posts: 12
|
 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.
|
Mon Jan 30, 2017 10:25 am |
|
|
|
Page 1 of 1
|
[ 10 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
|
|