Arduino + NXTMMX + LEGO Motors

When I first learned that Mindsensors.com (who make several really neat sensors for use with the NXT) was making a motor multiplexer, I contacted them to ask if it would work with the Arduino (yes!) … and then I asked if I could buy a prototype and was thrilled when they sent me one. (Thanks!)

This video shows how well it works.

Oh man. I love the NXT, but I really like the possibilities that this affords. The NXTMMX allows you to connect two LEGO motors to a device that issues I2C commands, and gives you one more port to plug in another NXT device. There is a good tech spec documenting the commands, so there is no reason it wouldn’t work with your microcontroller of choice, by merely connecting four wires (with a cable like this, or something from here) and supplying power with a battery pack.

Better than that, though, is that there are other I2C sensors for the NXT which will work. When I run the I2CScanner example sketch, I am able to see a HiTechnic Compass Sensor and a Mindsensor’s Line Leader. Most of my other sensors do not use the I2C bus to communicate and would need to be connected differently to use with an Arduino. [For anyone who wants to try, allow me to recommend Extreme NXT: Extending the LEGO MINDSTORMS NXT to the Next Level, or download the NXT Hardware Development KitLEGO was kind and wise enough to offer schematics on how the parts works.] One I2C sensor that did not work was LEGO’s Ultrasonic sensor. I suspect that if I provided a 9V power signal to it, it would work.

I have started an open-source project called NXT I2C Devices for Arduino. The project contains my initial code to run the NXTMMX (ported from the Not eXactly C API for the device), and, Mindsensors has been contributing code so you can use it with other sensors that they sell! Right now you need to install the Bazaar version control system to get the latest code. (I’ll update these instructions if/when I make a more straightforward download available.) At a command prompt, change to the Arduino library directory (on my Mac it is /Applications/Arduino.app/Contents/Resources/Java/libraries/), and issue this command:

bzr branch lp:nxti2cdevice NXTI2CDevice

If you’d prefer to use a graphical tool, take a look at the first few steps of my previous post explaining the use of Bazaar Explorer with Enchanting. Just make a branch of lp:nxti2cdevice, and then copy/move/symlink the folder into your Arduino libraries folder.

Oh, and if you are interested in helping out on the project, drop me a line.

Happy Hacking!

Posted by Clinton Blackmore - Wednesday July 7, 2010.
Posted in .
Comment

Jumpstart Guide to Using Enchanting with Bazaar Version Control

This article discusses how to develop Enchanting and use it with an external version control system (namely Bazaar). I used the graphical Bazaar Explorer tool on Windows and went through things step-by-step. If you prefer to use the ‘bzr’ command-line tool, you’ll see the commands to type highlighted in blue.

The Enchanting project is hosted on Launchpad. You can do most of the things listed in this tutorial without even having a Launchpad account. However, if you want to contribute back to the mainline development of the project, you will need to:

One more link you may find handy is to the latest image file for Enchanting.

Without further ado, then, here are the step-by-step screenshots and text for getting started with Enchanting and Bazaar.

Posted by Clinton Blackmore - Thursday July 1, 2010.
Posted in .
Comment

Hacking On Scratch

This page will serve as some notes for hacking on Scratch.

First, Scratch is written in Squeak, which is a dialect of Smalltalk. To really do anything with it, the starting point is Squeak By Example, an excellent book that helps you get started with programming in Squeak. I think Scratch is based on a modified version of Squeak 2.8; as of this writing, Squeak 4.1 is current. (Squeak For Non-Native Speakers (pdf) also sounds interesting, in part because it was written for Squeak 2.8.)

Next, you’ll need to download Scratch and the Scratch Source Code. I am using Scratch 1.4 in these examples. ScratchSource1.4.zip is the only file you really need, as we will not be developing plugins or tweaking the skin. It is worth looking through the license on the Scratch page. It is very open, but there are some restrictions that are worth noting.

And, fortunately, there are some great tutorials already available.

Jens created a tutorial in Scratch on creating a custom flip block, and sharing your changes with other people. (Jens later went on to create Build Your Own Blocks, which is incredibly cool.)

billyedward also has a tutorial video on creating a block in Scratch, and has gone on to make a project based on Scratch called Streak.

In the Scratch Advanced Forums, LS97 has an excellent write-up on how to create custom blocks.

Starting Up the Scratch Source Code

All of these screen shots come from the Finder in Mac OS X, but things are very similar for someone using Windows Explorer under Windows, and a file manager of choice under Linux.

Here I’ve downloaded and installed Scratch (and highlighted the files in yellow), and I’ve extracted the contents of ScratchSource1.4.zip into the Scratch folder (and highlighted the files in green). I don’t think it really matters where you unzip them to.

Scratch folder with source folder inside

To start the Scratch using the source code, you’ll need to drag and drop the image you want to work with (ScratchSourceCode1.4.image) onto the Scratch executable (Scratch.app on a Mac, Scratch.exe on Windows; I’m not sure what it is on Linux). I have highlighted the two files involved in blue in this image. Note that a Smalltalk Image is like a freeze-dried system, containing all source code and “live” objects. If you could take a snapshot of the system, what you’d get would best be called an image.

Drag the ScratchSourceCode1.4.image file onto Scratch.app.

When you first launch it, you’ll see this:

This is what you see when you first launch Scratch in the source code mode

The first time I did that, some months ago, I was completely overwhelmed. May I refer you, again, to Squeak By Example (and thank the authors for their hard work)?

I followed Jens’ tutorial. These image shows what the files look like afterwards:

Files that were changed

Files that have changed — the .image file and corresponding .changes file — are highlighted in red. Files that are newly created — the changeset that Jens recommended creating and a folder called “Locale” — are not highlighted.

Note that if you save your image in user mode, as Jens tutorial shows you, that it no longer starts up in source mode when you drag it and drop it onto the image. You can hold down shift and choose “Exit Source Mode” from the File menu, but things are not the same as they were. If you had to, you could file in the changes that you had made (and that is a reasonable way to share change sets). Alternatively, duplicate the .image and .changes file before saving in User mode. You can give people the user mode images and work yourself in the ones that are not in user mode.

Exit User Mode menu option

Posted by Clinton Blackmore - Saturday June 12, 2010.
Posted in .
Comment