Subject:
|
Re: Two motors at the same time... It is possible?
|
Newsgroups:
|
lugnet.robotics.nxt
|
Date:
|
Tue, 20 Feb 2007 10:25:17 GMT
|
Viewed:
|
13684 times
|
| |
|
|
David Wallace wrote:
> occam ... I was wondering where I had dealt with that before. Then I
> realized, I had a little introduction to this when writing test
programs for
> submarine circuit cards that had used transputers. Weren't they
developed by
> NASA?
>
> David
Ah. occam history. :)
The Transputer was a chip made well before its time by the INMOS
corporation, and is actually a UK invention. It supported very fine
grained concurrency, and could handle switching between many hundreds of
concurrent processes in microseconds. And, if you stuck a few
Transputers together, you had an instant 20Mb network between the
processors, and could easily write code that ran on more than one CPU.
All this in the early 1980's. You could program it in occam (it's
"native" language), or Lisp, or C, or Pascal... quite a few languages,
actually. Today, we have living, breathing compilers for occam and C,
and the code is executed on a virtual machine.
The virtual machine the Transterpreter) runs on a whole lot of
platforms, whereas occam used to only run on the Transputer. This means
we can write very safe, concurrent (or, on multiple CPUs, parallel) code
quite easily.
For example, in occam, you can write things like:
CHAN speed, bumpOne, bumpTwo:
PAR
motorControl(speed?)
brains(speed!, bumpOne?, bumpTwo?)
bumper(bumpOne!, '1')
bumper(bumpTwo!, '3')
The PAR says "do all of these things at the same time". The runtime
handles the concurrency of multiple tasks. Each task runs forever. The
channels carry data between them---perhaps single integers, perhaps
complex data structures. And, we can draw pictures of these things:
------------- -------------
| bumper 1 |-----bumpOne----| |
------------- | | ----------------
| brains |---speed--| motorControl |
------------- | | ----------------
| bumper 3 |-----bumpTwo----| |
------------- ------------|
The channels are named, and the end you write to is designated (in the
code) by a '!', and the end you read from is designated by a '?'. (They
work like soup cans tied together with a bit of string. You talk in one
end, and listen in the other.) So, in this network, we can see that the
two 'bumper' processes will produce data on the channels named 'bumpOne'
and 'bumpTwo'. The 'brains' process will read data from 'bumpOne' and
'bumpTwo', and produce messages on the 'speed' channel. And,
'motorControl' reads in the messages from 'speed'. It is, if it means
anything to you, a dataflow language instead of a sequential language
(like C, Java, RoboLab, NQC, etc...).
Hence why we're revising our RCX port, and a member of the community is
helping leading on the port to the NXT. When we're done, you'll have a
consistent, concurrent interface to robotic control that works the same
on the RCX, the NXT, and any large robotics platform that is supported
by the Player/Stage API (a commonly used interface in robotics research).
Wow. I really got going there. I've spent a lot of time working on the
VM and tools surrounding it, and it is exciting to be getting close to
release. If you're interested in robotics and concurrency, you can also
check out or VMWare virtual machine that supports exploring the
programming of large platforms (http://robodeb.transterpreter.org/). We
usually intend it for use in the classroom, so there isn't as much
"self-start" material as we'd like. Feel free to ask questions (perhaps
on our discussion lists) if you grab it.
Cheers,
Matt
|
|
Message is in Reply To:
5 Messages in This Thread:
 
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in NXT programmable brick
|
|
|
|
|
|
