Dec/090
Robotic Kite Flying
I saw this post in the IEEE Spectrum blog about a robotic kite flying. The group that did it, Festo, has done some other cool project like flying robot penguins.
I guess it's always more impressive to demonstrate learning algorithms on big expensive hardware. But having big hardware is not essential for having great algorithms. I'm sure there are ways to demonstrate great algorithms using relatively primitive hardware.
Peter
Oct/090
Magnetic charge has been measured
Researchers from the London Centre for Nanotechnology have measured magnetic charge.
Our measurement of magnetic charge and magnetic current establishes an instance of a perfect symmetry between electricity and magnetism.
Wow! That's nothing short of amazing!
Peter
Sep/090
PRETzel
PRETzel is a research group based in the ECE department at the University of Auckland. Their research focuses on the development of Precision Timed (PRET) Machines, which are processor architectures designed to give precise, deterministic execution timing. Predictable timing can be crucial for the reliable operation of embedded systems.
The PRETzel group's approach is based on augmenting an existing general purpose soft-core processor with a "predictable functional unit". Their ARPRET processors are programmed in PRET-C, an extension of C that supports synchronous concurrency, preemption, and a high-level construct for logical time. PRET-C programs are logically concurrent, but compile down to a sequential program for execution.
Berkeley and Columbia are also collaborating on the devlopment of PRET machines, although their approach is slightly different to the PRETzel one.
I'd eventually like to start doing some work with PRET machines here - either on the architecture development front, or on language design for PRET systems. Vorpal's approach to concurrency might map well onto a PRET architecture. It'd be interesting to look at how well the two approaches match, and whether Vorpal could be augmented with timing instructions.
Aug/091
Line tracing laser which generates sound
I can imagine this is quite fun to play with. Its a pity they haven't managed to get some more interesting sounds out of it.
http://www.youtube.com/watch?v=fBxPYhOnKv0
[Ed. Looks like a good system for making a simple interactive robot. Laser tracing of features in realtime should have some nice applications in games or learning systems. Building two robot which can interact by laser projection with each other sounds like a great demo and nice ML platform.]
Aug/093
Wacky Idea #1: An Embedded-Systems “Multimeter”
Sometimes it'd be handy to have some kind of portable "multimeter" for embedded systems development. A kind of "universal embedded systems debugger". What I envision here is a handheld device with the capability to handle simple digital levels, JTAG, USB, RS232, SPI, I2C, ethernet, and wireless (probably 802.15.4) interfaces, to read in data and display it, and to output custom data. Possibly also including some basic current and voltage sensing, or a really basic oscillioscope capability. Something that would let you interface to a device in the field by whatever debugging port it has available, and try to figure out what's wrong with it.
Does anything like this exist already?
--Allan
Aug/093
Fleet
Fleet is a Berkeley project to develop novel processor architecture -- if that's the right word for what Fleet is doing -- based on small interacting components that operate concurrently. The result seems to be sort of halfway between a processor and an FPGA. A Fleet processor consists of a switching fabric, a bunch of functional units (called "ships"), and a collection of connections (called "docks").
Personally, I find the terminology a bit too "cute". It introduces an additional barrier to understanding what they're doing: the analogy between real ships and docks and the Fleet system is sufficiently tenuous that the names don't really help in understanding what they're up to. But the basic idea looks quite interesting. The processor itself is completely asynchronous, and highly concurrent. Programming a Fleet processor is quite different than programming a traditional processor, and largely seems to involve defining movements of data between different "ships" rather than defining operations on data. Seems like there'd be some interesting challenges in programming such a system (although I'd imagine that the occam community might have some applicable ideas), but also some interesting potential applications.
--Allan