Subject:
|
Re: Multitasking
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Fri, 14 Jan 2000 18:09:30 GMT
|
Viewed:
|
706 times
|
| |
|
|
Hi Alex,
I was thinking this over last night and was wondering about how sleeping a task
would affect an application that requires precise timing. In the bicycle
example, what would happen if the balancing task was asleep when the bicycle
began to tip?
I think multitasking is certainly useful in situations where the tasks are
disjoint, such as driving the robot and sending a message over the IR port. But
when the tasks need to work together closely, the sleeping issue worries me.
David Leeper (thinks this is an interesting topic)
In lugnet.robotics, Alex Wetmore writes:
> From: "David Leeper" <david.leeper@destiny.com>
> > I removed the multitasking features from my cruise and avoid code last • night
> > and discovered the robot runs smoother, using less code, and less RCX
> > variables.
>
> Cruise and avoid is a pretty simple type of program, and multitasking really
> isn't necessary. I wrote a sublimation version of it mostly to play with
> the concepts of sublimation. Two nights ago I wrote the same program using
> LegOS and used a more traditional loop there. The two versions are:
>
> http://www.phred.org/~alex/lego/wander.nqc
> http://www.phred.org/~alex/lego/wander.c
>
> I think that the sublimation model becomes a lot more powerful as you have
> many inputs to monitor and build more complex robots. My cruise and avoid
> robots really only have one input to watch -- some sort of bump detection (a
> rotation sensor in the above examples).
>
> An example of a robot type where I think that sublimation would be useful is
> trying to build a balancing and steering vehicle such as a bicycle. Alex
> Nicolaou and I started talking about this in private email a few days ago.
> Here you might want a high priority task which makes the minor steering and
> weight-shift movements necessary to keep the bike balanced, while having a
> lower priority task which controls the same steering and weight-shift
> movements to allow the bike to turn. We'll see how this works out once I
> have time to build such a robot.
>
> Conclusion: multitasking isn't necessary or optimal for all tasks, but it
> can be useful in more complex tasks.
>
> alex
|
|
Message has 1 Reply:
 | | Re: Multitasking
|
| (...) Actually, this is precisely the case where multitasking works best. A single-threaded application has to poll for events that it is interested in. Regardless of the priority of a particular event, that event has to wait until the application (...) (25 years ago, 14-Jan-00, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Multitasking
|
| From: "David Leeper" <david.leeper@destiny.com> (...) night (...) Cruise and avoid is a pretty simple type of program, and multitasking really isn't necessary. I wrote a sublimation version of it mostly to play with the concepts of sublimation. Two (...) (25 years ago, 13-Jan-00, to lugnet.robotics)
|
9 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
