Recent Changes for "Open Standards for Prosthetics" - Open Prosthetics Project Wiki

Open Standards for Prosthetics

adrian.poulton — 2009-08-14 13:00:21

Differences for Open Standards for Prosthetics

Deletions are marked with - .	Additions are marked with +.
Line 105:	Line 105:
	+ ==LonWorks 2.0== + [[File(LonWorks 2.pdf)]] +

Open Standards for Prosthetics

adrian.poulton — 2009-08-14 12:51:41

Upload of file LonWorks 2.pdf.

Open Standards for Prosthetics

JonKuniholm — 2009-03-12 18:09:10

Differences for Open Standards for Prosthetics

Deletions are marked with - .	Additions are marked with +.
Line 6:	Line 6:
	+ + =RFID Tags for Prosthetic Control Information= + It makes sense that a standard for or central repository of object data exist for facilitating the augmentation of control information that a prosthetic arm can use to manipulate an object. We've started a discussion of how that might work ["RFID for Prosthetic Arm Control" here].

Open Standards for Prosthetics

JonKuniholm — 2009-03-09 18:38:00

Differences for Open Standards for Prosthetics

Deletions are marked with - .	Additions are marked with +.
Line 49:	Line 49:
- =Some questions to consider=	+ ==Some questions to consider==
Line 67:	Line 67:
- =Candidate Bus Standards=	+ ==Candidate Bus Standards==
Line 70:	Line 70:
- ==Automotive==	+ ===Automotive===
Line 88:	Line 88:
- ==Avionics==	+ ===Avionics===
Line 99:	Line 99:
- =Connector Standards=	+ ==Connector Standards==
Line 102:	Line 102:
- =Implementation=	+ ==Implementation==

Open Standards for Prosthetics

JonKuniholm — 2009-03-09 18:36:08

Differences for Open Standards for Prosthetics

Deletions are marked with - .	Additions are marked with +.
Line 14:	Line 14:
- ==Design Requirements==	+ ==Design Requirements for Prosthetic Applications== +
Line 20:	Line 21:
	+ + The many standards available are classified in different ways in the literature, e.g. + + Arbitration v. No arbitration + Event triggered v. Time triggered + Asynchronous v. Synchronous + Equal status nodes v. Master/Slave + Non-deterministic v. Deterministic + + Arbitration is generally needed where more two nodes can transmit at the same time and so collisions are possible, e.g. Ethernet. One solution is for both nodes to stop transmitting and then try again after a random interval. CAN uses a bitwise arbitration mechanism where if two packets arrive together one is given priority based on an identifier. + + Time triggered systems differ from event triggered systems in that all activities are triggered by a periodic clock rather than by events themselves, so state messages are transmitted rather than event messages. Advantages claimed for time triggered systems include predictable bus loading and latency. + + Applications where real time is critical tend to use time triggered protocols such as TTCAN or TTP/C. Arbitrated networks such as standard Ethernet have some advantages in office networks where real time is not of the essence; for example, new nodes can be added easily. However, the possibility of collisions and ensuing delays is a drawback in real time applications. The effect of this can be controlled if the bus loading is kept light, by running at a high bit rate so that there are relatively large gaps between the packets. This was done in the ToMPAW project, which used the arbitrated LonWorks protocol, described in [http://www.oandp.org/jpo/library/2007_01_015.asp Kyberd et al (2007)] + . But this implies a certain inefficiency in the use of the bus. + + Time triggered protocols where sequences of messages are specified in advance (e.g. TTP/A rounds) may not as flexible as arbitrated protocols for office computer networks, but this need not be a disadvantage for prosthetics. Any given prosthesis will generally have a fixed set of nodes, and there is always an initial setup process where the network is configured. So although there should be no constraint on the number of possible different types of prosthesis, once a given prosthesis is set up there is no expectation that new nodes will be added, certainly not on a ‘plug and play’ basis. + + Some buses operate on a master/slave basis, where one particular node, the master, initiates all message exchanges. While one the face of it this appears less flexible than a network where any node can initiate transactions, it need not be a serious disadvantage in the case of a prosthesis. There is usually one node where EMG signals come in and commands to move joints are sent out. Conceivably other nodes might want to communicate with each other, for example a finger and thumb in an opposed grip, but most of the traffic is likely to pass through the node that collects the EMG (or other controlling input) signals. This node would be the natural candidate for the master in a master/slave bus. + + Message or packet length could be an important parameter. Typically a prosthesis will handle short chunks of data of not more than a few bytes, with information about joint angles, forces and so on. So packets need to be short and with low overhead. Increasing the size of the overhead allows for more error protection and other functions, at the expense of extra bus loading. But if a large quantity of data needs to be delivered, it is best sent in long packets, as the overhead is then a relatively small part of the packet. This might be the case if raw EMG data is transmitted. + + Electrically, low power drivers are available, but the power consumed by the driver itself is only part of the story. Most buses have terminating resistors of around 100 ohms to match to the characteristic impedance of the line, thus avoiding problems with reflections. These resistors consume power, which increases with the square of voltage. So a low signal voltage is preferable in this respect, but a high signal voltage is better for EMC immunity. I2C is rather different as it has a passive pull-up of a few kilohms. It is mainly intended for pcb tracks, where the characteristic impedance varies from one circuit to another. However, the limited current available from the pull-up means that capacitance has to be kept very low to achieve adequate data rates. + + Reflections are a potential problem when the time to propagate a pulse along the cable is comparable to or longer than a bit period. But a prosthetics bus is likely to be quite short, which could help in this respect. + + Differential drivers are preferred to single-ended types for EMC reasons. + + =Some questions to consider= + + What bus length is needed to cater for any prosthesis? One or two metres would seem adequate for most cases, but what about connecting to external test and measurement equipment? Or do we assume that this would always be done wirelessly? It may be important not to over-specify the maximum bus length. Buses like CAN have a maximum length for a given data rate, above which the bitwise arbitration mechanism breaks down. I2C has a maximum capacitance of 400 pF, which limits its use to quite short lengths of cable. + + What voltage will be available to power the network? Probably less than the motor supply, taking into account regulation etc. (dc-dc convertors could be used, but at extra cost, complexity, and some inefficiency). + + It would be useful to have some figures for actual data rates that might be needed in practice, based on the number of possible sensors, actuators and EMG inputs, and how often these signals need to be sampled. I’m assuming that only smoothed EMG data will be sent and not raw EMG, though it is possible that some of the higher speed buses could handle raw EMG quite adequately.
Line 31:	Line 67:
	+ =Candidate Bus Standards= + Short descriptions of a large number of buses can be found [http://www.interfacebus.com/Interface_Bus_Types.html here], including automotive buses, avionics buses and field buses. + + ==Automotive== + Automotive protocols are discussed in [http://www.aber.ac.uk/~dcswww/Research/mbsg/fmeaprojects/SoftFMEAtechreports/systems/protocols.pdf. Bell, J. (2002)]. In-vehicle networks are divided into classes A (< 10 kbit/s), B (10-125 kbit/s), C (125 kbit/s-1 Mbit/s) and D (> 1 Mbit/s). Here are some examples: + + LIN is a low cost network running at up to 19 200 baud. It is a time triggered, single master / multiple slave protocol. It uses a simple UART/SCI interface with a single-wire medium described [http://www.lin-subbus.org/ here] as being an enhanced version of ISO 9141. + + OBD-II refers to a Class B protocol for diagnostic tools for emission controls, as required by US legislation. There are various implementations of OBD-II (using J1850 and ISO 9141 standards), and different pins of the 16-pin standard connector are used to cope with the variants. + + Buses in classes A and B have been in use for many years and are well developed, but are they fast enough for prosthetics? + + The popular CAN protocol falls within class C. It is a CSMA/CD protocol with non-destructive bitwise arbitration. As such, latency is not guaranteed, but the TTCAN extension seeks to remedy this by allowing time triggered messages. + + TTP/C is a time triggered protocol for class C applications. It is a TDMA protocol with deterministic latency. TTP/A is a low cost version of TTP/C, for class A vehicle applications. There are several relevant articles at the [http://http://www.ttagroup.org/technology/articles.htm TTA-Group website]. TTP was developed at TU Wien. More recently this group has applied time triggered methods to Ethernet [http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4700418 Kopetz, 2008]. + + [http://www.flexray.com/ FlexRay] is a high speed (up to 10 Mbit/s) protocol for safety critical automotive applications. It supports both time triggered and event triggered messaging. + + When considering a network protocol for prosthetics, it should be noted that some of the automotive standards assume a 12V nominal supply. While some prostheses may use 12V, particularly for elbows, wrists and shoulders, generally not more than 6V will be available, reducing with battery discharge. + + + ==Avionics== + MIL-STD-1553 is very well established (Apache helicopter, satellites, Space Shuttle, ISS). It has a data rate of 1 Mbit/s, which is now inadequate for many avionics applications, so alternatives have been sought, e.g. an enhanced bit rate version EBR-1553 which is capable of 10 Mbit/s. MIL-STD-1553 uses TDMA and is often implemented in a dual redundant configuration, making it highly reliable, though costly. + + NASA has done an interesting comparison of several competitors to MIL-STD-1553 in [http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20060050129_2006251309.pdf Gwaltney and Briscoe, 2006]. The comparison matrix it provides is particularly useful. They review SAFEbus (a Honeywell backplane bus used in the Boeing 777), TTP/C, FlexRay, TTCAN, IEEE-1394B (Firewire), SpaceWire (a European standard based on IEEE 1355 and LVDS), Ethernet 10/100 Base-T, Avionics Full-Duplex Switched (AFDX) Ethernet (used on the A380 passenger plane), Fibre Channel, and Gigabit Ethernet. + + Fieldbuses. There are many fieldbuses for industrial automation and building applications, but they are largely proprietary, and so are not ideal for an open prosthetics project. A notable exception is Bitbus, which is an open standard. It is built on existing RS485 and SDLC standards and runs at data rates of 62.5 kbit/s, 375 kbit/s or 1.5 Mbit/s. It has been in use for a very long time, at least at the lower data rates, and is supported by a [http://www.bitbus.org user group]. + + Note on the Axon Bus. The use of TTP/A in the Otto Bock Axon Bus is described in [http://www.vmars.tuwien.ac.at/ttpa/publications.html Obermaisser and Kanitsar, 2000]. This document only discusses progress up to August 2000, so there have probably been significant changes since then. It describes two electrical interfaces, RS-232 and ISO-K. ISO-K is used for ISO 9141 vehicle diagnostics systems. + + The [http://www.axon-cable.com/pdf/BUS-ANG.pdf AXON’ Cable company] (note the apostrophe) makes cables for MIL-STD-1553 bus networks. This is not the same as TTP/A, and does not appear to have anything to do with the Otto Bock Axon bus. Probably Axon is just an obvious word to use for this sort of thing. +

Open Standards for Prosthetics

JonKuniholm — 2008-08-14 21:21:32

Differences for Open Standards for Prosthetics

Deletions are marked with - .	Additions are marked with +.
Line 23:	Line 23:
- Physical layer – RS485	+ ===Physical Layer Candidates (Please weigh in)=== + ====RS485==== + ====CAN==== + A transceiver is available that draws 75mw, nanoamps asleep, and 200uA in standby: + http://focus.ti.com/lit/ds/symlink/sn65hvd234.pdf + So here is a candidate for a transceiver that would draw 200uA most of the time.

Open Standards for Prosthetics

JonKuniholm — 2008-04-02 18:38:53

Differences for Open Standards for Prosthetics

Deletions are marked with - .	Additions are marked with +.
Line 28:	Line 28:
	+ + =Implementation= + A standard is useless unless it is complied with. This can be voluntary, if the various stakeholders can preserve or even further their interests through compliance, or can be externally driven, e.g. through requirements imposed by government or other organizations. There is currently no ISO standard for prosthetic communication.

Open Standards for Prosthetics

JonKuniholm — 2008-04-02 18:31:58

Differences for Open Standards for Prosthetics

Deletions are marked with - .	Additions are marked with +.
Line 12:	Line 12:
	+ The [http://www.unb.ca/biomed/ University of New Brunswick Center for Biomedical Engineering], which hosts the MEC conference, has been working on the technical details of what such a standard might look like. With their permission, here are the basic details of the proposed standard: + + ==Design Requirements== + Noise immunity + Low power + High speed – 5Mbits/sec (driven by the desire to stream data over the network) + Daisy chaining capability (for streaming raw myo data from daisy-chained electrodes, in order to minimize wire routing problems) + Small physical size of required components (ie: connectors and transceivers) + + ==Initial Proposed System== + 4 wire differential multi-drop bus + Physical layer – RS485 + High level layers – Modbus +

Open Standards for Prosthetics

JonKuniholm — 2008-04-02 17:42:36

Differences for Open Standards for Prosthetics

Deletions are marked with - .	Additions are marked with +.
Line 1:	Line 1:
	+ While related to the ["Open Myoelectric Signal Processor" Open Myo Project] (which will comply with these standards if and when when they are developed), there is a great need within the prosthetic industry (particularly upper extremity) for standards of interoperability. These could extend from mechanical connections, like the Otto-Bock quick disconnect wrist, a de facto standard, to electrical bus standards for communication like the CAN-based [http://en.wikipedia.org/wiki/OBD-II#OBD-II OBD-II] standard used in automobiles, to a connector standard for assembling, programming or troubleshooting components. This topic will be a subject of discussion at a breakout session at the [http://www.unb.ca/biomed/mec.php MEC 2008 Conference in August], and we have created this project page to serve as a source of information and a place to begin and continue a dialog about the development of these standards. + + =Mechanical Interfaces for Prosthetic Components= + ==Arms== + The current de facto standard for detachable prosthetic arm terminal devices is the Otto-Bock quick disconnect wrist. While interchangeable components are available from a variety of suppliers, the use of components from different suppliers will in many cases void warranties, and is specifically discouraged. + + =Control Bus for Mechatronic Arm Prostheses= + Most of the effort in this area has so far focused on arms, as the need for communication with and between components in powered legs is a matter of debate (unless you want to dance), but is a necessity in arms. The two DARPA Revolutionizing Prosthetics projects use different [http://en.wikipedia.org/wiki/Controller_Area_Network CAN]-based architectures. The Otto-Bock [http://www.ottobockus.com/products/upper_limb_prosthetics/dynamicarm.asp dynamic arm] uses proprietary Axon Bus technology, cited in [http://www.embedded-computing.com/departments/embedded_europe/2006/08/ some places] as the same as that being used in aircraft. It is not clear if [http://www.axon-cable.com/pdf/BUS-ANG.pdf this] is the same product or not. It is assumed that future Otto-Bock upper extremity products, such as the [http://www.shadmehrlab.org/Courses/physfound_files/Thakor.pdf Michaelangelo Hand] will also communicate with this protocol. + + The ["Open Myoelectric Signal Processor" Open Myo Project] is considering support of a variety of protocols, including I2C / TWI, Ethernet, USB, Analog (e.g. onboard DAC), DC Myo emulation with the standard Bock 1.25/1.3V offset, JTAG, and possibly RS-232, CAN, and Bluetooth. Obviously, the device will support the protocol discussed on this page, if and when it materializes. + + =Connector Standards= + The OBD-II standard for car diagnostics mentioned above is a connector standard that includes the CAN communication wires, but additionally had legacy support for other communication protocols.