Fetproxy never really got beyond the quick hack that Tom and I threw together in the 25C3 hack-centre at the end of 2008. The next stage was going to be a massive upheaval of its architecture, but I never found the time to do this. Enter Daniel Beer with his excellent MSPDebug utility. Daniel has found the time to work on this tool, and has made several releases so far. I’ve tested it with a couple of boards that I had lying around, and it appeared to work quite well.

Go and use it. Its source code is quite legible too, so you should hack on it too ;)

I’ve packaged mspdebug for Fedora, and you’ll find the package in this directory. Maybe I’ll jump through the hoops of getting it included in the repositories soon.

Johannes and I played around with sintering sugar. After tuning the laser power and speed to get the sugar to melt together, we decided to try out a multi-layer object. This object is made of something like 6 or 7 layers sintered on top of each other:

We printed the object the other way up from how it’s shown above. The criss-crossed interconnection between the cylindrical walls was added in the last layer we sintered.

There’s more to come on the laser cutter front in the future… The software that the laser cutter comes with is a piece of Windows software called “NewlyDraw”. It’s got quite a limited and inextensible feature set. I’ve currently got this confined to a virtual machine, but intend on reverse engineering the PC-to-laser-cutter protocol so that I can replace it with something significantly more flexible and Linux related.

Subscribe to my blog to stay current with the latest Formica facial hair developments!

Enjoy the timelapse:

More competition write-up coming soon!

You’ll also find the protopack in the webstore, which is a backpack (an extension board which plugs into the new hack connector on top of Formica 2) with a 1.27mm prototyping area on it. This will be useful for quickly hacking together extensions for your Formica robots.

Luckily I managed to get in at the right time and bought all the MSP430F2274 microcontrollers that we need for these chips. There’s some kind of international shortage of these at the moment. If you are in desperate need of these chips, email me and I might be able to sell some to you.

Why the delay? We’re not just shipping the same old design as before. We’ve added a hack header to the robot, allowing the robots to be easily extended. We’re quite excited by the extensions that people will come up with. We’ve also trimmed down the number of components on the board further (yes, it was hard to believe there were any, but turns out we did miss some!). All of these changes meant that we had to do a prototype run, which obviously increased the hours that we had to put into the project.

I’m not going to say exactly when I think the robots will be ready, because I don’t want to let people down again! However, I think I am safe in saying that they will be available within the next few months.

]]> http://xgoat.com/wp/2009/12/23/longer-urls-please/feed/ 0 http://xgoat.com/wp/2009/11/22/logger-decentralised-no-hassle-logbook-app/ http://xgoat.com/wp/2009/11/22/logger-decentralised-no-hassle-logbook-app/#comments Sun, 22 Nov 2009 22:16:38 +0000 Rob http://xgoat.com/wp/?p=965 When I started my electronic engineering degree, ECS presented me and my fellow coursemates with a logbook each. We were told these things would become invaluable assets. I remember that I was initially sceptical. As I started to follow roads that were more undocumented and experimental (i.e. everything I like to do these days…), I found the logbook more and more valuable. I don’t think I would have survived the final year of my course without it.

There are few places that I’ll go for more than a few hours without my logbook now. It’s a place to writes notes and thoughts about what I’m doing. If I go home to visit my parents for a weekend, it’ll go with me. It’ll go with me on holiday. Everywhere.

The Itch

So that experience has been good. However, there are a few things about my physical logbook that have been aggravating me for a few years now. You may have noticed that computers have become a significant part of our lives. Physical, paper logbooks are absolutely perfect for projects that involve limited interaction with computers (and those that don’t involve copying of lots of data). Writing notes on paper about projects that involve software is painful. It’s quite challenging to annotate source code that’s on a PC screen by writing in a logbook.

Getting copies of software configuration, source code and other bits of data into a logbook entry typically involves lots of printing, cutting and gluing. It’s tiresome and results in a logbook that’s twice as thick as it once was. The increased effort that one has to invest to write notes about these projects makes it much less likely that one will write them to start with. There are more problems from here on. Getting source code out of the logbook back into the PC is not going to happen.

I believe the solution to this problem is to move the logbook onto the machine.

Solution attempt 1

A few months ago, I decided to try a first quick and easy solution to this problem. I set up a git repository on a server, and put a text file called ‘log’ in it. For the next week or so, I wrote notes into it. This was OK, but I had to be very careful of keeping the machines I use it from in sync to avoid conflicts.

Solution 2

A couple of evenings ago, I started hacking away on a new solution to this problem. The result is a small tool called ‘logger’. This logbook-like application managed a chronologically-ordered list of entries. This list of entries can be synchronised between machines.

“That sounds like a versioning tool” I hear you say. Yes, Logger does use git as its backend. However, it tacks on some limitations about what you’re allowed to do to the stuff that’s in the repository once you’ve put it in. Once something’s in the log, it’s there for good. Logger doesn’t provide any features for editing things that are already in the log. There’s a good reason for this. By making log entries that already exist immutable, synchronisation between machines becomes a doddle.

You can get logger from the gitorious project I’ve set up for it:

git clone git://gitorious.org/logger/logger.git

Logger stores all log messages in a git repository, accessing it using GitPython. This means that it can use all of Git’s goodies to simplify its job.

The README file that comes with logger provides a short tutorial on its use.

(If you want gitpython for Fedora, I quickly hacked together an rpm for it. This contains the required patch to support empty commits. May submit it to the repos at some point, but not now.)

The future

I haven’t been using this situation very long yet, but it already feels like it’s a good solution. My housemate Tobias and I have been discussing how we might extend this tool. Introducing better search capabilities is something we’re both interested in. I’m also quite interested in doing “partial clones” of git repositories — so that some machines don’t have to have all of the log on them. Logger’s a command line application right now. A GUI for it would definitely be interesting.

Patches are most welcome.

Logger’s still very much an experimental tool. I’m still working out whether it fully meets my needs. We’ll see.

p.s. Oh yes, there are probably some who will say there’s some stuff to do with logbooks being legal documents. This might be soluble using something like the service I heard the Post Office provides for signing digital documents.