That was a few weeks ago. I now understand why no one ever did this… I’m still sweating 😉
Download it here.
I am now building these projects one by one to see if I’ve made any mistakes. The CD-ROM had small movies included in the instruction steps, most of which are probably not that important, but for some of them I may need to find a way of inserting a shot from the movie into the instructions.
Version history:
0.2 – verified the plotter project with all its modules: corrected one image in motor module 2 and added two images to the pen module.
0.1 – initial version.
crw------- 1 root root 180, 1 Oct 22 09:56 legousbtower1
Since I log on as user michiel, not root, I could not access the device, so NQC would complain about “Could not open serial port or USB device”. I found the solution on Adrian Smith’s Blog:
“For a more permanent solution create the file /etc/udev/rules.d/90-legotower.rules with the following contents,ATTRS{idVendor}=="0694",ATTRS{idProduct}=="0001",MODE="0666",GROUP="<group>"
You can use any group you’re a member of in place of <group>. You can find a list of the groups you’re a member of using ‘id -a
‘. I used the group “adrian”. On a lot of systems there’ll be a group with the same name as your userid. This is fine so long as you’re the only one who’ll need access to the device. Otherwise you’ll need to find a common group or perhaps create a new one. By the way, the vendor and product ids in the udev rules file came from running lsusb.”
I used the group name “michiel” and it worked fine (I think it will work regardless because it sets the mode to 666 which means read/write access for everyone anyway.
After creating that file, I unplugged the USB tower, plugged it back in, and presto there it was:
crw-rw-rw- 1 root michiel 180, 1 Oct 22 12:59 legousbtower1
Problem solved!
]]>When the program is started, Output ports A and C are turned on forward.
So if you attached two motors to these ports and linked them to wheels, you have a rover that drives forward.
Sensor ports 1 and 3 are configured for use with touch sensors.
When the program is started, Output ports A and C are turned on forward.
When touch sensor 1 is activated, motor A stops. When touch sensor 3 is activated, motor C stops.
With this you could for example build a rover that turns when hitting an object.
Sensor port 2 is configured for a light sensor. Keep two motors attached to output ports A and C.
After activating the program, the motors will turn only when the light sensor is close to a bright surface, for example a white paper. When above a dark surface (for example a black line), the motors will stop.
With this you could build a Rover that drives on a white surface until it reaches a black finish line or boundary.
So I decided to hook up a standard LEGO 9v Light 2×1 brick to one of the OUT ports on my RCX, and see if I could get it to work. Here is the setup (and my first attempt at Leocad):The lamp doesn’t really show up well in the above picture, but it’s simply one of these.
Now basically the light needs to flash in certain patterns to transfer information. For finding out what those patterns are I need to acknowledge Doug Eaton who did a great job of figuring it all out and putting a great write-up online. Another great resource was Barnaby Walter’s page, who achieved the same using the LEGO fibre-optic elements.
I have written a rcxvll.nqh library which contains all the VLL commands the MicroScout recognizes, together with a little test program which runs a sequence of the direct commands which you can use to test connectivity.
To successfully use it all together, make sure to build your setup first, turn on the bricks, upload program to the RCX, set the MicroScout to P mode, then run the RCX program.
You can barely see the light flashing in the video, but it is!
]]>The RCX has been set up real simply with three touch sensors, one for left, one forward and one right. The programming is made pretty easy using NQC:
task main() { /* Set all three Sensor types to Touch sensors */ SetSensorType(SENSOR_1, SENSOR_TYPE_TOUCH); SetSensorType(SENSOR_2, SENSOR_TYPE_TOUCH); SetSensorType(SENSOR_3, SENSOR_TYPE_TOUCH); /* Set infrared power to High, so we can cover longer distance. */ SetTxPower(TX_POWER_HI); while(true) // Loop forever { if (SensorValue(0)==1) //button 1 pressed { SendRCMessage(RC_CHANNEL_1, RC_CMD_REV, RC_CMD_FWD); } if (SensorValue(1)==1) //button2 pressed { SendRCMessage(RC_CHANNEL_1, RC_CMD_FWD, RC_CMD_FWD); } if (SensorValue(2)==1) //button3 pressed { SendRCMessage(RC_CHANNEL_1, RC_CMD_FWD, RC_CMD_REV); } Wait(5); } }
This of course assumes your Spybotics brick has been configured to RC channel 1. Download the program: rcx2spy_remote.nqc
]]>If you look closely, you’ll see above the port it says: 9-12 V ~
So that means you can use any adapter that produces between 9 and 12 volts and has a plug that fits? Unfortunately, No.
That ~ symbol at the end means AC, alternating current. Most adapters you’ll find will output DC instead of AC. The circuitry behind this port is quite good in that it will even appear to work fine on a DC adapter for quite a while, but you run a serious risk of overheating it, and there have been reports of burnt out RCXs! So make sure you get an adapter with AC output.
Here is a LEGO adapter* I had lying around. How to tell it is the correct one?
At OUTPUT it says 10V, so that is okay, but there’s a different symbol next to it:
This symbol means Direct Current: DC. So not good, it’s not AC.
* Adapter merely used as an example, this particular LEGO adapter has the wrong plug anyway, it doesn’t fit the RCX port.
]]>