My big haul (in a little box) of LEGO™ bits turned up. I bought them from the Brick Artist Depot, run by a very pleasant and accommodating bloke in Atlanta. Very happy. Go and make him a rich man.
I now own another two motors that look identical to those that come with the Lego™ Mindstorms kit. Slightly worrying is that these are known to fail. Conversely the four turntables should come in quite handy.
This looks interesting: a Wikipedia-style collaborative robotics textbook. Sounds like a great idea.
A three speed automatic transmission built out of LEGO™. Wow.
Quick hack to fix the slow downloads: somehow the leading 0xf1
byte of a response packet from the RCX is getting lost quite often, so I
simply make it seem that if the host gets a packet from the RCX then
that packet starts with that byte. Things are a lot faster and more reliable
now. The tarball has been updated.
Using the light sensor and a circular 2x2 plate to simulate a rotation sensor is a bit tricky, not the least because the (active) light sensor readings don't seem to vary much - 50 to 54 for me. Secondly there's the question of sampling frequency, and then relating the number of events to the quantity we're really interested in (distance or angle in the case of the turtle). Oh well, I'll see what I can do.
From the point of view of interesting programming, the turtle isn't such a great starting point. The robot is severely limited in the amount of concurrent activity it can engage in; I think one could raise or lower the pen while rotating or moving, but this is hardly useful. It seems to me that the cleverer the mechanism the more limited the concurrency possibilities.
Brown has an interesting course with some labs that help with getting started. Another way to get into interesting-program-land is to sophisticate the task.
dll
is
pretty damn unreliable. (I began writing a control program for the turtle,
see. That bit's easier than I thought.) Oh well, another problem for another
day.
Wow, things start working. I ripped Markus Strickler's mostly-beautiful
osx_usb.{ch}
out of the aforementioned lejOS tree and started hacking it
into brickOS's mangled dll
(dynamic linker and loader). The
code for all these sorts of tools starts out as a minor variant of Kekoa Proudfoot's seminal
work, is extended with various hacks to get things working under Windows, Linux with that new USB driver, on Solaris, etc. etc. and
ends in Mac OS X users tearing their hair out. The code started out as a
proof-of-concept and is now more-or-less unmaintainable.
Well, that's my excuse for ungently hacking out the bits I didn't need (viz the old serial device mechanisms, and Windows and Linux support). If the brickOS website looked less dead I may have tried to do it tidily and submitted a patch. As it is, I'm just going to package it up to save the hair of my fellow Mac OS X users. Some notes:
- Things are slow; quad-rate download is unsupported.
- My RCX had a default LNP (brickOS's "LEGO™ Network
Protocol") address of 2. You need to specify this when using
dll
. The following worked for me:dll -v -p1 ../demo/helloworld.lx --rcxaddr=2
View
button: the address is the number that comes up afterAddr
when you cycle through it, ignoring the final '0'. You can set it by pressingPrgm
when it is displayed.
The tools are available here. They are imperfect but enough to get started. I may hack them a bit further into shape in the future, and if you do please send me the results.
With the confidence that I can now get my programs onto the RCX I started building the Logo turtle featured in the Syngress 10 Cool Lego Mindstorms Robotics Invention System 2 Projects book. It's a mechanical marvel. I wonder if it's capable of drawing a smooth curve.
Wow, some success. Back at my parents' place for the weekend, I had access to a Windows machine. This allowed me to get the official LEGO™ firmware onto the RCX, and then, well! The wonders one can work with known-good hardware.
The only Mac OS X 10.4.3 / USB Lego tower firmware downloader that worked for me is packaged with leJOS. Indeed, if I was more charitable I would try out their whole system, the core of which is an implementation of most of the interpreter-part of a JVM on the RCX, a nice piece of engineering. That's more than I hope I'll need, but we'll see.
The lejosfirmdl
program happily downloaded the brickOS
kernel to the RCX for me. I have a minorly hacked version of it that I
can supply on request.
Once the brickOS firmware is on the RCX it doesn't take too kindly to attempts to replace it. Apparently one must ask it to commit hara-kiri, leaving only the LEGO™ ROM intact and in charge. To quote the aging FAQ:
Because of a limitation in the LEGO™ firmware,
firmdl3
cannot delete brickOS. Instead, before downloading the new firmware, you must first stop the old brickOS program, and then hold down thePrgm
button while hitting theOn/Off
switch. This will delete the old brickOS firmware, allowing a new download.
Next step: getting a brickOS program onto the RCX. I observe at this point that the linker and program downloader are fused together, and so I cannot just hope that NQC or leJOS will save my bacon this time.
Lesson of the week: don't be heroic. There's a pre-packaged GCC 3.2.2 and binutils 2.13.2.1 available, linked from this rather intriguing summer class at Lund (hello Calle!). Download and install. Trust me, it's much easier than compiling things yourself.
Compiling brickOS itself is still a bit fiddly. I did the following to a virgin brickOS 0.9.0 tree:
-
util/firmdl/rcx_comm.c
fails to compile. I later found thefirmdl3
program included with brickOS to be useless, so the quickest "get the compile to go through" hack is just to add#define linux
near the top of that file. - blinks that seems to do it.
The tricky part is talking to the USB tower. Almost all the non-LEGO™ Lego™ Mindstorms projects appear to have stalled right about when the USB tower became the only thing one could buy. I take that to mean that the people who got all excited in 1998 or so and did all this wonderful work never bothered with the newer RCXs, and that it seemed to have lost its geek chic by 2001 (excepting the Linux afficiandos, of course, who appear to think that this device is worth a kernel driver... in 2.6.something... say no more.).
Picked up the Lego™ Mindstorms I ordered from Dick Smith Electronics from the post office yesterday. (This courier company thoughtfully leaves one's package at the post office if they can't deliver it.)
The first step, beyond opening the box and aahing over all the bits in the kit, is to get a decent development environment working on Mac OS X - and that means GCC, of course. I tried 4.0.2 with little joy, and from a fair bit of googling I got the impression that 3.3.x is a goer.
Some details: we need a cross-compiler to GCC-target
h8300-hitachi-hms
. The Mac OS X internationalisation appears
to cause GCC some grief, so I'm just going to have to read American
English for a while (shock horror). Using the various Fink and DarwinPorts tools lying about, and after a painless binutils v2.16.1
installation, the following worked for me:
% tar xfj gcc-3.3.6.tar.bz2 % mkdir build-gcc % cd build-gcc % ../gcc-3.3.6/configure --target=h8300-hitachi-hms --prefix=/opt/local/crossgcc --exec-prefix=/opt/local/crossgcc/h8300-hitachi-hms --enable-target-optspace --enable-languages="c" --disable-nls % make
You can change that to --enable-languages="c c++"
if you like
that sort of thing.
My choice of putting everything in /opt/local
rather than
/usr/local
confuses brickOS's (ad-hoc, not autoconfiscated) configure
script. The obvious change in that
script makes it work.
Next step: build brickOS.