Subject:
|
Re: Why java is (not) bad for Mindstorms
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 24 Jan 2006 02:04:24 GMT
|
Viewed:
|
2014 times
|
| |
|
|
In lugnet.robotics, Kevin L. Clague wrote:
> I don't know the format of the output of the graphical programming environment.
>
> The concept of a JIT compiler seems good to me. Dunno where it should exist. on
> the NXT or on the PC?
Well my understaing of JIT compiler is that its a part of the actual runtime so
I'm not sure how it would be on the PC?!
Though you got me thinking (dangerous), perhaps the best way to program the NXT
is not to run a binary but instead use an event stream methodolgy from a
Bluetooth enabled device (PC or Cellphone).
Currently the development model is you use the graphical IDE to develop discrete
execution paths based on certain events (sensors mainly). Typically these
threads of execution sit around forever waiting for these events to occur and
then react (branch, process, etc.). The logic of what to do is embedded in the
application you execute on the NXT (which is limited due to lack of resources
and is generally static).
Maybe the environment would be more robust if it was a real-time streaming message based framework, i.e. the actual logic of what to do based on sensor data (or whatever events the NXT can consume) can be forwarded along the Bluetooth connection to a host that collects and processes the data. Then, the host sends commands via discrete messages back to the NXT firmware/OS which consumes and performs the action. The idea is that the actual processing of sensor data and robotic logic is complex and better suited to a more robust host. The NXT environment has to monitor input/outputs and have some sort of message consumer/producer on it. The firmware is relatively small and highly optimized to process these messages and execute as fast as possible (interrupt driven).
Taking this one step forward, if the host knew about several NXTs, it could
perform higher level tasks by federating these messages across different NXTs.
If you had to processs all of these events and try to communicate back and forth
between NXTs directly, I think the runtime environment would be too limited for
anything overly complex (considering the memory constraints alone though maybe
I'm being too skeptical).
Maybe this is all crazy, I'm not sure, but it seems with Bluetooth, passing
along the logic via messages to a more powerful host makes a lot of sense to
me... (provided the messages are easy to consume and produce, obviously trying
to parse XML on the tiny NXT may be a bad idea).
-aps
|
|
Message has 2 Replies:
 | | Re: Why java is (not) bad for Mindstorms
|
| -- pisymbol <pisymbol@gmail.com> wrote: [SNIP} (...) If I'm chosen as the one of the 100, this is what I will work on, using and abusing the BT communications on the NXT. Right now, I'm working at using the RCX Ir-I2C mindsensors.com interface for (...) (19 years ago, 24-Jan-06, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Why java is (not) bad for Mindstorms
|
| (...) I don't know the format of the output of the graphical programming environment. The concept of a JIT compiler seems good to me. Dunno where it should exist. on the NXT or on the PC? (...) Could be. (...) I sure hope so. (...) Kev (19 years ago, 23-Jan-06, to lugnet.robotics)
|
25 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
|
|
|
|
