Subject:
|
Re: Why java (or other langs) for Robots
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 18 Jan 2006 15:47:40 GMT
|
Original-From:
|
PeterBalch <PETERBALCH@COMPUSERVEstopspam.COM>
|
Viewed:
|
1528 times
|
| |
|
|
Dan
> A 4GL scripting language such
> as Python, Ruby, or Lua, (maybe even Scheme), with next-gen data • structures
> (arbitrarily indexed tables, true polymorphism),
> will really enhance the NXT experience for a good percentage of • youngsters for
> whom it will be their first exposure to what programming is all about.
You almost had me convinced there for a moment.
4GLs are wonderful for quick "I wonder if this will work" programs. And
that's exactly what most of the robot we build are.
But such languages require a lot of housekeeping in the background and a
lot of debugging tools in the forground. They don't readily fit into a tiny
computer. To get the best of both worlds, you need to run a 4GL on a PC
with a radio-link to a dumb robot. Once your code works, you (somehow!)
compile it down to fit into a few K of RAM.
Until such a system is available for $200, we're stuck with NQC and its
equivalents in other languages.
With a new toy about to come out, now is the ideal time to say what should
and shouldn't be in the new compilers that will be produced for it.
There is no such practice as "typical" robot programming. There are three
rather different practices:
Type 1 People who make balancing robots want something like an analogue
computer. You set up the "circuit" for your PID controller or whatever and
then twiddle the control knobs until the robot balances. Quite a lot of
low-level robot control is like that.
Type 2 People who make simple mobile robots want something like Brooke's
subsumption. Small "behaviours" which are triggered by events: if you bump
into a wall, back up and turn left; or follow the left hand wall until you
sense an opening then expect to find some steps and ...".
Type 3 People who make robots with vision and route finding through the
desert want high-level languages to crunch enormous amount of data or
explore huge "search spaces" for the path to some goal.
Type 3 People won't be using a tiny computer. They'll mount a PC on a big
chassis and have as much processing power as they can afford. We can forget
them. They need Lisp or Prolog or Haskell or whatever is the fashionable
languge this month. The rest of us don't.
So that leaves Type 1 and Type 2 people.
Both _can_ use C or Java or Fortran or Pascal or Forth or whatever, but
none are ideal. Why?
Type 1 people find those languages are a bit clumsy. A circuit-diagram on
the back of an envelope is better. The user interface should look like
that. C, Java, etc. are sequential languages and there's no real concept of
sequence in an analogue circuit.
Type 2 people need multi-threading because you're often juggling several
small algorithms at the same time (hence the beauty of Brooke's
philosophy). C, Java, etc. _can_ be made to be multi-threaded but it's a
real kludge.
Lego ensured that the RIS visual language did have multi-threading. Good
for them. They understood what mobile robots are about far better than
most.
The fact that it was a "visual" language is not relavent. That sort of
"visual" language is exactly equivalent to a textual language. There are
statements and they are executed in sequence. "Visual" languages are very
useful for beginners because it is much more obvious what you can and can't
do. If the blocks (i.e. statements) are shaped like jigsaw pieces then it's
obvious what is and isn't syntactically correct. With a good visual
language you can enforce syntax and encourange good programming practice.
Then all you need is a "convert to Java" button (which is trivially simple
apart from the multi-threading).
A visual language like a circuit diagram is totally different. What's
flowing is data. (Whereas in RIS, it was execution that was flowing.)
That's what is brilliant about Brooke's philosophy. He combines both in a
fairly natural way. There are boxes and arrows like any visual language.
Inside the "behaviour" boxes, the arrows show flow of execution. But
between the "behaviour" boxes, the arrows showed flow of data. (His
breakthough, of course, was to show how you combine the outputs from the
boxes.)
Robot programmers are unusual in that they always need to consider both
kinds of flow. Java or Python don't deliver.
Peter
|
|
Message has 1 Reply:
 | | Re: Why java (or other langs) for Robots
|
| (...) .. (...) heh, I'll keep trying. (...) Well I agree halfway. Small interpreter kernels like Lua can fit easily into the 256K flash. The programs themselves are typically very compact. The really scarce resource will be RAM -- 64K is quite (...) (18 years ago, 19-Jan-06, to lugnet.robotics)
|
2 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
