Subject:
|
Re: Crate Contraption scripting system?
|
Newsgroups:
|
lugnet.org.us.smart
|
Date:
|
Sun, 17 Oct 2004 04:45:10 GMT
|
Viewed:
|
2470 times
|
| |
|
|
I'm not sure how 'exactly' I can describe the system but I'll give it a try.
I'll basically describe how the scripting system is used and you can infer how
the code must work.
First of all, let me talk about the marker tape pieces. They come from a very
shiny metallic tape that I bought at Home Depot or Lowe’s. It basically acts
like a mirror and the direct reflection of the LED to the sensor gives a value
way below that of white. The raw value is around 100 below the value for white.
I experimented with retro-reflective tape but the results were not nearly as
satisfying. I also tried small, 1/2" square, glass mirrors that I bought at a
craft store. These worked really well as far a light sensor values but made for
a very bumpy ride for the robots.
The main program can run in different modes. One mode is immediate mode where
the program takes commands that are in the form of message sequences. All the
commands that the ForkLift/DumpTruck take are three message sequences using
messages 1, 2 and 3. For example, the command Track Forward Left Edge, is
message sequence 1-1-1. Track Forward Right Edge is 1-1-2. In total there are
8 different tracking commands, basically all permutations of direction, side of
line, and whether or not to cross the line before tracking. Tracking commands
all go until, and just beyond, the reflective markers and then stop (unless
running a script, more on that later).
Some commands, such as Wait Time, also take an extra parameter. In that case,
after the message sequence is given, 2-2-1 in the case for Wait Time, the RCX
expects a binary number that is also entered using the message buttons on the
remote, M1 for binary 1, M2 for binary 0,and M3 for Enter. So a Wait Time for 5
seconds would be entered as 2-2-1, 1-2-1-3. Other commands that take a binary
parameter are Send Message and Wait For Message. Send Message and Wait For
Message are available so that it is possible to get multiple robots to
coordinate actions.
The robots also have specialized commands, such as Dump for the DumpTruck
(message sequence 2-1-1), and Move Lift To (also message sequence 2-1-1 but with
a binary parameter) for the ForkLift. The ForkLift also has a command Move Lift
Asynchronous, that starts moving the lift but returns right away so that the
robot can perform other commands, such as line tracking, while the lift is still
moving. There is also a Wait For Lift command to make sure the lift has reached
its destination before continuing.
In addition to these commands that perform some action on the robot, there are
also commands to begin recording scripts, stop recording, delete last recorded
command, and run script. Once recording has been started, all subsequent action
commands, get recorded in the memory of the RCX as they are performed, until the
stop recording command. Once recorded, scripts can be played back and they are
automatically repeated.
One difference between tracking commands when used in immediate mode v. script
playback, in immediate mode the robot always comes to a complete stop after
tracking to a marker. When playing back the script, the robots dead-reckons
over the marker and then continues the next command, if it is another tracking
command, without stopping.
The program is written in NQC which means I have to deal with some limitations,
most notably the limited amount of memory available for variables and arrays.
This turned out to be a bit of a challenge for storing the scripts. Originally
I stored the scripts in a global array but this limited the script to about 20
commands. Not sufficient, especially for the ForkLift which tends to need
longer scripts. The solution is to use the local memory, 16-integer array, of 4
separate tasks. These four tasks all included code to read or write from their
local array to the global memory. Since there are four tasks and each task can
store 16 integer commands, the script limit is now 64 commands.
I mentioned that the main program runs in different modes. The mode is
determined by a global variable that can be set by other programs also stored on
the RCX. For example, running P1, the main program, it automatically goes into
a Run Script mode. Running P2, on the other hand, sets the global mode variable
to Immediate Mode, and then runs P1 so that it now waits for message commands.
P5 also uses the main program in P1 but it sets the mode so that it does a light
sensor calibration.
Overall I have been really satisfied with how these robots perform with the
scripting system. On my original ForkLift that I built last year for the
NWBrickCon and Lego Road Show, the ‘script’ was simply an NQC program with a
very big include file that contained all the tracking and lift control code.
This program structure made the designing and testing of the layout very
cumbersome since every change to the script required a recompile and download,
something that gets pretty slow when the programs get large. With the message
interpreter system, it is quite easy to test the layout as we make it.
In lugnet.org.us.smart, Brian Davis wrote:
> I was looking at a completely different signaling system (barcode reading,
> using reflective tape to signal the beginning/end of the barcode). This has some
> advantages (well, maybe...), but making all these codes and keeping them in
> place (I was planning on removable ones, using 1x2 tiles along 2xn plates) might
> be a pain.
This is an interesting idea that I have also considered. One problem is that it
may be difficult to use the same sensor to track the line that you use to read
the barcode. It may require a seperate light sensor just to read the barcode.
> As to the Crate Contraption at Robothon, again, Wow! Fantastic job folks, I
> wish I could see it in person. I did get a module built (currently, its output
> feeds its input), and as per Dave's warning, hopper feeding is a bear. At least
> it doesn't jam the lift mechanism, but currently it only feeds reliably for
> about 5-10 minutes at a time (that's about 300-600 balls) before a jam in the
> hopper starves the lift mechanism of balls. I've also used the bulk of my 1x16
> beams :-( But it's cool, it makes a lot of noise, and most importantly my kids
> LOVE it!
Thanks! I would also love to see photos of your ball contraption module.
Gus
|
|
Message has 1 Reply:
 | | Re: Crate Contraption scripting system?
|
| (...) Wow. Thank you for an absolutely fabulous describtion - that is far more than I hoped for, and it makes a lot of things clearer. (...) That's probably next on my list. I grabbed some cheap retroreflective tapa at Meijer's the other day, and (...) (20 years ago, 17-Oct-04, to lugnet.org.us.smart)
|
Message is in Reply To:
| | Crate Contraption scripting system?
|
| How exactly does the scripting system you use work? I'm trying my hand at this, and did not think of using the remote to "program", so you've got my curiosity arroused (I'm using NQC, but that still gives me program access to three buttons (...) (20 years ago, 16-Oct-04, to lugnet.org.us.smart)
|
4 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
|
|
|
|
