Subject:
|
BrickRemote ideas for discussion
|
Newsgroups:
|
lugnet.robotics.palm
|
Date:
|
Wed, 10 Nov 1999 22:03:58 GMT
|
Viewed:
|
2358 times
|
| |
|
|
Greetings,
Mike Kory (author of BrickRemote) and I have been corresponding via
email regarding a number if ideas for BrickRemote. We'd like to make this a
public discussion for further illumination! Sorry for the lengh of this post...
USER INTERFACE
It seems that there are two basic "types" of users: roughly
speaking "the advanced users" and "their children" ;-) In addition, there are
several different approaches available for remotely controling a Lego bot:
- 2 motor drive such as a tank bot
- 1 motor drive, 1 motor steer
- 2 motor drive such as a tank bot plus 3rd motor
- 1 motor drive, 1 motor steer plus 3rd motor
- all of the above plus task buttons, program buttons and the ability to watch
variables/sensors
In designing an interface for use by those with little fingers, we're
wondering if a UI similar to Lego's remote control (Motors A | B | C
forward/reverse plus message buttons, beep, etc.) would be "better" than a
forward/left/right/reverse/stop approach. There is also BrickRemote's current
UI which provides one-tap access to tasks, the ability to switch programs and
watch variables, etc.
Mike has mentioned the possibility of splitting BrickRemote into two
versions: one designed for children (large buttons for finger control) with
the possibility of a few variations on control layout and functionality. It's
a bit tricky to design, because Scout handles two motors whereas MindStorms
can take three. The opening screen could have three button/options:
1) Tank tread robot,
2) Driver/Steering robot, and
3) A|B|C Motor controls (similar to the Lego Remote).
Depending on the user's choice, you either go to the direction control
screen (whose motor controls are set up to match the type of robot)
or you go to the A|B|C motor control screen. Options #1 and #2 could be
hardcoded to use motor's A & B (along with a notice to that effect) in order
to have compatibility between MindStorms and Scout.
I've posted a few UI designs for BrickRemote at
http://www.sitewax.com/shine/brick.htm
RCX HAS PALM FOR BRAINS
BrickRemote and NCQ got me pondering about the possibility of giving
the RCX a brain transplant: use the Palm. There's plenty of RAM, nice
clockspeed, multi-tasking (so I'm told), a graphical environment and the
hotsync ability makes everything neat, mobile and web-able. Here's the quick
rundown:
- Palm runs something like BrickRemote in that it can communicate with
the RCX via the Lego IR tower. It may not be as fast as a hardwire, but it
works!
- The Palm app has functionality similar to NCQ with the exception of
compiling and downloading the code to the RCX. Instead, the code is run in the
*Palm.* The Palm captures all motor commands and pipes them through the IR
tower and down to the RCX.
- The app also polls the RCX (via IR tower) on a regular basis in
order to get up-to-the-minute sensor data. E.g. Poll RCX > Process in Palm >
Instruct RCX > Poll RCX etc. (Perhaps the polling period is adjustable?)
The caveat here might be the time delay introduced by using the IR
tower as a mediator between the Palm and the RCX. (I haven't timed it.) That
being said, I doubt that even a one second delay would seriously hamper the
performance of most Lego bots. ;-) Then again... if real-time performance is
critical (i.e. near-zero communication delay between brain and brawn) then it
may be possible for a specialized chunk of code to be downloaded into the RCX
to handle those critical events when they arise, after which passing the
higher functions back to the Palm.
Anyways, giving the RCX a brain transplant with a Palm is exciting and
full of possibilities. Imagine having that the extra computing space and
power! It may service to free our robots to do more leading-edge stuff: like
neural learning or building a 2-d array/maps of it's environment, or real-time
image scanning, data graphing, etc. Who knows?
As for the Palm app itself, I'm frankly a bit fuzzy:
Write scripts on the Palm - Basic editing controls as well as saving RCX
scripts into a database is good.
Hotsync new scripts in - so they can be shared across the web. ASCII format
sounds good. Desktop conduit may be needed unless the app pulls from specific
MEMO category or email.
Saving RCX data - The ability to record sensor logs gives the RCX access to
past memories -- or even transplanted ones!
Using RCX data - The ability of a script to consult those logs or load a log
file into an array as run-time parameters would be very valuable.
Displaying RCX data - To visualize sensor/variable data as text, binary,
charts, etc. opens up new possibilities in gathering/sharing data.
Extensible - What about taking a plugin approach and allow the app to be
extended by other developers?
Aware of Palm system - What if the RCX could fire off an email from your Palm
and beam it to your laptop? Or launch a stop watch?
Could NCQ be ported over and adjusted to catch all sensor requests and
turn them into sensor polls as well as catch all motor commands and send them
down via IR tower to the RCX? (I'm not a programmer, so I'm just throwing
these things into the ether as a catalyst for conversation)
The floor is open!
Cheers,
Carl Jagt
|
|
1 Message in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
