Subject:
|
Re: Mindstorms NXT programming languages
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Fri, 13 Jan 2006 19:19:53 GMT
|
Original-From:
|
dan miller <danbmil99@yahoo[nomorespam].com>
|
Viewed:
|
2289 times
|
| |
|
|
What you say below is entirely true, up to a point. Note that most Lego
stuff (and this is true outside Lego -- it applies to most controller code
I've seen for robotics) is now using bytecode interpreters. The memory
advantages far outweigh the CPU superiority of compiled code.
Python is a bytecode interpreter. It's true that the libraries take up alot
of memory (>5meg for the latest version), but that is mostly Python source
code. The actual interpreter is 20K on my machine.
So my thought is something like this: create a stripped-down bytecode
interpreter (VM) that understands _compiled_ Python code (the fact that
Python is compiled is usually hidden from casual users, but it's just like
Java -- it compiles a binary.)
A utility would exist that could recursively figure out exactly which
modules your code was using, and compile only those. That stuff is loaded
onto the NXT and executed. Support utilities for debugging, logging, and
possibly extended data analysis (vision, large map databases) can be
executed on the remote machine, and communicate with the NXT over a socket.
This is not too different from how things work today with NQC ir Interactive
C, or even with Java I suspect. In reality, the choice of language is not
that critical to performance, within some bounds. The advantage of Python
is that it is easy to learn, and there is a ton of Robotics code already
written for it. It's become somewhat popular in AI circles too, I think
primarily for its polymorphic abilities (though that requires a compiler,
which probably exceeds the NXT's budget).
An alternative scenario would be more like what Pyro did with hemisson,
where the NXT would just be a dumb controller written in C, and Python would
always run on the host machine over bluetooth. That might be fun, but in
the end I want a way to get the NXT to operate autonomously.
-dbm
ps everything I said also applies to Java, and there is plenty of robotics
research being done on that platform too. It comes down to a matter of
taste. Perhaps we can factor out the language, and have a project that
works with Java, Python, Perl, NQC, IC, and any other language that can be
compiled to bytecodes? Alot of the management and UI code will be the same;
you just need alternate .exe's for each bytecode syntax. Bricxcc is sort of
like that now.
--- Allen Foster <kaptain.korolev@ntlworld.com> wrote:
> In fairness, although the NXT has a small amount of memory, you're
> talking about porting a high level interpreted language like Python to a
> low-cost embedded platform.
>
> For my sins, my day job consists of developing code that must cross
> compile across about 10 different platforms, these vary in processor
> architecture. Most use Linux which greatly simplifies integration but at
> the end of the day the lowest common denominator in languages is C and
> assembly language.
>
> In my opinion you don't need to use python on embedded platforms.
> Interpreted high-level languages are great for testing concepts and
> ideas on powerful platforms. They generally are inefficient with
> resource handling and quite slow. Once you refine your code, you trim it
> down and optimise it for the embedded platform, most likely in a
> language such as C with assembler for the special stuff.
>
> I'm sure that's what you wanted to hear!
>
> Allen.
>
>
> steve wrote:
> > dan miller wrote:
> > >
> > > Has anyone (other than myself) used Python? It's a great language,
> > > and has
> > > excellent attributes for programming robots (simple, easy to learn,
> > > extremely powerful). Not clear what compromises would have to be
> > > made to
> > > port it to NXT.
> >
> > Well, on my Linux box, the main Python interpreter is in a library
> > called 'libpython' with a teeny-tiny main program running the command
> > line version. The library is about a Megabyte - and depends on other
> > stuff from other libraries.
> >
> > This is four or eight times larger than the NXT's teeny-tiny flash
> > memory (depending on which report you read about the NXT's memory size).
> >
> > Worse still, that library on my Linux box is for a Intel CPU - the ARM
> > (being a RISC machine) needs more instructions to do any given job - so
> > the code take up more space.
> >
> > So it would definitely take about 10 times the amount of flash memory
> > than is provided in the NXT.
> >
> > I'm still horrified at how little memory the NXT has. It's pathetic.
>
>
|
|
Message has 1 Reply:
 | | Re: Mindstorms NXT programming languages
|
| (...) Dan, Once you get your hands on an NXT I encourage you to try. Sounds like you have considered the costs and it might work. Don't wait for permission from us! Just try it. Often when people say it can't be done, I just consider it a challenge. (...) (19 years ago, 13-Jan-06, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Mindstorms NXT programming languages
|
| In fairness, although the NXT has a small amount of memory, you're talking about porting a high level interpreted language like Python to a low-cost embedded platform. For my sins, my day job consists of developing code that must cross compile (...) (19 years ago, 13-Jan-06, to lugnet.robotics)
|
52 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
|
|
|
|
