An Array of Solutions
OK, so far we’ve probably painted a pretty picture of the NXT. But some of you are likely saying “wait a minute, where’s the down side?” And there are some – after all, this is first and foremost a toy (educational or otherwise) aimed at kids, not adults with computer science and engineering degrees. So there are some things that are missing from the out-of-the-box kit. In terms of parts, this isn’t a critical problem; I (and a lot of others… you know who you are) have a lot of LEGO around the house, and it’s fully compatible. Even in terms of motors and sensors, the NXT is a more “complete” kit than the RCX (for example, the RCX with three motor ports generally came with only two motors, while the NXT comes complete with a full complement of three motors). But what about the software?
There are (from my viewpoint – again, to be honest, I’m not the target market for this) some things missing that I really wish were built in to the software. Arrays are a really good example: NXT-G has no official support for arrays, yet I find them very useful. But NXT-G is powerful enough that with a little bit of work (and a good deal of fun) I can get around this, and have my own arrays!
The method I’ve used (I’m sure there are others) uses the file system on the NXT. For each element of an array, I just create a very short on-brick file to hold that number: essentially, the array is just a series of numbered files on the NXT. What would be really nice is if you could just add this ability into NXT-G in a way even a kid could understand. Gee, yeah, that would be really nice…
Remember MyBlocks?
Here I’ve created two MyBlocks, ArrayRead (which will read a number from a specific element of the array) and... ArrayWrite (to write a number into the array). Take a look.
With these as MyBlocks, all these messy details are hidden, and almost anybody can use them as easily as the "stock" blocks from the official NXT-G pallets. For instance, to test these MyBlocks I wrote a simple program that just puts five random numbers into an array, and then reads them out to display on the screen.
Notice that the code is pretty much self-documenting used this way.
While this is a reasonable way to do arrays, there's a deeper point here. Yes, there are things missing from the language. But in a lot of cases, you can write MyBlocks to patch these holes (like arrays, trig functions, etc.)... and learn (or teach!) something in the process. It this extendability of the language that I think is its greatest strength, and kudos to LEGO and NI for keeping it in. Now, when we need something implemented in the NXT-G language... we can do it ourselves.
--
Brian Davis
There are (from my viewpoint – again, to be honest, I’m not the target market for this) some things missing that I really wish were built in to the software. Arrays are a really good example: NXT-G has no official support for arrays, yet I find them very useful. But NXT-G is powerful enough that with a little bit of work (and a good deal of fun) I can get around this, and have my own arrays!
The method I’ve used (I’m sure there are others) uses the file system on the NXT. For each element of an array, I just create a very short on-brick file to hold that number: essentially, the array is just a series of numbered files on the NXT. What would be really nice is if you could just add this ability into NXT-G in a way even a kid could understand. Gee, yeah, that would be really nice…
Remember MyBlocks?
Here I’ve created two MyBlocks, ArrayRead (which will read a number from a specific element of the array) and... ArrayWrite (to write a number into the array). Take a look.
With these as MyBlocks, all these messy details are hidden, and almost anybody can use them as easily as the "stock" blocks from the official NXT-G pallets. For instance, to test these MyBlocks I wrote a simple program that just puts five random numbers into an array, and then reads them out to display on the screen.
Notice that the code is pretty much self-documenting used this way.While this is a reasonable way to do arrays, there's a deeper point here. Yes, there are things missing from the language. But in a lot of cases, you can write MyBlocks to patch these holes (like arrays, trig functions, etc.)... and learn (or teach!) something in the process. It this extendability of the language that I think is its greatest strength, and kudos to LEGO and NI for keeping it in. Now, when we need something implemented in the NXT-G language... we can do it ourselves.
--
Brian Davis
Comments
So far in all the code examples I have not seen anything that resembles the RCX sensor stack. Does this feature still exist?
The nice thing about this is now, you can have a sequence ("stack") execute in response to lots of different conditions. Not just "the light sensor is brighter than some set value", but things like "either the light sensor is above or below this specified range, or the ultrasonic sensor detects an object closer than 20 cm".
--
Brian Davis
In the second picture, you have three red blocks and I'm not understanding the comments and how this process works. Any chance you could provide some more clarification on the read/write process?
Also, is the index# generated randomly? The third picture shows an orange block that I think is a random number generator feeding into the ArrayWrite block. Is this correct? If so, if the loop happens five times isn't it possible that an array element will get overwritten if the random# repeats itself?
Thank you for taking time to go over this. I can't wait to get my MSNXT and start testing the programs.
Chris from Florida
PS: Could you cover programming one or two of the sensors and show us how to configure them or do something interesting with them? Thank you.
In ArrayRead, the MyBlock takes a number (wired in by the yellow wire) and converts it to a string (carried by orange wires), which is then combined with some other text in the next block to make a name like "array-3" or something similar. This is used as the file name (see how it's wired into the plug with a "file folder" symbol?). The first of these two File blocks closes the file (so that if it was open for some reason before, like writing to it, it will be re-opened at a known point - namely the beginning), and the second File block reads out one piece of data from the named file.
ArrayWrite works very simlarly, but closes and deletes any preexisting file by the requested name, to make sure that the number to write into the file is the very *first* piece of data in it.
Essentially I'm doing some file manipulation "behind the scenes"... but by putting it into MyBlocks, I (or a student) don't have to deal with those issues again, but can just use them as array access blocks.
> is the index# generated randomly...
Nope, there are two numbers being wired into the ArrayWrite MyBlock: the first is the index, which is being sourced from the plug coming out of the loop - the "counter". The second input to ArrayWrite is the number to write into the array, and it is wired out of the Random block.
All this is much easier when you are programming: for instance, the specifics of the block configuration appears at the bottom of the screen as you mouse over or select a block, and all the plugs have pop-up tooltips naming them (even the ones you make for your own MyBlocks). It's nearly impossible to convey the amount of information you have availible to you in any form other than a dynamic, graphical one (i.e.- the environment).
--
Brian Davis
What's the IO time like? Any chance of missing a sensor input during an IO read?
--
Brian Davis
It's a good point to bring up, and one the members of thye MDP and LEGO have given some serious thought to. But I think this is a trade-off here, and I'm using the FLASH memory in a decidedly non-standard fashion.
--
Brian Davis
Lighten up.
Jim
While it sounds like your array method would work for D-heaps (as long as LabView supports recursion...) I think things would be much more efficient if one could read and write to different positions in the same file.
There's also been mention of a LUA IDE coming soon. I believe the LUA language also has native support for arrays.
Both of these are 3rd party developed IDEs. RobotC is commercial software available from Carnegie-Mellon Univerisity. I believe LUA will be freeware.
YOu probably don't want to use files. Every sector write takes 3-6 msec while the NXT CPU is stalled. Deleting file, creating new file, writing one byte likely involves at least six sector writes (say 25 msec)!