- Home
- About
-
- Arduino + NXTMMX + LEGO Motors
- Jumpstart Guide to Using Enchanting with Bazaar Version Control
- Hacking On Scratch
- Create your own printable LEGO Grids
- LEGO and DUPLO printable grids
- Behaviour-Based Wall Follower in NXT-G
- Robofest 2010 in Cardston
- Obstacle Course Tips
- Line Following Tips
- SABRE Competition at the CES Science Fair
- Blog
- Contact Us
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 Kit — LEGO 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!
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:
- sign up for a Launchpad account
- request to join the Enchanting Team
- tell Launchpad what your public SSH keys is.
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.
First, start Bazaar Explorer (how you do this depends on which platform you are running on).
Click on the "Configuration" button and tell Bazaar your name and e-mail address.
Now, you will create a branch of the Enchanting project. Doing so will copy all of the files from the Enchanting project on Launchpad (called "lp:enchanting" for short) to your local computer.
When asked if you want to create a destination repository, the answer is "Yes".
Next, I specified a location for the local copy of the repository and hit the Okay button.
After hitting close on that last dialog, the files downloaded, and I was told I was done creating a branch.
Now the main window of Bazaar Explorer shows the new branch ...
... and, if I navigate to the specified folder in my filesystem, you can see that the branch has indeed been created and populated.
Two important files are not versioned in the source-code repository: Enchanting.image and Enchanting.changes. These files represent a snapshot of the state of the virtual machine image running in Squeak, and as such, change all of the time. For those rare occasions when you need a new copy of the image, download it from http://static.robotclub.ab.ca/source_code/enchanting/Enchanting-Image-Latest.zip.
Unzip the latest image file and put Enchanting.image and Enchanting.changes inside your main Enchanting directory (overwriting any files with the same names).
Drag and drop Enchanting.image onto Enchanting.exe/Enchanting.app, and you'll be greeted with the running image inside a Squeak Virtual Machine, similar to the picture above.
If you open up the file menu normally, this is what you get, but ...
... the file menu has developer functions if you hold down Shift while opening it. Any time you get new code from Launchpad, you'll want to "Import From Version Control." This will 'file in' (import) all of the classes that have been exported to the Classes subdirectory.
Let us now assume that you have new functionality to add that resides within the Enchanting.image. Go ahead and hack on the code ...
... tweak your code ...
... and test your code until it works and you are happy with it.
Here I've highlighted all the currently exported files in the Classes folder.
Holding down shift, choose the File menu and "Export to version control"
Wait patiently while the code is exported.
Here is what the Classes folder looks like afterwards. You can see there are now more files in the directory. They will need to be added to the source control system.
Going back to Bazaar Explorer, I hit the 'Refresh' button, and it indicates that changes have been made.
I hit the 'plus' symbol beside the word "Unversioned" and specified which files to add to version control.
After that, I wanted to see what changed in the modified files, so I hit the 'Diff' button. [In this image, so far as I can tell, the only difference is in the text file line endings. I will be fixing that so that diffing works properly.] Do note that you can configure Bazaar Explorer to use your favourite diff and merge tools.
Now that I am happy with everything I've done, I am performing a local commit. Basically, this means that all the changes I've made will be safe in the source control system, but only on my computer. (We'll push the changes to launchpad in the next few steps.)
After I type in a message (so I know what changes I made when I look through the history/log of the project), I hit "Okay" and everything is committed locally.
I am now going to Merge. Basically, this will check to see if there have been any changes on Launchpad that need to be integrated into my branch. The location could read "lp:enchanting" for short.
The merge went successfully. It does help that there were no changes. If there were, I recommend diffing, testing, committing locally, and merging again until there are no changes.
Now, I (believe I) am ready to push my changes to the code repository on Launchpad, so I hit the "Push" button.
I need to tell Launchpad who I am so I can upload code. The only way to do that in Bazaar Explorer version 1, is to go to "All Commands..."
... and then issue the "launchpad-login" command with my Launchpad username, "clinton-blackmore". After a couple of false starts, I hit "Okay" and it works.
Now that I'm logged in to Launchpad (and am on the Enchanting-Team that controls the Enchanting project), I try to push the code again. It gets further, but fails in that it can not verify my SSH key to upload the code. I go to the Launchpad site, read up on creating an SSH key and telling Launchpad what it is, do it, and then, as you can see, I successfully push up a new version of the code.
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.
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.
When you first launch it, you’ll see this:
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 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.
