"Dancing mule"
On a more broadly interesting robotty note, here's a dancing mule. It looks like the star is a "Big Dog" from Boston Dynamics, though I prefer the video cut to music to the drier one (warning - 11Mb WMV) on the company's website.
Building the Coat Hanger Walker
Here are a few things I noticed when building the "Coat Hanger Walker" from the Absolute Beginner's Guide to Building Robots -- see my last post -- that I think it would have been nice to know in advance. If you're not intending to build one in the near future, you should probably skip this post :-)
Another robot
A happy New Year to everyone! As a last post for 2006, here's another robot, slightly better than my last attempt (though it does insist on walking backwards -- some reshaping of the legs required, I think); it's the "Coat Hanger Walker" from the Absolute Beginner's Guide to Building Robots. (See here for my build notes.)
Have a great evening, and see you in 2007.
Make:06 Trimet... hmmm.
I've just realised that I posted about receiving a package from Solarbotics a while back -- but I've been silent about the results. The bits were the parts for the "Trimet" from Make magazine, issue 6, along with a book called the Absolute Beginners Guide to Building Robots, and the parts required for the robots designed in there. I've never been much of a hardware hacker, but spending half my time coding and the other half messing around with the business side of running a company has made me keener on spending the, uhm, other half somewhere away from a computer screen. And, being a good geek, how better to spend that time than on building our new robot overlords.
Time constraints mean that I've only been able to build the Make Trimet, a solar-powered thingy that uses the power from light shining on it to move, pretty much randomly. And while I can imagine that in sunny southern California, herds of these creatures jig cheerfully across the desert, in the wintertime UK they are somewhat less active:
Well, what can you expect - we all get a little sluggish in the runup to Christmas. But just as Seasonal Affective Disorder is meant to be banished by bright light, a torch (flashlight for our american cousins) can help the Trimet -- or, at least, a 1,500,000 candlepower torch can:
(In case you're wondering, the apparent dimming of the lights when the torch switches on is simply my phone's camera adjusting its brightness settings to allow for the sudden influx of excess photons... ambient light was actually the same throughout. It's a bright torch.)
I guess the Trimet races will have to wait until July.
Installing Asterisk
Continuing down the VoIP-experimentation route, I've installed Asterisk on a spare Linux box. It seemed most sensible to do it from the CVS repository, so I tried:
jura:/home/root# cd /usr/src
jura:/usr/src# mkdir asterisk
jura:/usr/src# cd asterisk
jura:/usr/src/asterisk# export CVSROOT=:pserver:anoncvs@cvs.digium.com:/usr/cvsroot
jura:/usr/src/asterisk# cvs login
However:
jura:/usr/src/asterisk# cvs login
Logging in to :pserver:anoncvs@cvs.digium.com:2401/usr/cvsroot
CVS password:
Unknown host cvs.digium.com.
jura:/usr/src/asterisk# ping cvs.digium.com
ping: unknown host cvs.digium.com
jura:/usr/src/asterisk#
I guess they've moved over permanently to Subversion (which is a good thing, though it would be nice if it were more prominently documented). So:
jura:/usr/src/asterisk# svn checkout http://svn.digium.com/svn/asterisk/branches/1.2 asterisk-1.2
A asterisk-1.2/build_tools
...
A asterisk-1.2/formats/format_g726.c
A asterisk-1.2/aescrypt.c
U asterisk-1.2
Checked out revision 48358.
jura:/usr/src/asterisk# svn checkout http://svn.digium.com/svn/zaptel/branches/1.2 zaptel-1.2
...
A zaptel-1.2/oct612x/Makefile
Checked out external at revision 12.
Checked out revision 1688.
jura:/usr/src/asterisk# svn checkout http://svn.digium.com/svn/libpri/branches/1.2 libpri-1.2
The rest of the build went reasonably easily once I started following the online instructions rather than the (admittedly literally months old) VoIP Hacks book, which omits certain bits of useful information (like the packages you need to have installed in order to make the compile work) and is clearly a bit out-of-date generally. For anyone else out there who googles for error messages to see if there's any easy fix, if you successfully compiled and installed libpri, but then found that building zaptel crapped out with vast numbers of error messages, the last ones looking like this:
/usr/include/linux/fs.h:383: error: storage size of `i_ctime' isn't known
/usr/include/linux/fs.h:515: error: storage size of `f_owner' isn't known
zaptel.h:1115: error: storage size of `confin' isn't known
zaptel.h:1116: error: storage size of `confout' isn't known
zaptel.c:6472: error: storage size of `zt_fops' isn't known
make: *** [zaptel.o] Error 1
jura:/usr/src/asterisk/zaptel-1.2#
...or, alternatively, when building asterisk, you got the following:
checking for tgetent in -ltermcap... no
checking for tgetent in -ltinfo... no
checking for tgetent in -lcurses... no
checking for tgetent in -lncurses... no
configure: error: termcap support not found
make: *** [editline/libedit.a] Error 1
jura:/usr/src/asterisk/asterisk-1.2#
...then you should go back and reread the list of packages you need installed before building. They are:
- Linux 2.4 kernel sources or kernel 2.6 header files. (for libpri)
- bison and bison-devel packages (This is used to build Asterisk)
- ncurses and ncurses-devel packages (Used to build astman, etc.)
- zlib and zlib-devel packages
- openssl and openssl-devel packages
The relevant apt packages (for my Debian 2.4 test machine) were
kernel-source-2.4.27, bison (bison-devel doesn't exist, which makes some
kind of sense -- surely any use of a compiler compiler is development?), ncurses-dev
and libncurses5-dev, zlib1g-dev, openssl, and libssl-dev.
Once these are installed, the build goes much more smoothly.
It's all installed happily on my machine, and if I didn't have work to do tomorrow I'd be posting again later this evening about how to set it up with the SPA-3102. I guess that will have to wait 'til later :-/
New project: VoIP
We need to sort out our phone system at Resolver, which has given me the excuse not only to wire up the office for gigabit ethernet (am I alone in thinking that self-adhesive trunking is an incredibly underrated invention?) but also to start playing with VoIP. I suspect that for the company I will wind up outsourcing everything, getting some kind of managed solution with an external POTS (normal phone) number that routes through to softphones on our desktop machines. I'll blog about anything interesting I find in that line.
With my home phone I can mess around a little more. In the excellent VoIP Hacks, I read about the Sipura SPA-3000, a clever device that connects to your phone socket and routes the signal onto your ethernet -- so that you can route incoming calls to a SIP (that is, VoIP) phone on your network, and -- if you are so inclined -- route your VoIP calls on the network out to the regular phone system. This is a great device because it allows you to start playing with VoIP at a minimal cost -- after all, if you want to do anything interesting, you'll need to mix your normal phone system in with your experiments, and phone cards for Asterisk servers can be costly and a pain to install.
Anyhow, after slightly more hunting around than you would hope, trying to find out where to get an SPA-3000 in the UK, I discovered that Sipura was acquired last year by Cisco -- their products are now sold under the Linksys brand (which, to be fair, is one I have a soft spot for). It's kind of odd that this fact isn't posted on the front page of the Sipura site, but there you are -- it looks like the site has been left unupdated for quite some time.
Once you know about the acquisition, it becomes easier to find the products, though it is still surprisingly difficult -- dabs.com, my favourite supplier, have nothing of interest, and none of the other companies I normally use stocked anything. However, BroadbandBuyer.co.uk have the SPA-3102, which is the successor to the SPA-3000. Mine arrived the other day.
The first step was to set up the device so that I was simply to be able to dial out and receive calls over my normal telephone line, with the phone and the line both connected to the device -- that is, to simply have it pass signals through in both directions. This should be trivial -- it's the default configuration, and should work even if the phone is switched off -- but, at least in the UK, it's not. The device comes with RJ-11 sockets (US telephone standard, a bit like the ethernet RJ-45 sockets but smaller) for both the FXO and the FXS ports, and an RJ-11 to RJ-11 cable. Like most modern phones sold in the UK, my normal telephone has an RJ-11 socket in the unit, into which is plugged an RJ-11 to BT socket cable (BT being the British standard, after British Telecom -- the plug looks a bit like a wide ethernet plug, with the "latch" to the side rather than on top). I initially tried connecting the phone to the unit by using the supplied RJ-11 cable, but got nothing. I then switched back to the old BT cable, but put an adaptor with a ring capacitor in between; this worked, and I got a (rather odd) dial tone from the device, and was able to use its voice prompts to find out what IP address it thought it had (192.168.0.1, no wonder my router was unhappy) and to change it to something sensible. So, lesson one -- if you want to plug a phone into the SPA-3102, you need to use the cable you would use to plug it into the wall, with a ring capacitor.
I then plugged the device into the telephone socket, using a different RJ-11 to BT cable. This did not work either; the dial tone on the phone did not change from the device's own tone to the BT one. A quick google, and I found this forum post; I needed a modem cable "with the wires swapped" rather than a straight-though cable. (My mental model for this is that it's kind of like an ethernet crossover cable.) A quick trip to Maplin, and voila -- the device worked in passthrough mode just fine, and I can start thinking about how to do something more useful with it!
Some pondering... initially I was thinking that it was because one has to mess around like this that VoIP has yet to hit prime time in this country... but then, I heard the laughter of thousands of aging british road warrior businessmen in my head, people who spent years on trips to the US, messing around with their modem cables -- back in the days when you could stay in a serious hotel that didn't have some kind of WiFi, or at least ethernet. "Of course you need a ring capacitor", they cry. "Isn't it obvious?"
Back again
Things have been busy for the last week or so, especially at Resolver, where we are moving inexorably toward a public launch. Normal blogging service will be resumed shortly.
Project: Automated offsite backups for an NSLU2 -- part 13
Previously in this series: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8, Part 9, Part 10, Part 11, Part 12.
I'm setting up automated offsite backups from my NSLU2 to Amazon S3. With suprisingly little effort, I've managed to get a tool called s3sync running on the "slug" (as it's known). s3sync is a Ruby script, so in order to run it, I had to install Ruby, which in turn meant that I had to replace the slug's firmware with a different version of Linux, called Unslung. Once all of this was done, I just had to set up the appropriate directory structures and certificates so that the sync tool could use SSL, and write a simple upload/download script. All of this worked pretty much as advertised in the tools' respective documentation -- for the details, see the previous posts in this series.
My final step had been to set up a cron job to run the upload script, but it had failed, not logging anything. In order to debug, I ran the upload script directly from the command line, and left it to run overnight, copying a large set of directories to S3.
Project: Automated offsite backups for an NSLU2 -- part 12
Previously in this series: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8, Part 9, Part 10, Part 11.
I'm setting up automated offsite backups from my NSLU2 to Amazon S3. With suprisingly little effort, I've managed to get a tool called s3sync running on the "slug" (as it's known). s3sync is a Ruby script, so in order to run it, I had to install Ruby, which in turn meant that I had to replace the slug's firmware with a different version of Linux, called Unslung. Once all of this was done, I just had to set up the appropriate directory structures and certificates so that the sync tool could use SSL, and write a simple upload/download script. All of this worked pretty much as advertised in the tools' respective documentation -- for the details, see the previous posts in this series.
My final step in my last post was to set up a cron job to synchronise quite a lot of data up to S3 overnight. This post covers what I found the next day.
MSBuild WTF: "The error was:"
Here's a fun one for anyone who uses msbuild (at least, v2.0.50727). Create a project file like this:
<Project DefaultTargets="Foo" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Foo">
<Exec Command = "echo Hello!" />
</Target>
</Project>
From a command prompt, run the project; you will get a the effect you would expect.
Now replace the word "Hello" with "The error was: something random". Run it again.
C:\\Dev\\Resolver>msbuild foo.proj
Microsoft (R) Build Engine Version 2.0.50727.42
[Microsoft .NET Framework, Version 2.0.50727.42]
Copyright (C) Microsoft Corporation 2005. All rights reserved.
Build started 15/11/2006 17:50:22.
__________________________________________________
Project "C:\\Dev\\Resolver\\foo.proj" (default targets):
Target Foo:
echo The error was: something random
EXEC : The error was: something random
C:\\Dev\\Resolver\\foo.proj(3,9): error MSB3073: The command "echo The error was: something random" exited with code -1.
Done building target "Foo" in project "foo.proj" -- FAILED.
Done building project "foo.proj" -- FAILED.
Build FAILED.
EXEC : The error was:
C:\\Dev\\Resolver\\foo.proj(3,9): error MSB3073: The command "echo The error was: something random" exited with code -1.
0 Warning(s)
2 Error(s)
Time Elapsed 00:00:00.09
C:\\Dev\\Resolver>
Fuzzyman and I bumped into this one at work today; our continuous integration server, which watches our Subversion repository and checks out, builds, and tests any code changes it sees, had reported a failure despite the fact that none of the tests had failed. It turned out that one test was quite innocently printing out the text "The error was: " followed by some logging information; it wasn't an error at all. As far as I can tell, the statement that the echo command exited with code -1 is absolute nonsense.
This behaviour is not documented anywhere that we were able to find; I can only assume it was added for some specific purpose in the context of Visual Studio...