Let's start right away with an example and sum up the parts of the last controller I was working on with Orocos:

* Industrial Single Board Computer (SBC) (PIV 3.4GHz) with 11 PCI slots. Brand: [Amplicon, Type: Ventrix 4003|http://www.amplicon.co.uk/IPC/product/Industrial-Ventrix-4U-379.cfm]
* National Instruments PCI cards: NI 6602, NI 6713, NI 6503 for counters, analog output and relays respectively, [supported by Comedi|http://www.comedi.org/hardware.html]
* RTL 10/100 ethernet card, supported by [RTNet|http://www.rtnet.org].
* [Peak Systems CAN card|http://www.peak-system.com], supported in Linux and Xenomai.

Ok, before you start building this system for your robot, you should know that the application was not in traditional robotics. But that's not the point. The point is the __price tag__. The PC was quite cheap, about 1500 euro (2250USD). The NI hardware was a bit harder to digest: 2500 euro (3650USD) for reading/generating block waves, analog and digital signals and closing some relays. We might have had a cheaper setup using some Advantech cards for example. But even then, the number of PCI cards often forces you into going for SBC's, backplanes and rack-cases like the Ventrix.

So that's what we bought eventually because it was supported under Linux. Now what did we ''really'' need controller side ?

* An ATX or small form factor PIV PC running (real-time) Linux
* A high-speed bus to connect to an IO island having dedicated encoder inputs, analog and digital IO.
* A PCI card interfacing connecting the PC to that bus.

Now what if that bus was plain Ethernet ? And what if that IO island had a completely open interface and runs firmware selected or compiled by you? You'd have an end-to-end open hardware system for robot control.

Where would you buy or how would you build such a system ? There is a standard, [EtherCat|www.ethercat.org], which is an [open real-time device protocol over Ethernet|http://http://en.wikipedia.org/wiki/EtherCAT]. There is one ''master'' sending packets to devices and each ''slave'' device modifies or extends the packet in microseconds and forwards it to the next device. The last device sends the packet back to the master. It's clearly a centralised controller solution, and it's main aim is to collect or send vast amounts of IO in real-time. Nothing constrains you however from networking the controllers themselves using another, not centralised, protocol.

There are already initial [master|http://www.etherlab.org/en/components.php] [implementations|http://ethercatmaster.berlios.de] in (real-time) Linux. The devices are mainly Beckhoff (but many vendors are jumping onboard) and a bit cheaper than National Instruments IO. However, it is not so cheap to extend this bus with your own hardware. Because the device reacts to the EtherCat packet using an FPGA chip, you'll have to ''buy'' your FPGA core if you want to attach a home made device. You can't find that yet on [Open Cores|http://www.opencores.org]. But its a great step forward, away from [a pretty darn closed protocol|http://www.sercos.com].

The EtherCat organization works like CAN does: anyone can freely create a master (read: controller), but if you want to create slave devices, you have to pay your share (by buying an FPGA core) of the development effort of the protocol. I'm sure this works very well in an industrial context, where (re-)liability is worth something, but where does this leave us, poor robot builders ?

I can't help wonder how this would be solved in an [open hardware community|http://opencollector.org/Whyfree/whyfree.html]. Are we saved by collectively writing an EtherCat core and let it spoil EtherCat's business model ? I think both can live perfectly together: an industrial grade core for industries, willing to pay for the added value of commercial support, while a growing community is supporting itself in the open source way.

Heard such a story before ? Yes we did, and [to which side is industry crossing nowadays|http://linuxdevices.com/articles/AT7065740528.html]? [Let's not wait for them|http://www.opencores.org/browse.cgi/filter/category_commctrl].