SOR Standardized Robotics Platform Community Project
SOR Community Project Overview
Fredrik Andersson started a thread in the forums about a community project. The first post can be found here. The idea evolved into the possibility of creating an entire hobby robotics standard. The purpose behind this standard would be to design code and schematics that would stick to a standard for easy use and allow people easier access to more advanced robotics faster and easier. The standard specifies that the boards will all have the same physical size and use the same communication protocol. This allows end users to purchase or build modules that can be linked together in any combination needed.
The basis of this standard is to build upon the concept of the $50 robot. This robot's purpose is to fill the gab between store bought kits and board level design and programming. The standard will allow modules to be built that will further fill this gap and for more creativity to be spent on the design of the overall robot and less time spent working out the kinks in programing and board design.
The standard is not meant to be cheaper then designing it yourself. Optimizing a schematic and utilizing a single microcontroller will always be the cheapest method. However this can be complex and makes every robot different. The standard allows the designer freedom to work on the overall functionality of the robot instead of the ins and outs of how it talks to each of the sensors and equipment. The standard is designed to be versatile and simple. This is a community project and it is open to discussion on the forums. Everyone is encouraged to design and program their own modules.
Communications Standard
SOR Community Project Communications Standard
Communication Between Microcontroller Based Modules.
Communication between microcontroller based modules should primarily be done over a multi-master i2c bus. There are 2 classes of i2c device: slave and master. The
speed of the bus will be set to a standard 100 kHz. This will also be
easily modified in source code for advanced users to change when needed. As
we are implementing a multi-master i2c bus, both master and slave
devices should accept incoming transmissions from a master on the bus.
Master devices should always have UART pins exposed and the option of outputting debug info where practical.
A subset of i2c bus masters called "routers" should be able to route packets to an output other than the i2c bus, eg the UART.
This
subset of i2c bus masters should also be able to receive an incoming
packet over an input other than the i2c bus (eg. UART) and route it to
the i2c bus.
Consider the following diagram:
i2c master nodes should be able to send and request information to and from other i2c master nodes, i2c slave nodes and nodes not on the i2c bus.
Nodes not on the i2c bus should be able to send to i2c master nodes, i2c slave nodes and other nodes not on the i2c bus.
Data sent on the bus needs to be determined by the destination module's designer. The design is also required to submit API code for use with the module so that the information is easy to use on the main control unit. The format of the data transmissions does not need to follow any specific form but does however need to comply to the standards of I2C and include The address for the module in question. Both the code for the module and the API needs to incorperate an method to change the address of the module easily but should have a default address assigned to it.
If this address is the i2c master node directly connected to the node in question then the data is handled locally.
If on the other hand it is a different address, the data will be transmitted on the i2c bus with the address in the packet as the destination.
When information is destined for a node not on the i2c bus things are a little more complex.
The transmitted packet should contain 2 addresses. The 1st address should contain the address of the i2c master node to which the destination connected. The 2nd address should contain the address of the destination node. (Provision should be made for more than one non i2c node connected to each i2c master.)
Example data packets:
~A001~B002~S~L004~dData
~A001 Addresses the packet to node 001.
~B002
(Optional) If the packet arrives at a master node and ~B exists and is
not equal to 000 then the master node (in this example 001) will
consult a lookup table to see which UART (or other port) to send the
packet out of.
~S Signifies that this packet is being Sent (ie, this is an i2c write).
~L004 Signifies the length of the data contained in the packet. (In this case, 4 bytes long.)
~d Signifies the start of the packet content (or data).
~A001~S~0100~1101~2102
~A001 Addresses the packet to node 001.
~S Signifies that this packet is being Sent (ie, this is an i2c write).
~0100 1st data byte sent has value "100"
~1101 2nd data byte sent has value "101"
~2102 3rd data byte sent has value "102"
~A001~R
~A001 Addresses the packet to node 001.
~R Signifies this packet is Reading data from node 001. (ie, an i2c read.)
Physical Design Standard
SOR Community Project Physical Design Standard
Physical Size
The target size for a module should be 64mm x 64mm ~(2.5 inches x 2.5 inches).
32.5mm x 32,5mm, 32.5mm x 64mm, 64mm x 64mm & 64 x 96.5mm are all acceptable sizes.
This is done to allow for compatibility the the Axon and Axon II MCU boards.
Mounting Holes and Mounting Brackets:
Chassis components should allow for M3 (4Gauge) screw to be fitted in a pattern that will allow for 32.5mm x 32.5mm square PCBs to be fitted adjacent to each other.
Screws can then be omitted as required to allow the fixing of larger boards.
On-board Voltages:
Modules operating at less than 5V should have on-board voltage regulator and buffer circuitry to allow 5V I/O.
Modules accepting greater than 5V (eg. 12V) which contain regulators to supply 5V to circuitry on board should also be able to supply other boards with 5V power to a minimum of 200mA.
Modules accepting greater than 5V (eg. 12V) to power high voltage components (eg, DC motor drivers) do not need regulators for modules 5V circuitry. They may draw 5V from another module.
Other electrical Specifications:
There should be space for i2c pull up resistors on all i2c master boards although only one set should be installed per bus. Also any modules designed to be power supplies for all 5 volt circuitry should also contain optional pull up resistors for the I2C bus.
If large amounts of interference are expected from an inductive load to be connected to a module (eg, large DC motors) efforts must be made to protect the i2c and power bus from adverse effects.
Connector Type:
For logic level (ie. 5V) connections standard 2.54mm (.1 Inch) pitch, single row header pins.
These should be placed near edges of board whenever practical to enable the use of straight or right angled header pins.
Male header pins should be used except where PCBs are going to mate with other PCBs where one should be a female type header.
Inexpensive crimp connectors should be used for connecting cables.
For higher voltage connectors a larger connector type should be used. (Exact specification TBA.)
Standard Connectors:
The NC (Not Connected) pin is to prevent accidental damage from reversing the connector.
All boards should be fitted with one of the i2c/power connectors at either side to allow modules to be daisy chained together.
UART header pins should also bring power in a 5 pin header like this: Vcc, GND, TX, RX, (NC). This is to provide debug capability to master modules and need not be available on slave modules.
Power here is for level shifters or other limited circuitry connected to the UART.
Standard Position for Connectors:
No set position for general purpose I/O pins although it is recommended to put them near the edge of boards to allow the use of right angled header pins if required.
The 5 pin i2c/power connectors should be mounted one at each side of the board to enable boards to be stacked easily.... (Exact position TBA.)
Publication Standard
SOR Community Project Publication Standards
When designing a module freedom is given the the design as long as they stay within the standard for communication and physical size. These standards will be discussed further on. However this is an open source project. When a module is designed and proposed to be included in the set it needs to have several conditions met as far as documentation and design go.
First:
All code used by the module needs to be published and commented throughout for easy access and use.
Second:
Board layouts need to be provided for through hole components. These need to be in Eagle Cad format as it is the most common and free access is available. Modules can have several board designs so it is possible to design a board using surface mount components but this project is design to allow beginners access to the modules so a through hole design is needed. If a smaller more compact SMD version is designed the layout does not necessarily need to be posted with the documentation.
Third:
A detailed tutorial needs to be written on how to use the module. This should include how to use the module and its specific functions. Explanation of complex code can also be included in this for those that want to dig deeper and possible modify the project.
The tutorials will need to be posted in the members tutorial section of the SOR website. This will centralize the documentation for all module designs. Being open source the modules can have several versions. If a design is modified by someone other then the original developer then permission needs to be obtained before their documentation can be changed to reflect the modified version. If permission is not obtained or the modification causes the design to warrant a new module then the person modifying the design needs to provide their own documentation.