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.
At the last Student Robotics doing, Jeremy showed me an exceptionally vile piece of hardware. Here, I share with you the pictures that I took to raise general awareness of this sort of abuse.
Student Robotics hardware development is heating up. The support for the currently shipped kit has almost reached a point where we don’t need to spend all our time on it, and a bunch of people eager to get involved in developing the new stuff have joined the group.
After a summer of racing to get the old kit into a shippable state, the Student Robotics hardware schedule is finally (ok, almost) in line with the rest of the groups agenda! We get to think about the new hardware design at the beginning of the academic year, giving us the maximum amount of time to both get new people involved and develop the new kit.
One of the major targets for the 2011 kit (uh, the 2010 kit is currently shipping — think of it like magazines) is the I2C bus that connects all the peripheral boards together. It’s getting replaced. From almost day one the bus has been misery and pain. If you’re thinking about using I2C as an interconnect between boards on a robot platform, I encourage you to think in a different direction. Due to the capacitance of the bus in our kit, we’ve had to knock the bus down to something like 20KHz. Furthermore, this bus gets along abysmally with the RFI emitted by the robot’s motors, so many transactions get repeated over and over until the checksums align.
So, what’s going to replace our I2C interconnect? I’ve been thinking about this in the back of my mind for a while, and discussion recently began on the mailing list. Right now, we have two options in front of us: asynchronous serial over RS485 or USB. Both of these are differential buses, and both appear that they could serve us well.
USB
The USB option involves the least explaining. We’d stick a USB-to-serial chip (probably a FT232RL) on each board that’d interface with the board’s microcontroller. All the boards would plug into a USB hub, which would end up plugged into the BeagleBoard.
RS485
RS485 feels like it’s been around since the beginning of time. I expect that somewhere there’s a wire-wrapped array of 555 timers (with the requisite heatsinks…) that are doing something they shouldn’t over RS485, or a central heating control system sitting in some large company’s basement brimming with valves rocking out to RS485. However, the fact it’s still around and is still used extensively in many industrial applications is a good thing. RS485 transceivers are cheap! RS485 is compatible with daisy-chaining, which means that one could just plug another board in without having to get hold of any additional hardware (e.g. a hub).
The downside of RS485 having been around for ages is that most of the cheap transceiver chips are 5V supply only. 5V went out with the dinosaurs. All the cool kids use 3.3V and lower these days. Somewhat surprisingly, it looks like it’s cheaper to get a 5V linear regulator and RS485 transceiver to suit, rather than a 3.3V transceiver. Sounds disgusting, but it’s cheaper and performs just as well.
If we went for a master-slave relationship like we had in I2C, then we’d be OK. However, I’ve always been annoyed that the boards connected to our robot can’t generate interrupts of their own. This simple code:
from sr import *
def main():
yield io.pin[2] == 1
print "Beans"
Results in the JointIO board being continuously polled over the I2C bus to see if pin 2 has gone high. This sucks in terms of latency. It gets worse when there’s more than one coroutine running on the robot, and latency goes through the roof. So, I’d really like a multi-master bus. One where boards can shout at the BeagleBoard with an interrupt. That interrupt message can contain information about what the interrupt was as well, so the BeagleBoard doesn’t have to ask it, resulting in a nice short interrupt response time.
However, with multiple-masters come collisions: two boards may try to both write to the bus at the same time. There are a variety of methods of dealing with collisions that we could use, and many of these involve things like random-backoff times and detecting whether the line was driven in the way it was supposed to etc. My current favourite is a token-ring like approach, where we add point-to-point connections between boards that are adjacent in the chain, and get them to act like a big shift register with a single ‘1’ bit passing through it. When a board has the ‘1’, a.k.a. “the token”, it’s the master of the bus. When it’s done with the token, it just passes it on to the next board in the line. This way, there are no collisions to deal with, and each board gets a chance to transmit its data.
Which will win?
I’m not sure which will win at the moment. The RS485 option seems safe, and USB could allow for future exciting expansions. I’ll be doing more reading on USB over the next week or two to try and work out how it’ll perform in noisy situations. A possible option is sticking both the USB and the RS485 transceivers on the PCB design, and only populating one of them when it’s time to ship. Depends on how costly the board space would be.
Image used under CC license from flickr user viriyincy.
Site by Rob Gilton. © 2008 - 2019