Subject:
|
Re: Why java (or other langs) for Robots
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 19 Jan 2006 06:46:27 GMT
|
Original-From:
|
dan miller <danbmil99@yahooIHATESPAM.com>
|
Viewed:
|
1724 times
|
| |
|
|
--- PeterBalch <PeterBalch@compuserve.com> wrote:
> Dan • ..
> You almost had me convinced there for a moment.
heh, I'll keep trying.
> 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.
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 limiting. But
think of a setup like this: there is quick-reaction-time code running on the
robot; and the desktop machine acts more or less like a hard drive or
database. So you need a system that is architected to cache the local data
in the robot as needed. Lots of client/server/agent stuff, esp. in Java,
thinks this way already.
>
> Until such a system is available for $200, we're stuck with NQC and its
> equivalents in other languages.
...
> 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.
Great analysis! I've been thinking about just these issues. Fact is,
serious roboticists are using all of these techniques simultaneously. Only
academic purists are convinced of the one true way. Consider a roving robot
like one from MobileRobotics. It uses PID loops to control servos and
velocity. There are medium-level logic routines, multitasking, to
coordinate sensor readings and react to situations like unexpected
obstacles. Then there are high-level routines to map and navigate. This
three-level architecture is actually just what they teach in grad school (at
least at CMU.)
>
> 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.
Here's where we part ways. I believe the type 1 and type 2 people could
easily move up to type 3 stuff, if the tools were available. What I'm
proposing (to the degree I've actually proposed anything -- more like what
is percolating in my mind) is a system where these levels of architecture
are more naturally integrated. My present thoughts revolve around some sort
of meta-language, that has the right properties to be implemented at all
three levels. Low-level routines would be strongly typed and compiled for
performance and footprint, and reside directly in the controller (the NXT in
the Lego model). Mid and High-level routines would reside mostly in the big
brain, but bits of code could be downloaded and executed on the controller
when necessary (say because of latency concerns). All of this would be as
transparent to the programmer as possible.
Your thoughts about time domain issues (subsumption, analog circuit
metaphors, threading, etc) are right on the money. I think a new langauge
paradigm may be necessary to capture the essence of what you need to do good
robotics.
This is very ambitious obviously, and frankly it goes beyond my interest in
Lego. Lego for me is a tool, not an end in itself. But it represents the
absolute best tool available for prototyping the real-world part of robotics
quickly and easily.
To sum up, I think I'm saying this: The whole combination of NXT, lego
building components, bluetooth, and the availability of cheap PC's with huge
hard drives and fast CPU's, may add up to more than the sum of the parts.
I'm just trying to think out of the box a bit, and not get stuck in the
groove of "it's just an RCX with a bit more memory". I don't think so.
best,
dan
|
|
Message is in Reply To:
 | | Re: Why java (or other langs) for Robots
|
| Dan (...) structures (...) youngsters for (...) 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 (...) (18 years ago, 18-Jan-06, to lugnet.robotics)
|
2 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
